Downloads |
Table Of Contents
Overview of the IOS SLB Feature
Functions and Capabilities of the IOS SLB Feature
Automatic Server Failure Detection
Client-Assigned Load Balancing
Delayed Removal of TCP Connection Context
Dynamic Feedback Protocol for IOS SLB
Network Address Translation (NAT)
Transparent Web Caches Balancing
Supported Standards, MIBs, and RFCs
Monitoring and Maintaining the IOS SLB Feature
Complete Example Configuration
Example of a Layer 3 Switch with ISL, VLAN, and BVI with GEC
Example of an IOS Layer 3 Switch with HSRP
Example of a Layer 3 Switch Configured with IOS SLB
Example of IOS SLB with NAT Configuration
Example of IOS SLB with an HTTP Probe Configuration
Example of IOS SLB with Stateful Backup Configuration
Example of IOS SLB with Redistribution of Static Routes
standby priority, standby preempt
FAQ (Frequently Asked Questions)
IOS Server Load Balancing
This feature module describes the Cisco IOS Server Load Balancing (SLB) feature for Cisco IOS Release 12.1(2)E. It includes the following sections:
•
Overview of the IOS SLB Feature
•
•
•
•
•
Overview of the IOS SLB Feature
The IOS SLB feature is an IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, you can define a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. In this environment, the clients connect to the IP address of the virtual server. The virtual server IP address is configured as a loopback address, or secondary IP address, on each of the real servers. (When you configure IOS SLB in server NAT mode, you do not need to configure these loopback addresses.) When a client initiates a connection to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured load balancing algorithm.
Note
Figure 1 illustrates a logical view of a simple IOS SLB network.
Figure 1 Logical View of IOS SLB
Functions and Capabilities of the IOS SLB Feature
This section describes the following functions and capabilities provided by IOS SLB:
•
•
•
•
•
•
•
•
This section also describes the following aspects of IOS SLB:
•
Algorithms for Load Balancing
IOS SLB provides two load balancing algorithms: weighted round robin and weighted least connections. You may specify either algorithm as the basis for choosing a real server for each new connection request that arrives at the virtual server.
Weighted Round Robin
The weighted round robin algorithm specifies that the real server used for a new connection to the virtual server is chosen from the server farm in a circular fashion. Each real server is assigned a weight, n, that represents its capacity to handle connections, as compared to the other real servers associated with the virtual server. That is, new connections are assigned to a given real server n times before the next real server in the server farm is chosen.
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. The first three connections to the virtual server are assigned to ServerA, the fourth connection to ServerB, and the fifth and sixth connections to ServerC.
Note
Weighted Least Connections
The weighted least connections algorithm specifies that the next real server chosen from a server farm for a new connection to the virtual server is the server with the fewest active connections. Each real server is assigned a weight for this algorithm, also. When weights are assigned, the server with the fewest connections is based on the number of active connections on each server, and on the relative capacity of each server. The capacity of a given real server is calculated as the assigned weight of that server divided by the sum of the assigned weights of all of the real servers associated with that virtual server, or n1/(n1+n2+n3...).
For example, assume a server farm comprised of real server ServerA with n = 3, ServerB with n = 1, and ServerC with n = 2. ServerA would have a calculated capacity of 3/(3+1+2), or half of all active connections on the virtual server, ServerB one-sixth of all active connections, and ServerC one-third of all active connections. At any point in time, the next connection to the virtual server would be assigned to the real server whose number of active connections is farthest below its calculated capacity.
Note
Alternate IP Addresses
IOS SLB enables you to telnet to the load balancing device using an alternate IP address. To do so, use either of the following methods:
•
•
This function is similar to that provided by the LocalDirector (LD) Alias command.
Automatic Server Failure Detection
IOS SLB automatically detects each failed connection attempt to a real server, and increments a failure counter for that server. (The failure counter is not incremented if a failed connection from the same client has already been counted.) If a server's failure counter exceeds a configurable failure threshold, the server is considered out of service and is removed from the list of active real servers.
Automatic Unfail
When a real server fails and is removed from the list of active servers, it is assigned no new connections for a length of time specified by a configurable retry timer. After that timer expires, the server is again eligible for new virtual server connections and IOS SLB sends the server the next qualifying connection. If the connection is successful, the failed server is placed back on the list of active real servers. If the connection is unsuccessful, the server remains out of service and the retry timer is reset.
Client-Assigned Load Balancing
Client-assigned load balancing allows you to limit the subnets that use a virtual server.
Delayed Removal of TCP Connection Context
Because of IP packet ordering anomalies, IOS SLB might "see" the termination of a TCP connection (a finish [FIN] or reset [RST]) followed by other packets for the connection. This problem usually occurs when there are multiple paths that the TCP connection packets can follow. To correctly redirect the packets that arrive after the connection is terminated, IOS SLB retains the TCP connection information, or context, for a specified length of time. The length of time the context is retained after the connection is terminated is controlled by a configurable delay timer.
Dynamic Feedback Protocol for IOS SLB
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 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 on 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 a default weight for the real servers.
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 traffic, the DFP agent can send an early report.
HTTP Probes
HTTP probes are a simple way to monitor applications being server load balanced. With frequent probes, the operation of each application is verified, not just connectivity to the application.
For server load balancing:
•
•
•
Maximum Connections
IOS SLB allows you to configure maximum connections, a limit on the number of active connections that a real server is assigned. If the maximum number of connections is reached for a real server, IOS SLB automatically switches all further connection requests to another server until the connection number drops below the specified limit.
Network Address Translation (NAT)
Cisco IOS NAT, RFC 1631, allows unregistered "private" IP addresses to connect to the Internet by translating them into globally registered IP addresses. Cisco IOS NAT also increases network privacy by hiding internal IP addresses from external networks.
IOS SLB can operate in one of two redirection modes:
•
•
IOS SLB supports the following types of NAT:
•
Note
The network designer must ensure that outbound packets travel through IOS SLB, using one of the following methods:
–
–
–
•
Note
Port-Bound Servers
You must specify which Transmission Control Protocol/User Datagram Protocol (TCP/UDP) port a virtual server handles. 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 to a virtual server address for a port that is not specified in a virtual server definition are not redirected.
IOS SLB supports both port-bound and non-port-bound servers, but port-bound servers are recommended.
Redundancy Enhancements
An IOS SLB could represent a point of failure and the servers could lose their connections to the backbone if power fails, or if a link from a switch to the distribution-layer switch is disconnected. IOS SLB supports two redundancy options you can use to reduce that risk:
•
•
Slow Start
In an environment that uses weighted least connections load balancing, a real server that is placed in service initially has no connections, and could therefore be assigned so many new connections that it becomes overloaded. To prevent such an overload, slow start controls the number of new connections that are directed to a real server that has just been placed in service.
Sticky Connections
When you use sticky connections, new connections from a client IP address are assigned to the same real server as were previous connections from that address. This behavior is controlled by a configurable sticky timer. If the timer is configured on a virtual server, 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 allow you to create a sticky object for a subnet, ensuring that all flows from the subnet are sent to the same real server. (Make sure the volume of flows is not so large that it overwhelms the real server.)
Sticky connections also permit the coupling of services that are handled by more than one virtual server. 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 are assigned to the same real server.
SynGuard
SynGuard limits the rate of TCP start-of-connection packets (SYNchronize sequence numbers, or SYNs) handled by a virtual server to prevent a type of network problem known as a SYN flood denial-of-service attack. A user might send a large number of SYNs to a server, which could overwhelm or crash the server, denying service to other users. SynGuard prevents such an attack from bringing down IOS SLB or a real server. SynGuard monitors the number of SYNs 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.
TCP Session Reassignment
IOS SLB tracks each TCP SYN sent to a real server by a client attempting to open a new connection. If several consecutive SYNs are not answered, or if a SYN is replied to with an RST, the TCP session is reassigned to a new real server. The number of SYN attempts is controlled by a configurable reassign threshold.
Transparent Web Caches Balancing
You can use IOS SLB to balance transparent Web caches if you know the IP addresses they are serving. Simply configure the IP addresses, or some common subset of them, as virtual servers.
Note
Benefits
IOS SLB facilitates scalability and availability. The addition of new servers and the removal or failure of existing servers can occur at any time without affecting the availability of the virtual server.
In a branch office, IOS SLB allows balancing of multiple sites and disaster recovery in the event of full-site failure, and distributes the work of load balancing.
Restrictions
IOS SLB has the following restrictions:
•
•
•
•
•
–
–
•
–
–
–
–
–
–
–
•
–
–
–
Supported Platforms
•
•
•
Supported Standards, MIBs, and RFCs
Standards
•
MIBs
•
Note
RFCs
•
Configuration Tasks
This section describes the required and optional IOS SLB network configuration tasks.
•
•
Required Configuration Tasks
This section describes the tasks required to configure a basic IOS SLB network.
Configuring IOS SLB involves identifying server farms, configuring groups of real servers in server farms, and configuring the virtual servers that represent the real servers to the clients. See the following sections for required configuration tasks for the IOS SLB feature.
•
•
•
•
•
•
•
Figure 2 shows a sample IOS SLB network with the following components:
•
•
–
–
•
–
–
Figure 2 Example SLB Network
To configure the IOS SLB network described and shown in Figure 2, use the following commands beginning in global configuration mode:
The following sections include examples of the configuration commands used to configure and verify the SLB network shown in Figure 2:
•
•
•
•
•
•
•
Configuring the Server Farms
The following commands configure the server farm PUBLIC and associate the three real servers:
Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.1.1.2Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.1.1.3Router(config-slb-real)# inserviceRouter(config-slb-real)# endThe following commands configure the server farm RESTRICTED and associate the two real servers:
Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# real 10.1.1.20Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.1.1.21Router(config-slb-real)# inserviceRouter(config-slb-real)# endRouter#Verifying the Server Farms
The following show ip slb reals command displays the status of server farms PUBLIC and RESTRICTED, the associated real servers, and their status:
Router# show ip slb realreal server farm weight state conns---------------------------------------------------------------------10.1.1.1 PUBLIC 8 INSERVICE 010.1.1.2 PUBLIC 8 INSERVICE 010.1.1.3 PUBLIC 8 INSERVICE 010.1.1.20 RESTRICTED 8 INSERVICE 010.1.1.21 RESTRICTED 8 INSERVICE 0Router#The following show ip slb serverfarm command displays the configuration and status of server farms PUBLIC and RESTRICTED:
Router# show ip slb serverfarmserver farm predictor nat reals bind id---------------------------------------------------PUBLIC ROUNDROBIN none 3 0RESTRICTED ROUNDROBIN none 2 0Router#Configuring the Virtual Servers
The following commands configure the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router#Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# virtual 10.0.0.1 tcp wwwRouter(config-slb-vserver)# serverfarm PUBLICRouter(config-slb-vserver)# inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# exitRouter(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# virtual 10.0.0.2 tcp wwwRouter(config-slb-vserver)# serverfarm RESTRICTEDRouter(config-slb-vserver)# inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# endRouter#Verifying the Virtual Servers
The following show ip slb vservers command verifies the configuration of the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP:
Router# show ip slb vserversslb vserver prot virtual state conns-------------------------------------------------------------------PUBLIC_HTTP TCP 10.0.0.1:80 INSERVICE 0RESTRICTED_HTTP TCP 10.0.0.2:80 INSERVICE 0Router#Router#Configuring the Restricted Clients
The following commands remove the virtual server RESTRICTED_HTTP from service, configure the restricted client access to the virtual server, then enable the virtual server again:
Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# no inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0Router(config-slb-vserver)# inserviceRouter(config-slb-vserver)#src = 0 - 0.(Information Deleted).index = 1Router(config-slb-vserver)# endRouter#Verifying the Restricted Clients
The following show ip slb conns command verifies the restricted client access and status:
Router# show ip slb connsvserver prot client real state nat-------------------------------------------------------------------------------RESTRICTED_HTTP TCP 10.4.4.0:80 10.1.1.20 CLOSING noneRouter#The following show ip slb conns command displays detailed information about the restricted client access status:
Router# show ip slb conns client 10.4.4.0 detailVSTEST_UDP, client = 10.4.4.0:80state = CLOSING, real = 10.1.1.20, nat = nonev_ip = 10.0.0.2:80, TCP, service = NONEclient_syns = 0, sticky = FALSE, flows attached = 0Router#Verifying IOS SLB Connectivity
To verify that the IOS SLB feature has been installed and is operating correctly, ping the real servers from the IOS SLB switch, then ping the virtual servers from the clients.
The following show ip slb stats command displays detailed information about the IOS SLB network status:Router# show ip slb statsPkts via normal switching: 0Pkts via special switching: 6Connections Created: 1Connections Established: 1Connections Destroyed: 0Connections Reassigned: 0Zombie Count: 0Connections Reused: 0Router#Normal switching is when IOS SLB packets are handled on normal IOS switching paths (CEF, FastSwitching, and Process Level). Special switching is when IOS SLB packets are handled on hardware-assisted switching paths.
See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify IOS SLB networks and connections.
Example Configuration of a Basic IOS SLB Network
The following show running-config command example displays the IOS SLB network described and shown in Figure 2:
Router# show running-configBuilding configuration....(Information Deleted).ip slb serverfarm PUBLICreal 10.1.1.1inservicereal 10.1.1.2inservicereal 10.1.1.3inservice!ip slb serverfarm RESTRICTEDreal 10.1.1.20inservicereal 10.1.1.21inservice!ip slb vserver PUBLIC_HTTPvirtual 10.0.0.1 tcp wwwserverfarm PUBLICinservice!ip slb vserver RESTRICTED_HTTPvirtual 10.0.0.2 tcp wwwserverfarm RESTRICTEDclient 10.4.4.0 255.255.255.0inservice!Optional Configuration Tasks
This section describes the following optional tasks you can use to fine tune the IOS SLB configuration:
•
•
•
•
•
•
Specifying a Load Balancing Algorithm
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
To specify the load balancing algorithm, use the following command in server farm configuration mode:
The following example shows how to configure weighted least-connections algorithm:
Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# predictor leastconnsSee the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify SLB network connections and the "Complete Example Configuration" section for an example of a SLB network configuration.
Specifying a Bind ID
The bind ID allows a single physical server to be bound to multiple virtual servers and report a different weight for each one. Thus, the single real server is represented as multiple instances of itself, each having a different bind ID. DFP uses the bind ID to identify for which instance of the real server a given weight is specified. The bind ID is needed only if you are using DFP.
To configure a bind ID on the server farm for use by DFP, use the following command in server farm configuration mode:
Specifies a bind ID on the server farm for use by DFP. See the bindid command for more details.
The following example shows how to configure a bind ID of 309 on server farm RESTRICTED:
Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# bindid 309See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify SLB network connections and the "Complete Example Configuration" section for an example of a SLB network configuration.
Configuring Real Server Attributes
You can configure any of the following real server attributes, by using the following real server commands beginning in global configuration mode:
The following example shows how to configure the consecutive connection failures to 16 that constitute the failure of real server 10.1.1.1:
Router(config)# ip slb serverfarm RESTRICTEDRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-real)# faildetect numconns 16The following example shows how to configure maximum number of connections to 1000:
Router(config-slb-real)# maxconns 1000The following example shows how to configure the number of consecutive unanswered SYNs to 4 that initiates assignment of the connection to a different real server:
Router(config-slb-real)# reassign 4The following example shows how to configure the retry interval to 120 seconds between the detection of a server failure and the next attempt to connect on real server 10.1.1.1:
Router(config-slb-real)# retry 120The following example shows how to configure workload capacity to 16, relative to other servers in the server farm:
Router(config-slb-real)# weight 16The following example shows how to enable the real server back into service after making changes to its configuration:
Router(config-slb-real)# inserviceSee the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify SLB network connections and the "Complete Example Configuration" section for an example of a SLB network configuration.
Adjusting Virtual Server Values
To change the default settings of the virtual server values, use the related virtual server command beginning in global configuration mode:
The following commands remove the virtual server RESTRICTED_HTTP from service and then configures the restricted client access to the virtual server:
Router(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# no inserviceRouter(config-slb-vserver)#.(Information Deleted).index = 1Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0By default, virtual server addresses are advertised. That is, static routes to the Null0 interface are installed for the virtual server addresses. To advertise these static routes using the routing protocol, you must configure redistribution of static routes for the routing protocol. To prevent the installation of a static route, use the no form of the advertise command:
Router(config-slb-vserver)# no advertiseThe following command configures the delay timer to 20 seconds after the termination of the TCP connection to the virtual server:
Router(config-slb-vserver)# delay 20The following command configures the idle time to 180 seconds (3 minutes) that the SLB maintains connectivity to the virtual server in the absence of packet activity:
Router(config-slb-vserver)# idle 180The following command configures the time to 60 seconds for connections from the same client to use the same real server:
Router(config-slb-vserver)# sticky 60 group 1The following command configures the rate of TCP SYNs to 3600000 handled by the virtual server:
Router(config-slb-vserver)# synguard 3600000The following example enables the virtual server again after modification:
Router(config-slb-vserver)# inserviceRouter(config-slb-vserver)#src = 0 - 0.(Information Deleted).index = 1Router(config-slb-vserver)#See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify SLB network connections and the "Complete Example Configuration" section for an example of a SLB network configuration.
Configuring IOS SLB Dynamic Feedback Protocol
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 IOS SLB DFP, enter the following commands in order, beginning in global configuration mode:
The following commands set the DFP password to Cookies, the timeout as 360 seconds, and then changes the CLI to DFP configuration mode:
Router(config)# ip slb dfp password Cookies 360Router(config-slb-dfp)#The following DFP command configures the IP address of the DFP agent as 10.1.1.1 and sets the connection port to use as 2221 (FTP):
Router(config-slb-dfp)# agent 10.1.1.1 2221See the "Monitoring and Maintaining the IOS SLB Feature" section for additional commands used to verify SLB network connections and the "Complete Example Configuration" section for an example of a SLB network configuration.
Configuring IOS SLB NAT
Cisco Network Address Translator (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)" section.
To configure IOS SLB NAT for client mode, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the client address pool.
Step 2
Configures which NAT mode to use. See the nat command for more details.
The following commands configure a NAT server on server farm PUBLIC:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# nat serverTo configure IOS SLB NAT client mode for a specific server farm, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the client address pool.
Step 2
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode. See the ip slb serverfarm command for more details.
Step 3
Configures which NAT mode to use. See the nat command for more details.
Step 4
Router(config-slb-sfarm)# real ip-address [port_number]Identifies a real server to the IOS SLB function and initiates real server configuration mode. See the real command for more details.
Step 5
Enables the real server for use by IOS SLB. See the inservice (real server) command for more details.
Step 6
Router(config-slb-real)# exitReturn to server farm configuration mode.
Step 7
Router(config-slb-real)# endReturn to global configuration mode.
Step 8
Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details.
The following commands configure NAT clients on server farm FARM2:
Router# config tEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb natpool web-clients 128.3.0.1 128.3.0.254 netmask 255.255.0.0Router(config)# ip slb serverfarm FARM2Router(config-slb-sfarm)# nat client web-clientsRouter(config-slb-sfarm)# real 10.3.1.1Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.4.1.1 8080Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.4.1.1 8081Router(config-slb-real)# inserviceRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.4.1.1 8082Router(config-slb-real)# inserviceRouter(config-slb-real)# endRouter#00:27:00: %SYS-5-CONFIG_I: Configured from console by consoleRouter# config terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip slb vserver HTTP2Router(config-slb-vserver)# virtual 128.2.0.1 tcp wwwRouter(config-slb-vserver)# serverfarm FARM2Router(config-slb-vserver)# inserviceRouter(config-slb-vserver)#(Information Deleted)Router# copy running-config startup-configDestination filename [startup-config]?Building configuration...[OK]Router#Following is the final configuration after a NAT client pool is configured using the previous process:
Router# show running-configBuilding configuration...(Information Deleted)!ip slb natpool WEB-CLIENTS 128.3.0.1 128.3.0.254 netmask 255.255.0.0 entries 8000 13851890ip slb serverfarm FARM2nat servernat client WEB-CLIENTSreal 10.3.1.1faildetect numconns 8 numclients 2inservicereal 10.4.1.1 8080faildetect numconns 8 numclients 2inservicereal 10.4.1.1 8081faildetect numconns 8 numclients 2inservicereal 10.4.1.1 8082faildetect numconns 8 numclients 2inservice!ip slb vserver HTTP2virtual 128.2.0.1 tcp wwwserverfarm FARM2inserviceConfiguring HTTP Probes
HTTP probes monitor applications being server load balanced. For a detailed description of HTTP probes, see the "HTTP Probes" section.
To configure an HTTP probe, enter the following commands in order, beginning in global configuration mode:
Step 1
Configures the IOS SLB probe name and changes to HTTP configuration submode. See the ip slb probe command for more details.
Step 2
(Optional) Configures the URL path to request from the server. See the request method, request url command for more details.
Step 3
(Optional) Configures the method used to perform the request to the server. See the request method, request url command for more details.
Step 4
(Optional) Configures the expected HTTP status code. See the expect command for more details.
Step 5
(Optional) Configures the HTTP probe transmit timers. See the interval (HTTP Probe) command for more details.
Step 6
(Optional) Configures basic authentication values for the HTTP probe. See the header command for more details.
Step 7
(Optional) Configures basic authentication values for the HTTP probe. See the credentials command for more details.
Note
The following example shows how to configure an HTTP probe named TREADER:
Router(config)# ip slb probe TREADER httpRouter(config-slb-probe)# request method post url /probe.cgi?allRouter(config-slb-probe)# header CookieRouter(config-slb-probe)# credentials Semisweet chipsRouter(config-slb-probe)# exitRouter(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# probe TREADERRouter(config-slb-sfarm)# endThe proceeding example configures the following HTTP probe parameters:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
To verify that the HTTP probe is configured correctly, use the following show ip slb probe command:
Router# show ip slb probeServer:Port Status Outages Current Cumulative----------------------------------------------------------10.1.1.1:80 200 0 never 00:00:0010.1.1.2:80 200 0 never 00:00:0010.1.1.3:80 200 0 never 00:00:00Following are the HTTP probe configuration statements for the HTTP probe configured in the previous example:
!Router(config)# ip slb probe TREADER httpRouter(config-slb-probe)# request method post url /probe.cgi?allRouter(config-slb-probe)# header CookieRouter(config-slb-probe)# header Authorization Basic U2VtaXN3ZWV0OmNoaXBz!Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# nat serverRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.1.1.2Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# real 10.1.1.3Router(config-slb-sfarm)# inserviceRouter(config-slb-sfarm)# probe TREADER!Implementing IOS SLB Stateless Backup
Stateless backup, based on the Hot Standby Router Protocol (HSRP), provides high network availability by routing IP traffic from hosts on Ethernet networks without relying on the availability of any single Layer 3 switch. Stateless backup is particularly useful for hosts that do not support a router discovery protocol (such as the Intermediate System-to-Intermediate System [IS-IS] Interdomain Routing Protocol [IDRP]) and do not have the functionality to shift to a new Layer 3 switch when their selected Layer 3 switch reloads or loses power.
How IOS SLB Stateless Backup Works
A Layer 3 switch running the HSRP detects a failure by sending and receiving multicast User Datagram Protocol (UDP) "hello" packets. When the IOS SLB switch running HSRP detects that the designated active Layer 3 switch has failed, the selected backup Layer 3 switch assumes control of the HSRP group MAC and IP addresses. (You can also select a new standby Layer 3 switch at that time.) Both the primary and the backup Layer 3 switch must be on the same subnetwork.
The chosen MAC and IP addresses must be unique and must not conflict with any others on the same network segment. The MAC address is selected from a pool of Cisco MAC addresses. Configure the last byte of the MAC address by using the HSRP group number. When the HSRP is running, it selects an active Layer 3 switch and instructs its device layer to listen on an additional (dummy) MAC address.
IOS SLB switching software supports HSRP over 10/100 Ethernet, Gigabit Ethernet, FEC, GEC, and BVI (Bridge-Group Virtual Interface) connections.
HSRP uses a priority scheme to determine which HSRP-configured Layer 3 switch is to be the default active Layer 3 switch. To configure a Layer 3 switch as active, you assign it a priority higher than that of all other HSRP-configured Layer 3 switches. The default priority is 100, so if you configure just one Layer 3 switch to have a higher priority, that switch becomes the default active switch.
HSRP works by the exchange of multicast messages that advertise priority among HSRP-configured Layer 3 switches. When the active switch fails to send a hello message within a configurable period, the standby switch with the highest priority becomes the active switch. The transition of packet-forwarding functions between Layer 3 switches is completely transparent to all hosts accessing the network.
HSRP-configured Layer 3 switches exchange the following types of multicast messages:
•
•
•
At any time, HSRP-configured Layer 3 switches are in one of the following states:
•
•
•
•
Configuring IOS SLB Stateless Backup
Configuration of stateless backup requires the following:
•
•
To configure stateless backup over VLANs between SLB switches, perform the following tasks in order:
Step 1
Note
Step 2
Step 3
Step 4
Step 5
Step 6
A sample stateless backup configuration is shown in the "Sample IOS SLB Stateless Backup Configuration" section.
Enabling HSRP
To enable HSRP on an IOS SLB interface, enable the protocol, then customize it for the interface. Enter the following command in interface configuration mode:
Customizing Group Attributes
To customize "hot standby" group attributes, use one or more of the following commands in interface configuration mode:
Verifying the IOS SLB Stateless Backup Configuration
To verify that stateless backup has been configured and is operating correctly, use the following show ip slb vservers commands to display information about the IOS SLB virtual server status:
Router# show ip slb vserversslb vserver prot virtual state conns-------------------------------------------------------------------VS1 TCP 10.10.10.12:23 INSERVICE 2VS2 TCP 10.10.10.18:23 INSERVICE 2Router# show ip slb vservers detailVS1, state = INSERVICE, v_index = 10virtual = 10.10.10.12:23, TCP, service = NONE, advertise = TRUEserver farm = SERVERGROUP1, delay = 10, idle = 3600sticky timer = 0, sticky subnet = 255.255.255.255sticky group id = 0synguard counter = 0, synguard period = 0conns = 0, total conns = 0, syns = 0, syn drops = 0standby group = NoneVS2, state = INOFSERVICE, v_index = 11virtual = 10.10.10.18:23, TCP, service = NONE, advertise = TRUEserver farm = SERVERGROUP2, delay = 10, idle = 3600sticky timer = 0, sticky subnet = 255.255.255.255sticky group id = 0synguard counter = 0, synguard period = 0conns = 0, total conns = 0, syns = 0, syn drops = 0standby group = NoneSample IOS SLB Stateless Backup Configuration
The following commands enable the HSRP standby group 100 IP address, priority, preempt, timers, configure a name and authentication for Device A in Figure 3:
Router(config-if)# standby 100 ip 172.20.100.10Router(config-if)# standby 100 priority 110Router(config-if)# standby 100 preempt delay 910Router(config-if)# standby 100 timers 5 15Router(config-if)# standby 100 name Web-Group1Router(config-if)# standby 100 authentication SecretRouter(config-if)# exitRouter#Configuring IOS SLB Stateful Backup
Stateful backup enables SLB to incrementally back up its load-balancing decisions, or "keep state," between primary and backup Layer 3 switches. The backup switch has its virtual servers in a dormant state until failover is detected by HSRP; then the backup (now primary) switch begins advertising virtual addresses and filtering traffic. You can use HSRP to configure how quickly the failover is detected.
This enhancement provides SLB with a one-to-one stateful or idle backup scheme. This means that only one instance of SLB is handling client or server traffic at a given time, and that there is at most one backup platform for each active 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:
Step 1
Configures a virtual server and enters virtual server configuration mode.
Step 2
Configures a stateful backup of SLB decision tables to a backup switch. See the replicate casa 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 7:
Router(config)# ip slb vserver RESTRICTED_HTTPRouter(config-slb-vserver)# virtual 10.10.10.12 tcp telnetRouter(config-slb-vserver)# replicate casa 10.10.3.132 10.10.99.3 1032 password PASSRouter(config-slb-vserver)# inservice standby virtRouter(config-slb-vserver)#.(Information Deleted)Monitoring and Maintaining the IOS SLB Feature
To obtain and display runtime information about IOS SLB, use the following commands in EXEC mode:
Displays all connections handled by IOS SLB, or, optionally, only those connections associated with a particular virtual server or client. See the show ip slb conns command for more details.
Displays information about DFP and DFP agents, and about the weights assigned to real servers. See the show ip slb dfp command for more details.
Displays information about the real servers defined to IOS SLB. See the show ip slb reals command for more details.
Displays information about the server farms defined to IOS SLB. See the show ip slb serverfarms command for more details.
Displays IOS SLB statistics. See the show ip slb stats command for more details.
Displays information about the sticky connections defined to IOS SLB. See the show ip slb sticky command for more details.
Displays information about the virtual servers defined to IOS SLB. See the show ip slb vservers command for more details.
Displays information about the HTTP probe defined to IOS SLB. See the show ip slb probe command for more details.
Router# show ip slb replicateDisplays information about the IOS SLB replication configuration. See the show ip slb replicate command for more details.
Configuration Examples
This section provides real-world examples of Layer 3 switching configurations and includes the following sections:
•
•
•
•
•
•
•
•
Note
Complete Example Configuration
The following example provides a complete configuration using the commands described in this feature module:
Router# show running-configBuilding configuration...Current configuration:!.(Information Deleted).ip slb probe TREADER httprequest method POST url /probe.cgi?allheader Cookieheader Authorization Basic U2VtaXN3ZWV0OmNoaXBz!ip slb serverfarm PUBLICnat serverreal 10.1.1.1inservicereal 10.1.1.2inservicereal 10.1.1.3inserviceprobe TREADER!ip slb serverfarm RESTRICTEDpredictor leastconnsbindid 309real 10.1.1.1weight 32maxconns 1000reassign 4faildetect numconns 16retry 120inservicereal 10.1.1.20inservicereal 10.1.1.21inservice!ip slb vserver PUBLIC_HTTPvirtual 10.0.0.1 tcp wwwserverfarm PUBLICno inservice!ip slb vserver RESTRICTED_HTTPvirtual 10.0.0.2 tcp wwwserverfarm RESTRICTEDno advertisesticky 60 group 1idle 1800client 10.4.4.0 255.255.255.0synguard 3600000inservice!Example of a Layer 3 Switch with ISL, VLAN, and BVI with GEC
This example configuration focuses on both the Inter-Switch Link (ISL) and virtual LANs (VLANs), as well as integrated routing and bridging (IRB) using a bridge-group virtual interface (BVI) over Gigabit EtherChannel (GEC). The Cisco proprietary ISL allows any Fast Ethernet port to be configured as a trunk. The Spanning-Tree Protocol detects and breaks loops on all the VLANs carried across the trunk.
The Gigabit Ethernet interface information applies to both two-port and eight-port Gigabit Ethernet interfaces for a Catalyst 8540 campus Layer 3 switch. This example also includes port snooping and Network Time Protocol (NTP) configurations.
!ip subnet-zerono ip domain-lookupip name-server 171.69.2.132ip name-server 198.92.30.32ip multicast-routingip dvmrp route-limit 20000bridge irb!interface FastEthernet1no ip addressno ip directed-broadcastno keepalive!interface FastEthernet1.128ip address 172.68.16.10 255.255.255.0ip helper-address 172.68.16.15no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1encapsulation isl 128!interface FastEthernet1.199ip address 172.68.17.15 255.255.255.0ip helper-address 172.68.16.16ip helper-address 172.68.16.17ip helper-address 172.68.16.18no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1encapsulation isl 199!interface FastEthernet1.201ip address 172.68.18.10 255.255.255.0ip helper-address 172.68.16.16ip helper-address 172.68.16.17ip helper-address 172.68.16.18no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1encapsulation isl 201!interface FastEthernet2no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet3no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet4no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet5no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet6no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet7no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet8no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet9ip address 172.68.19.10 255.255.255.0ip helper-address 172.68.16.16ip helper-address 172.68.16.17ip helper-address 172.68.16.18no ip redirectsno ip directed-broadcastip pim dense-modeip multicast ttl-threshold 1ip sdr listenno keepalive!interface FastEthernet10no ip addressno ip directed-broadcastno keepaliveshutdown!interface FastEthernet11no ip addressno ip directed-broadcastno keepaliveshutdown!.(Information Deleted).interface GigabitEthernet41snoop interface FastEthernet3 direction bothsnoop interface FastEthernet5 direction bothsnoop interface FastEthernet6 direction bothip address 172.68.21.10 255.255.255.0ip helper-address 172.68.16.19ip helper-address 172.68.16.20ip helper-address 172.68.16.21!interface GigabitEthernet42ip address 172.68.1.1 255.255.255.0no ip directed-broadcastip pim sparse-dense-mode!interface BVI1ip address 171.201.1.2 255.255.255.0no ip directed-broadcastip pim dense-modeno ip route-cache cef!interface Ethernet0ip address 172.68.20.10 255.255.255.0no ip directed-broadcast!router eigrp 170network 171.200.0.0network 171.201.0.0network 172.68.0.0network 172.69.0.0no auto-summary!router bgp 180network 172.68.1.0network 172.69.1.0no auto-summary!ip classless!bridge 1 protocol ieeebridge 1 route ip!ip http server!line con 0line aux 0line vty 0 4login!ntp clock-period 17181168ntp update-calendarntp server 171.71.150.52ntp server 171.69.4.143ntp server 171.69.5.10endExample of an IOS Layer 3 Switch with HSRP
This example configuration for an IOS Layer 3 switch focuses on the HSRP, which provides high network availability. HSRP makes network topology changes transparent to the host. The active router is monitored by other standby routers, and as soon as an active router becomes unavailable, the standby router takes its place. Helper addresses facilitate connectivity by forwarding certain broadcasts to a target server.
Figure 3 shows the topology of an IP network with two Layer 3 switches configured for HSRP.
Figure 3 HSRP Example Network Topology
In this network:
•
•
•
•
Note
If the connection between Device A and the client accessing virtual server IP address 10.10.10.12 tcp 23 or 10.10.10.18 tcp 23 fails, fast converging routing protocols, such as OSPF and the Enhanced Interior Gateway Routing Protocol (Enhanced IGRP), can respond within seconds, ensuring that Device B is prepared to transfer packets that would have gone through Device A.
The following is the configuration for Device A (active):
hostname Device A!ip slb serverfarm ServerGroup1real 172.20.100.3inservicereal 172.20.100.4inservice!ip slb serverfarm ServerGroup2real 172.20.200.3inservicereal 172.20.200.4inservice!ip slb vserver VS1virtual 10.10.10.12 tcp 23serverfarm ServerGroup1in-service standby Web-Group1!ip slb vserver VS2virtual 10.10.10.18 tcp 23serverfarm ServerGroup2in-service standby Web-Group2!ip routingrouter ripnetwork 172.20.0.0!interface vlan100ip address 172.20.100.1 255.255.255.0standby 100 ip 172.20.100.10standby 100 priority 110standby 100 preempt delay 910standby 100 timers 5 15standby 100 name Web-Group1standby 100 authentication Secret!interface vlan200ip address 172.20.200.1 255.255.255.0standby 200 ip 172.20.200.10standby 200 priority 110standby 200 preempt delay 910standby 200 timers 5 15standby 200 name Web-Group2standby 200 authentication Covert!The following is the configuration for Device B (standby):
hostname Device B!ip slb serverfarm ServerGroup1real 172.20.100.3inservicereal 172.20.100.4inservice!ip slb serverfarm ServerGroup2real 172.20.200.3inservicereal 172.20.200.4inservice!ip slb vserver VS1virtual 10.10.10.12 tcp 23serverfarm ServerGroup1in-service standby Web-Group1!ip slb vserver VS2virtual 10.10.10.18 tcp 23serverfarm ServerGroup2in-service standby Web-Group2!ip routingrouter ripnetwork 172.20.0.0!interface vlan100ip address 172.20.100.2 255.255.255.0standby 100 ip 172.20.100.10standby 100 preempt delay 910standby 100 timers 5 15standby 100 name Web-Group1standby 100 authentication Secret!interface vlan200ip address 172.20.200.2 255.255.255.0standby 200 ip 172.20.200.10standby 200 preempt delay 910standby 200 timers 5 15standby 200 name Web-Group2standby 200 authentication CovertThe standby ip interface configuration command enables HSRP and establishes 10.10.10.12 and 10.10.10.18 as the IP addresses of the virtual servers. The configurations of both Layer 3 switches include this command so that both switches share the same virtual IP address. The numbers 100 and 200 establish Hot Standby groups 100 and 200. (If you do not specify a group number, the default is group 0.) The numbers 100 and 200 in the following commands indicate that they apply to Hot Standby groups 100 and 200, respectively. The configuration for at least one of the Layer 3 switches in the Hot Standby group must specify the IP address of the virtual server; specifying the IP address of the virtual router is optional for other routers in the same Hot Standby group.
The standby preempt interface configuration command allows the Layer 3 switch to become the active switch when its priority is higher than all other HSRP-configured switches in this Hot Standby group. The configurations of both switches include this command so that each can be the standby Layer 3 switch for the other switch. If you do not use the standby preempt command in the configuration for a Layer 3 switch, that switch cannot become the active Layer 3 switch.
The standby priority interface configuration command sets the Layer 3 switch's HSRP priority to 110, which is higher than the default priority of 100. Only the configuration of Device A includes this command, which makes Device A the default active Layer 3 switch.
The standby timers interface configuration command sets the interval (in seconds) between hello messages (called the hello time) to 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 standby name interface configuration command associates the IOS SLB interface with an HSRP group name (in this case, Web-Group1 or Web-Group2), previously specified on an inservice (virtual server) command.
The standby authentication interface configuration command establishes an authentication string whose value is an unencrypted eight-character string that is incorporated in each HSRP multicast message. This command is optional. If you choose to use it, each HSRP-configured Layer 3 switch in the group should use the same string so that each switch can authenticate the source of the HSRP messages that it receives.
Example of a Layer 3 Switch Configured with IOS SLB
Figure 4 shows an example configuration with IOS SLB server connections configured as part of a server farm, using real and virtual servers over Fast Ethernet interfaces.
Figure 4 Network Configuration for IOS SLB
As shown in the following sample configuration, the example topology has three public Web servers and two restricted Web servers for privileged clients in subnet 10.4.4.x. The public Web servers are weighted according to their capacity, with server 10.1.1.2 having the lowest capacity and having a connection limit imposed on it. The restricted Web servers are configured as members of the same sticky group, so that HTTP connections and Secure Socket Layer (SSL) connections from the same client use the same real server.
The network configuration to provide the previously described IOS SLB functionality follows:
! Unrestricted Web server farmip slb serverfarm PUBLIC! Use weighted least connections algorithmpredictor leastconns! First real serverreal 10.1.1.1weight 16inservice! Second real serverreal 10.1.1.2weight 4! Restrict maximum number of connectionsmaxconns 1000inservice! Third real serverreal 10.1.1.3weight 24inservice! Restricted Web server farmip slb serverfarm RESTRICTED! Use weighted least connections algorithmpredictor leastconns! First real serverreal 10.1.1.20in-service! Second real serverreal 10.1.1.21in-service!! Unrestricted Web virtual serverip slb vserver PUBLIC_HTTP! Handle HTTP requestsvirtual 10.0.0.1 tcp www! Use public Web server farmserverfarm PUBLICinservice!! Restricted HTTP virtual serverip slb vserver RESTRICTED_HTTP! Handle HTTP requestsvirtual 10.0.0.1 tcp www! Use restricted Web server farmserverfarm RESTRICTED! Only allow clients from 10.4.4.xclient 10.4.4.0 255.255.255.0! Couple connections with RESTRICTED_SSLsticky 60 group 1inservice!! Restricted SSL virtual serverip slb vserver RESTRICTED_SSL! Handle SSL requestsvirtual 10.0.0.1 tcp https! Use restricted Web server farmserverfarm RESTRICTED! Only allow clients from 10.4.4.xclient 10.4.4.0 255.255.255.0! Couple connections with RESTRICTED_WEBsticky 60 group 1inserviceExample of IOS SLB with NAT Configuration
Figure 5 shows an example configuration with IOS SLB real server connections configured as part of a server farm, focusing on the configuration of the NAT server and address pool of clients.
Figure 5 Sample IOS SLB NAT Topology
The topology in Figure 5 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.
The configuration statements for Switch A are:
ip slb serverfarm FARM1! Translate server addressesnat server! Server 1 port 80real 10.1.1.1inservice! Server 2 port 80real 10.2.1.1inservice!ip slb vserver HTTP1! Handle HTTP (port 80) requestsvirtual 128.1.0.1 tcp wwwserverfarm FARM1inserviceThe configuration statements for Switch B are:
ip slb natpool web-clients 128.3.0.1 128.3.0.254! NAT address pool for clientsip slb serverfarm FARM2! Translate server addressesnat server! Translate client addressesnat client web-clients! Server 3 port 80real 10.3.1.1inservice! Server 4 port 8080real 10.4.1.1 port 8080inservice! Server 4 port 8081real 10.4.1.1 port 8081inservice! Server 4 port 8082real 10.4.1.1 port 8082inservice!ip slb vserver HTTP2! Handle HTTP (port 80) requestsvirtual 128.2.0.1 tcp wwwserverfarm FARM2inserviceThe configuration statements for Switch C are:
ip slb natpool web-clients 128.5.0.1 128.5.0.254! NAT address pool for clientsip slb serverfarm FARM2! Translate server addressesnat server! Translate client addressesnat client web-clients! Server 3 port 80real 10.3.1.1inservice! Server 4 port 8080real 10.4.1.1 port 8080inservice! Server 4 port 8081real 10.4.1.1 port 8081inservice! Server 4 port 8082real 10.4.1.1 port 8082inservice!ip slb vserver HTTP2! Handle HTTP (port 80) requestsvirtual 128.4.0.1 tcp wwwserverfarm FARM2inserviceExample of IOS SLB with an HTTP Probe Configuration
Figure 6 shows an example configuration with IOS SLB real server connections configured as part of a server farm, focusing on using HTTP probe to monitor the IOS SLB connections.
Figure 6 Sample HTTP Probe Topology
:
The topology shown in Figure 6 is a heterogeneous server farm servicing a single virtual server. Following are the Catalyst 4840G switch router configuration statements for this topology:
!ip slb probe TREADER httprequest method post url /probe.cgi?allheader Cookiecredentials Semisweet chips!ip slb serverfarm XEBECreal 10.0.0.1inserviceprobe TREADER!Example of IOS SLB with Stateful Backup Configuration
This example configuration focuses on the IOS SLB real server connections configured as part of a server farm, with real and virtual servers over Fast Ethernet interfaces configured with stateful backup standby connections.
Figure 7 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 traffic to 10.10.3.100, which is the HSRP address on the server side interfaces. The client (or access router), routes to the virtual IP address (10.10.10.12) through 10.10.2.100, HSRP address on the client side.
Notice the loopback interfaces configured on both boxes for the exchange of these messages. Each IOS SLB should also be given duplicate routes to the other switch loopback address. This allows replication messages to flow despite an interface failure.
Note
Figure 7 IOS SLB Stateful Environment
Following is the stateful backup configuration for switch SLB1 shown in Figure 7:
!ip slb serverfarm SF1nat serverreal 10.10.3.1inservicereal 10.10.3.2inservicereal 10.10.3.3inservice!ip slb vserver VS1virtual 10.10.10.12 tcp telnetserverfarm SF1replicate casa 10.10.99.132 10.10.99.99 1024 password PASSinservice standby virt!interface Loopback1ip address 10.10.99.132 255.255.255.255!interface FastEthernet1ip address 10.10.3.132 255.255.255.0no ip redirectsno ip mroute-cachestandby priority 5 preempt delay 910standby name outstandby ip 10.10.3.100standby track FastEthernet2!interface FastEthernet2ip address 10.10.2.132 255.255.255.0no ip redirectsstandby priority 5 preempt delay 910standby name virtstandby ip 10.10.2.100standby track FastEthernet1!Following is the stateful backup configuration for switch SLB2 shown in Figure 7:
ip slb serverfarm SF1nat serverreal 10.10.3.1inservicereal 10.10.3.2inservicereal 10.10.3.3inservice!ip slb vserver VS1virtual 10.10.10.12 tcp telnetserverfarm SF1replicate casa 10.10.99.99 10.10.99.132 1024 password PASSinservice standby virt!interface Loopback1ip address 10.10.99.99 255.255.255.255!interface FastEthernet2ip address 10.10.2.99 255.255.255.0no ip redirectsno ip route-cacheno ip mroute-cachestandby priority 10 preempt delay 910standby name virtstandby ip 10.10.2.100standby track FastEthernet3!interface FastEthernet3ip address 10.10.3.99 255.255.255.0no ip redirectsno ip route-cacheno ip mroute-cachestandby priority 10 preempt delay 910standby name outstandby ip 10.10.3.100standby track FastEthernet2Example of IOS SLB with Redistribution of Static Routes
Figure 8 shows an IOS SLB network configured to distribute static routes to a virtual server's IP address. The route to the address is added to the routing table as static if you advertise the address when you bring the virtual server into service (using the inservice command). See the advertise command for more details about advertising virtual server IP addresses.
Because the routing configuration varies from protocol to protocol, sample configurations for several different routing protocols are given.
Figure 8 IOS SLB Redistribution of Static Routes
Routing Information Protocol (RIP)
Following is the RIP static route redistribution configuration for the SLB switch shown in Figure 8:
router ripredistribute staticnetwork 10.0.0.0network 8.0.0.0Following is the RIP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 8:
router ripnetwork 10.0.0.0network 8.0.0.0Open Shortest Path First (OSPF)
Following is the OSPF static route redistribution configuration for the SLB switch shown in Figure 8:
router ospf 1redistribute static subnetsnetwork 10.10.6.217 0.0.0.0 area 0network 8.8.8.0 0.0.0.255 area 0Following is the OSPF static route redistribution configuration for the access router that is listening for routing updates shown in Figure 8:
router ospf 1network 10.10.6.2 0.0.0.0 area 0network 8.8.8.0 0.0.0.255 area 0Interior Gateway Routing Protocol (IGRP)
Following is the IGRP static route redistribution configuration for the SLB switch shown in Figure 8:
router igrp 1redistribute connectedredistribute staticnetwork 8.0.0.0network 10.0.0.0Following is the IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 8:
router igrp 1network 8.0.0.0network 10.0.0.0Enhanced Interior Gateway Routing Protocol (Enhanced IGRP)
Following is the Enhanced IGRP static route redistribution configuration for the SLB switch shown in Figure 8:
router eigrp 666redistribute staticnetwork 10.0.0.0network 8.0.0.0Following is the Enhanced IGRP static route redistribution configuration for the access router that is listening for routing updates shown in Figure 8:
router eigrp 666network 10.0.0.0network 8.0.0.0Command Reference
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(1)T command reference publications.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
advertise
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.
advertise
no advertise
Syntax 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
Usage Guidelines
HTTP probes require a route to the virtual server. The route is not used, but it must exist in order for HTTP probes to function correctly. The route can be either a host route (advertised by the virtual server) or a default route (specified using the ip route 0.0.0.0 0.0.0.0 command, for example). If you specify no advertise, you must specify a default route.
Examples
The following example prevents advertisement of the virtual server's IP address in routing protocol updates:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# no advertiseRelated Commands
agent
To configure a DFP agent, 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 [timeout [retry_count [retry_interval]]]
no agent ip-address port
Syntax Description
Defaults
Timeout default: 0 seconds (no timeout)
Retry_count default: 0 (infinite retries)
Retry_interval default: 180 seconds
Command Modes
DFP configuration
Command History
Usage Guidelines
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 may reside on the server, or it may 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:
Router(config)# ip slb dfpRouter(config-slb-dfp)# agent 17.17.17.17 22Related Commands
bindid
To configure a bind ID, use the bindid server farm configuration command. To remove a bind ID from the server farm configuration, use the no form of this command.
bindid [bind_id]
no bindid [bind_id]
Syntax Description
Defaults
Bind_id default: 0
Command Modes
Server farm configuration
Command History
Usage Guidelines
You can configure one bind ID on each bindid command.
The bind ID allows a single physical server to be bound to multiple virtual servers and report a different weight for each one. Thus, the single real server is represented as multiple instances of itself, each having a different bind ID. DFP uses the bind ID to identify for which instance of the real server a given weight is specified.
Examples
The following example configures bind ID 309:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# bindid 309Related Commands
ip slb dfp
Configures the IOS SLB DFP.
Displays information about the SLB server farms.
clear ip slb
To clear IP SLB connections or counters, use the clear ip slb command.
clear ip slb {connections [serverfarm farm_name | vserver server_name] | counters}
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example clears the connection database of server farm FARM1:
Router# clear ip slb connections serverfarm FARM1The following example clears the connection database of virtual server VSERVER1:
Router# clear ip slb connections vserver VSERVER1The following example clears the SLB counters:
Router# clear ip slb countersRelated Commands
Displays information about the SLB connections.
Displays information about the SLB server farms.
Displays IOS SLB statistics.
Displays information about the SLB virtual servers.
client
To define which clients are allowed to use the virtual server, use the client virtual server configuration command. You can use more than one client command to define more than one client. To remove a client definition from the IOS SLB configuration, use the no form of this command.
client ip-address network-mask
no client ip-address network-mask
Syntax Description
ip-address
Client IP address. The default is 0.0.0.0 (all clients).
network-mask
Client IP network mask. The default is 0.0.0.0 (all subnetworks).
Defaults
Ip_address default: 0.0.0.0 (all clients)
Network_mask default: 0.0.0.0 (all subnetworks)
Taken together, the default is client 0.0.0.0 0.0.0.0 (allows all clients on all subnetworks to use the virtual server).
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The network-mask value is applied to the source IP address of incoming connections. The result must match the ip-address value for the client to be allowed to use the virtual server.
Examples
The following example allows only clients from 10.4.4.x access to the virtual server:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# client 10.4.4.0 255.255.255.0Related Commands
Displays information about the virtual servers.
virtual
Configures the virtual server attributes.
credentials
To configure basic authentication values for the HTTP SLB probe, use the credentials configuration command. To remove a credentials configuration, use the no form of this command.
credentials {username} [password]
no credentials {username} [password]
Syntax Description
Defaults
No default behavior or values.
Command Modes
HTTP probe configuration
Command History
Examples
The following example configures an HTTP probe named TREADER, 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 TREADER httpRouter(config-slb-probe)# credentials lauren developRelated Commands
delay
To change the amount of time IOS SLB maintains TCP connection context after a connection has terminated, use the delay virtual server configuration command. To restore the default delay timer, use the no form of this command.
delay duration
no delay
Syntax Description
duration
Delay timer duration in seconds. The valid range is 1 to 600 seconds. The default value is 10 seconds.
Defaults
Duration default: 10 seconds
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The delay timer allows out-of-sequence packets and final acknowledgments (ACKs) to be delivered after a TCP connection ends.
Do not set this value to zero (0).
If you are configuring a delay timer for HTTP traffic, choose a low number such as 5 seconds as a starting point.
Examples
The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# delay 30Related Commands
Displays information about the virtual servers.
virtual
Configures the virtual server attributes.
expect
To configure a status code to expect from the HTTP probe, use the expect configuration command. To remove a status code configuration, use the no form of this command.
expect status number
no expect status number
Syntax Description
Defaults
No default expected status code is 4XX.
Command Modes
HTTP probe configuration
Command History
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:
•
•
•
Examples
The following example configures an HTTP probe named TREADER, changes the CLI to HTTP submode, and configures the HTTP probe to expect the status code 40l:
Router(config)# ip slb probe TREADER httpRouter(config-slb-probe)# expect status 401Related Commands
faildetect
To specify the conditions that indicate a server failure, use the faildetect real server configuration command. To restore the default values that indicate a server failure, use the no form of this command.
faildetect numconns number-conns [numclients number-clients]
no faildetect
Syntax Description
Defaults
If the faildetect command is not specified, the default value of the connection reassignment threshold is 8.
If the numclients keyword is not specified, the default value of the unique client failure threshold is 2.
Command Modes
Real server configuration
Command History
Examples
In the following example the connection reassignment threshold is set to 16 and, because the number-clients keyword is not configured, the threshold for unique client connection failure is set to the default value 8. The real server is considered to have failed when 8 unique clients have had connection failures and there have been 16 connection reassignments.
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# faildetect numconns 16Related Commands
real
Identifies a real server.
Displays information about the server farm configuration.
Displays information about the real servers.
header
To configure the basic authentication values for the HTTP probe, use the header HTTP probe configuration command. To remove a header HTTP probe configuration, use the no form of this command.
header field-name [field-value]
no header field-name [field-value]
Syntax Description
field-name
Configures the name of the HTTP probe header. The character string is limited to 15 characters.
field-value
(Optional) Configures the value of the HTTP probe header.
Defaults
No default behavior or values, although the following headers are inserted in the server script by default:
Accept: */*Connection: closeUser-Agent: cisco-slb-probe/1.0Host: virtual IP addressCommand Modes
HTTP probe configuration
Command History
Usage Guidelines
The header HTTP probe command configures authentication parameters of the header.
Note
Examples
The following example configures an HTTP probe named TREADER, changes the CLI to HTTP submode, and configures the HTTP probe header name as Cookie:
Router(config)# ip slb probe TREADER httpRouter(config-slb-probe)# header CookieRelated Commands
idle
To specify the minimum amount of time IOS SLB maintains connection information in the absence of packet activity, use the idle virtual server configuration command. To restore the default idle duration value, use the no form of this command.
idle duration
no idle
Syntax Description
duration
Idle connection timer duration in seconds. Valid values range from 10 to 65535. The default is 3600 seconds (1 hour).
Defaults
Duration default: 3600 seconds
Command Modes
Virtual server configuration
Command History
Usage Guidelines
TCP connections that do not send traffic or keepalives before the idle timer expires are assumed to be inactive and are reset (RST).
If you are configuring an idle timer for HTTP traffic, choose a low number such as 120 seconds as a starting point. A low number ensures that the IOS SLB connection database maintains a manageable size if problems at the server, client, or network result in a large number of connections. However, do not choose a value under 60 seconds; such a low value can reduce the efficiency of IOS SLB.
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# idle 120Related Commands
Displays information about the virtual servers.
virtual
Configures the virtual server attributes.
inservice (real server)
To enable the real server for use by IOS SLB, use the inservice real server configuration command. To remove the real server from service, use the no form of this command.
inservice
no inservice
Syntax Description
This command has no arguments or keywords.
Defaults
If the inservice command is not specified, the real server is defined to IOS SLB but is not used.
Command Modes
Real server configuration
Command History
Examples
The following example enables the real server for use by the IOS SLB feature:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# inserviceRelated Commands
real
Identifies a real server.
Displays information about the server farm configuration.
Displays information about the real servers.
inservice (virtual server)
To enable the virtual server for use by IOS SLB, use the inservice virtual server configuration command. To remove the virtual server from service, use the no form of this command.
inservice [standby group-name]
no inservice [standby group-name]
Syntax Description
Defaults
If the inservice command is not specified, the virtual server is defined to IOS SLB but is not used.
Command Modes
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.
Examples
The following example enables the real server for use by the IOS SLB feature:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# inserviceRelated Commands
Displays information about the virtual servers.
virtual
Configures the virtual server attributes.
interval (HTTP Probe)
To configure an HTTP probe interval, use the interval configuration command. To remove an HTTP probe interval configuration, use the no form of this command.
interval seconds
no interval seconds
Syntax Description
seconds
Designates the number of seconds to wait before reattempting the probe. Valid values range from 1-65535 seconds.
Defaults
The default interval value is 8 seconds.
Command Modes
HTTP probe configuration
Command History
Examples
The following example configures an HTTP probe named TREADER, changes the CLI to HTTP submode, configures the HTTP probe timer interval to transmit every 11 seconds:
Router(config)# ip slb probe TREADER httpRouter(config-slb-probe)# interval 11Related Commands
ip slb dfp
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 password [timeout]]
no ip slb dfp
Syntax Description
Defaults
Timeout default: 180 seconds
Command Modes
Global configuration
Command History
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 password to flounder, and configures a timeout period of 60 seconds and changes to DFP agent configuration mode:
Router(config)# ip slb dfp flounder 60Router(config-slb-dfp)#Related Commands
ip slb entries
To configure an initial allocation and a maximum value for SLB database entries, use the ip slb entries global configuration command. To restore the default values, use the no form of this command.
ip slb entries [conn [init-conn [max-conn]] | frag [init-frag [max-frag]] | sticky [init-sticky [max-sticky]] ]
no ip slb entries [conn | frag | sticky]
Syntax Description
Defaults
For connections, the default initial allocation is 8000 connections, and the default maximum is 8000000 connections.
For fragments, the default initial allocation is 4000 fragments, and the default maximum is 8000000 fragments.
For sticky connections, the default initial allocation is 2000 sticky connections, and the default maximum is 3200 sticky connections.
Command Modes
Global configuration
Command History
Usage Guidelines
If you configure an initial allocation value that exceeds the amount of available memory, memory may not be available for other features. In extreme cases, the router or switch may not boot properly. Therefore, be careful when you configure initial allocation values.
Examples
The following example configures an initial allocation of 128,000 connections, which can grow dynamically to a limit of 512,000 connections:
Router(config)# ip slb entries conn 128000 512000Related Commands
Displays all connections handled by IOS SLB, or, optionally, only those connections associated with a particular virtual server or client.
ip slb natpool
To configure an IOS SLB NAT, use the ip slb natpool configuration command to create at least one client address pool. To remove an ip slb natpool configuration, use the no form of this command.
ip slb natpool pool-name start-ip end-ip [netmask netmask | prefix-length leading_1_bits] [entries init-addr [max-addr]]
no ip slb natpool pool-name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
If you want to use client NAT, you must create at least one client address pool.
Examples
The following example configures an IOS SLB NAT server farm pool of addresses with the name web-clients, the IP address range from 128.3.0.1 through 128.3.0.254, and a subnet mask of 255.255.0.0:
Router(config)# ip slb natpool web-clients 128.3.0.1 128.3.0.254 netmask 255.255.0.0Related Commands
ip slb probe
To configure an HTTP probe name and to change to HTTP probe configuration submode, use the ip slb probe configuration command. To remove an ip slb probe configuration, use the no form of this command.
ip slb probe name http
no ip slb probe name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
This command configures the HTTP probe name and application protocol. The ip slb probe command also changes the user interface to HTTP submode.
The HTTP probe cannot be unconfigured while it is being used by the server farm.
Only one HTTP probe can be configured per server farm.
Note
Examples
The following example configures an IOS SLB probe with TREADER, then changes to HTTP configuration submode:
Router(config)# ip slb probe TREADER httpRouter(config-slb-probe)#Related Commands
ip slb serverfarm
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
no ip slb serverfarm serverfarm-name
Syntax Description
serverfarm-name
Character string used to identify the server farm. The character string is limited to 15 characters.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Grouping real servers into server farms is an essential part of IOS SLB. Using server farms enables IOS SLB to assign new connections to the real servers based on their weighted capacities, and on the load balancing algorithms used.
Examples
The following example identifies a server farm named PUBLIC:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)#?Related Commands
ip slb vserver
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
no 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
Examples
The following example identifies a virtual server named PUBLIC_HTTP:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)#Related Commands
serverfarm
Associates a real server farm with a virtual server.
Displays information about the virtual servers.
maxconns
To limit the number of active connections to the real server, use the maxconns real server configuration command. To restore the default of no limit, use the no form of this command.
maxconns maximum-number
no maxconns
Syntax Description
maximum-number
Maximum number of simultaneous active connections on the real server. Valid values range from 1 to 4294967295. The default is 4294967295.
Defaults
Maximum_number default: 4294967295
Command Modes
Real server configuration
Command History
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# maxconns 1000Related Commands
real
Identifies a real server.
Displays information about the server farm configuration.
Displays information about the real servers.
nat
To configure IOS SLB NAT and specify a NAT mode, use the nat configuration command. To remove a NAT configuration, use the no form of this command.
nat {server | client pool-name}
no nat {server | client}
Syntax Description
Defaults
None
Command Modes
Server farm configuration
Command History
12.1(1)E
This command was introduced.
12.1(2)E
The client keyword and pool-name variable were added.
Usage Guidelines
The no nat command is allowed only if the virtual server was removed from service with the no inservice command.
Examples
The following example changes to IOS SLB server farm configuration mode and configures NAT mode as server address translation on server farm FARM2:
Router# ip slb serverfarm FARM2Router(config-slb-sfarm)# nat serverThe following example configures the NAT mode on server farm FARM2 to client translation mode and using the real command configures the real server IP address as 10.3.1.1:
Router(config-slb-sfarm)# nat client web-clientsRouter(config-slb-sfarm)# real 10.3.1.1Related Commands
Associates a real server farm with a virtual server.
Identifies a real server as a member of a server farm.
Displays information about the server farm configuration.
predictor
To specify the load balancing algorithm for selecting a real server in the server farm, use the predictor server farm configuration command. To restore the default load balancing algorithm of weighted round robin, use the no form of this command.
predictor [roundrobin | leastconns]
no predictor
Syntax Description
roundrobin
(Optional) 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
Examples
The following example specifies the weighted least connections algorithm:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# predictor leastconnsRelated Commands
Displays information about the server farm configuration.
weight
Specifies the real server's capacity, relative to other real servers in the server farm.
probe
To associate a probe with a server farm, use the probe server farm configuration command. To remove the association, use the no form of this command.
probe name
no probe name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
Examples
The following example associates probe TREADER with server farm PUBLIC:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# probe TREADERRelated Commands
real
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]
no real ip-address [port_number]
Syntax Description
ip-address
Real server IP address.
port_number
Port translation for the server. Valid values range from 1 to 65535.
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
12.0(7)XE
This command was introduced.
12.1(2)E
The port-number variable was added.
Usage Guidelines
A server farm comprises a number of real servers. The real servers are the physical devices that provide the load balanced services.
Examples
The following example identifies a real server as a member of the server farm:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.1.1.1Router(config-slb-real)#Related Commands
Enables the real server for use by IOS SLB.
Displays information about the server farm configuration.
Displays information about the real servers.
reassign
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
no reassign
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 command's numconns keyword is not exceeded. See the faildetect 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
Examples
The following example sets the threshold of unanswered SYNs to 2:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# reassign 2Related Commands
real
Identifies a real server.
Displays information about the server farm configuration.
Displays information about the real servers.
replicate casa
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 password timeout]
no replicate casa listen-ip remote-ip com-port
Syntax Description
Defaults
The interval default is 10 seconds.
The password timeout default is 180 seconds.
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The timeout option allows you to change the password without stopping messages between the backup and primary Layer 3 switches. The default value is 180 seconds.
During the timeout, the backup sends packets with the old password (or null, if there is no old password), and receives packets with either the old or new password. After the timeout expires, the backup sends and receives packets only with the new password.
When setting a new password timeout, keep the following in mind:
•
•
Examples
The following example configures a stateful backup Layer 3 switch with a listening IP address of 10.10.10.11, a remote IP address of 10.10.11.12, over HTTP port 4231:
Router(config)# ip slb vserver VS1Router(config-slb-vserver)# replicate casa 10.10.10.11 10.10.11.12 4231Related Commands
Displays the configuration of IOS SLB IP replication.
Displays information about the virtual servers.
request method, request url
To configure an HTTP probe to check the status of the real servers, use the request method/url configuration command. To remove a request method/url configuration, use the no form of this command.
request [method {get | post | head | name name}] [url path]
no request [method {get | post | head | name name}] [url path]
Syntax Description
Defaults
If no values are configured following the method keyword, the default is Get.
If no URL path is set to the server, the default is /.
Command Modes
HTTP SLB probe configuration
Command History
Usage Guidelines
The request method/url command configures the IOS SLB HTTP probe method used to receive data from the server. Only one IOS SLB HTTP probe can be configured for each server farm.
Examples
The following example configures an IOS SLB HTTP probe named TREADER, changes the CLI to SLB probe submode, and configures HTTP requests to use the post method and the URL /probe.cgi?all:
Router(config)# ip slb probe TREADER httpRouter(config-slb-probe)# request method post url /probe.cgi?allRelated Commands
Configures the IOS SLB IP probe name.
Displays an IOS SLB HTTP probe configuration.
retry
To specify how long to wait before a new connection is attempted to a failed server, use the retry real server configuration command. To restore the default retry value, use the no form of this command.
retry retry-value
no retry
Syntax Description
Defaults
The retry-value default is 60 seconds.
Command Modes
Real server configuration
Command History
Examples
The following example specifies that 120 seconds must elapse after the detection of a server failure before a new connection is attempted:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# retry 120Related Commands
real
Identifies a real server.
Displays information about the server farm configuration.
Displays information about the real servers.
serverfarm
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
no serverfarm
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
Examples
The following example shows how the ip slb vserver, virtual, and serverfarm commands are used to associate the real server farm named PUBLIC with the virtual server named PUBLIC_HTTP.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# virtual 10.0.0.1 tcp wwwRouter(config-slb-vserver)# serverfarm PUBLICRelated Commands
Displays information about the virtual servers.
virtual
Configures the virtual server attributes.
show ip slb conns
To display the active IOS SLB connections, use the show ip slb conns privileged EXEC command.
show ip slb conns [vserver virtserver-name] [client ip-address] [detail]
Syntax Description
Defaults
If no options are specified, the command displays output for all active IOS SLB connections.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB active connection data:
router# show ip slb connsvserver prot client real state----------------------------------------------------------------------------TEST TCP 7.150.72.183:328 80.80.90.25:80 CLOSINGTEST TCP 7.250.167.226:423 80.80.90.26:80 CLOSINGTEST TCP 7.234.60.239:317 80.80.90.26:80 CLOSINGTEST TCP 7.110.233.96:747 80.80.90.26:80 CLOSINGTEST TCP 7.162.0.201:770 80.80.90.30:80 CLOSINGTEST TCP 7.22.225.219:995 80.80.90.26:80 CLOSINGTEST TCP 7.2.170.148:169 80.80.90.30:80 CLOSINGTable 1 show ip slb conns Command Field Information
show ip slb dfp
To display DFP manager and agent information, such as passwords, timeouts, retry counts, and weights, use the show ip slb dfp privileged EXEC command.
show ip slb dfp [agent ip_address port | detail | weights]
Syntax Description
Defaults
If no options are specified, the command displays summary information.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB DFP data:
router# show ip slb dfp detailDFP Manager:Current passwd:NONE Pending passwd:NONEPasswd timeout:0 secUned errors:0DFP Agent 161.44.2.34:61936 Connection state:ConnectedTimeout = 0 Retry Count = 0 Interval = 180 (Default)Security errors = 0Last message received:10:20:26 UTC 11/02/99Last reported Real weights for Protocol TCP, Port wwwHost 17.17.17.17 1 Weight 1Host 68.68.68.68 Bind ID 4 Weight 4Host 85.85.85.85 Bind ID 5 Weight 5Last reported Real weights for Protocol TCP, Port 22Host 17.17.17.17 Bind ID 111 Weight 111router# show ip slb dfp weightsReal IP Address 17.17.17.17 Protocol TCP Port 22 Bind_ID 111 Weight 111Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99Real IP Address 17.17.17.17 Protocol TCP Port www Bind_ID 1 Weight 1Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99Real IP Address 68.68.68.68 Protocol TCP Port www Bind_ID 4 Weight 4Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99Real IP Address 85.85.85.85 Protocol TCP Port www Bind_ID 5 Weight 5Set by Agent 161.44.2.3458490 at 132241 UTC 12/03/99router# show ip slb dfpDFP Manager:Current passwd:NONE Pending passwd:NONEPasswd timeout:0 secAgent IP Port Timeout Retry Count Interval---------------------------------------------------------------161.44.2.34 61936 0 0 180 (Default)Table 2 show ip slb dfp Command Field Information
show ip slb natpool
To display the IP SLB NAT configuration, use the show ip slb natpool command.
show ip slb natpool [name pool-name] [detail]
Syntax Description
name
Keyword to display a specific NAT pool.
pool-name
NAT pool name string to display.
detail
Lists all the interval ranges currently allocated in the client NAT pool.
Defaults
No default behavior or values.
Command Modes
EXEC configuration
Command History
Examples
The following example displays the default show ip slb natpool command:
Router# show ip slb natpoolnat client B 1.1.1.6 1.1.1.8 Netmask 255.255.255.0nat client A 1.1.1.1 1.1.1.5 Netmask 255.255.255.0The following example displays the show ip slb natpool command with the additional detail parameter:
Router# show ip slb natpool detailnat client A 1.1.1.1 1.1.1.5 Netmask 255.255.255.0Start NAT Last NAT Count ALLOC/FREE-------------------------------------------------------1.1.1.1:11001 1.1.1.1:16333 0005333 ALLOC1.1.1.1:16334 1.1.1.1:19000 0002667 ALLOC1.1.1.1:19001 1.1.1.5:65535 0264675 FREEnat client B 1.1.1.6 1.1.1.8 Netmask 255.255.255.0Start NAT Last NAT Count ALLOC/FREE-------------------------------------------------------1.1.1.6:11001 1.1.1.6:16333 0005333 ALLOC1.1.1.6:16334 1.1.1.6:19000 0002667 ALLOC1.1.1.6:19001 1.1.1.8:65535 0155605 FREERelated Commands
show ip slb probe
To display an IOS SLB HTTP 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.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB HTTP probe data:
Router# show ip slb probeServer:Port Status Outages Current Cumulative----------------------------------------------------------10.11.2.2:80 200 0 never 00:00:00
show ip slb reals
To display information about the real servers, use the show ip slb reals privileged EXEC command.
show ip slb reals [vserver virtserver-name] [detail]
Syntax Description
Defaults
If no options are specified, the command displays information about all real servers.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB real server data:
router# show ip slb realsreal server farm weight state conns--------------------------------------------------------------------80.80.2.112 FRAG 8 OUTOFSERVICE 080.80.5.232 FRAG 8 OPERATIONAL 080.80.15.124 FRAG 8 OUTOFSERVICE 080.254.2.2 FRAG 8 OUTOFSERVICE 080.80.15.124 LINUX 8 OPERATIONAL 080.80.15.125 LINUX 8 OPERATIONAL 080.80.15.126 LINUX 8 OPERATIONAL 080.80.90.25 SRE 8 OPERATIONAL 22080.80.90.26 SRE 8 OPERATIONAL 21680.80.90.27 SRE 8 OPERATIONAL 21680.80.90.28 SRE 8 TESTING 180.80.90.29 SRE 8 OPERATIONAL 22180.80.90.30 SRE 8 OPERATIONAL 22480.80.30.3 TEST 100 READY_TO_TEST 080.80.30.4 TEST 100 READY_TO_TEST 080.80.30.5 TEST 100 READY_TO_TEST 080.80.30.6 TEST 100 READY_TO_TEST 0Table 4 show ip slb reals Command Field Information
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.
server farm
Name of the server farm to which the real server.
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.
•
•
•
•
•
•
•
•
•
show ip slb replicate
To display the SLB replication configuration, use the show ip slb replicate privileged EXEC command.
show ip slb replicate
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example displays the SLB replication configuration:
Router# show ip slb replicate VS1, local = 10.10.99.132 remote = 10.10.99.99 port = 1024 current password = none pending password = none password timeout = 180 sec (Default) unsent conn updates: 0 conn updates received: 32 conn updates transmitted: 471 update packets received: 12 update packets transmitted: 34 failovers: 0 Router#Table 5 describes the fields shown in the display.
Related Commands
show ip slb serverfarms
To display information about the server farms, use the show ip slb serverfarms privileged EXEC command.
show ip slb serverfarms [name serverfarm-name] [detail]
Syntax Description
name
(Optional) Displays information about only a particular server farm.
serverfarm-name
(Optional) Name of the server farm.
detail
(Optional) Displays detailed server farm information.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB server farm data:
router# show ip slb serverfarmsserver farm predictor reals bind id-------------------------------------------------FRAG ROUNDROBIN 4 0LINUX ROUNDROBIN 3 0SRE ROUNDROBIN 6 0TEST ROUNDROBIN 4 0Table 6 show ip slb serverfarms Command Field Information
show ip slb stats
To display IOS SLB statistics, use the show ip slb stats privileged EXEC command.
show ip slb stats
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows IOS SLB statistics:
router# show ip slb statsPkts via normal switching: 530616Pkts via special switching:1812710Connections Created: 783774Connections Established: 633418Connections Destroyed: 782752Connections Reassigned: 0Zombie Count: 0Table 7 show ip slb stats Command Field Information
show ip slb sticky
To display the IOS SLB sticky database, use the show ip slb sticky privileged EXEC command.
show ip slb sticky [client ip_address]
Syntax Description
client
(Optional) Displays only those sticky database entries associated with a particular client IP address.
ip-address
(Optional) IP address of the client.
Defaults
If no options are specified, the command displays information about all virtual servers.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows the IOS SLB sticky database:
Router# show ip slb stickyclient netmask group real conns-----------------------------------------------------------------------10.10.2.12 255.255.0.0 4097 10.10.3.2 1Router#
show ip slb vservers
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
Examples
The following example shows virtual server data:
router# show ip slb vserversslb vserver prot virtual state conns---------------------------------------------------------------------TEST TCP 80.80.254.3:80 OPERATIONAL 1013TEST21 TCP 80.80.254.3:21 OUTOFSERVICE 0TEST23 TCP 80.80.254.3:23 OUTOFSERVICE 0Table 9 show ip slb vservers Command Field Information
standby authentication
To configure an authentication string for the Hot Standby Router Protocol (HSRP), use the standby authentication interface configuration command. To delete an authentication string, use the no form of this command.
standby [group-number] authentication string
no standby [group-number] authentication string
Syntax Description
group-number
(Optional) Group number on the interface to which this authentication string applies.
string
Authentication string. It can be up to eight characters in length.
Defaults
The group number default is 0.
The string default is cisco.
Command Modes
Interface configuration
Command History
Usage Guidelines
The authentication string is transmitted unencrypted in all HSRP messages. The same authentication string must be configured on all routers and access servers on a cable to ensure interoperation. Authentication mismatch prevents a device from learning the designated Hot Standby IP address and the Hot Standby timer values from other routers configured with HSRP. Authentication mismatch does not prevent protocol events such as one router taking over as the designated router.
When group number 0 is used, no group number is written to NVRAM, providing backward compatibility.
Examples
In the following example, "word" is configured as the authentication string required to allow Hot Standby routers in group 1 to interoperate:
Router(config)# interface fastethernet 1Router(config-if)# standby 1 authentication wordstandby name
To specify an HSRP group name with which to associate an IOS SLB interface, use the standby name interface configuration command. To remove the group name association on the interface, use the no form of this command.
standby [group-number] name group-name
no standby [group-number] name group-name
Syntax Description
group-number
(Optional) Group number of the interface to which the timers apply. The default is 0.
group-name
Specifies the HSRP group name with which the IOS SLB virtual server is associated.
Defaults
The default group number is 0.
Command Modes
Interface configuration
Command History
Usage Guidelines
The HSRP group name must first be specified on the inservice (virtual server) command.
Examples
In the following example, HSRP is enabled for group number 1, group name Web-Group, on Ethernet port 0 on the EIP that is installed in slot 5:
Router(config)# interface Ethernet5/0Router(config-if)# ip address 172.18.48.154 255.255.255.128Router(config-if)# standby 1 ip 172.18.48.124Router(config-if)# standby 1 priority 2 preempt delay 910Router(config-if)# standby 1 name Web-GroupRelated Commands
standby priority, standby preempt
To configure Hot Standby Router Protocol (HSRP) priority, preemption, and preemption delay, use the standby interface configuration command. To restore the default values, use the no form of this command.
standby [group-number] priority priority [preempt [delay delay]]
standby [group-number] [priority priority] preempt [delay delay]
no standby [group-number] priority priority [preempt [delay delay]]
no 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
(Optional) The router is configured to preempt, which means that when the local router has a Hot Standby priority higher than the current active router, the local router should attempt to assume control as the active router. If preempt is not configured, the local router assumes control as the active router only if it receives information indicating that there is no router currently in the active state (acting as the designated router).
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). The default value is 0 seconds (if the router wants to preempt, it will do so immediately).
Note
For example, if you use the default idle (3600 seconds) and the default interval (10 seconds), specify a delay of at least (3600/4) + 10 = 910 seconds.
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
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 910 seconds (15 minutes and 10 seconds) before attempting to become the active router:
Router(config)# interface fastethernet 1Router(config-if)# standby ip 172.19.108.254Router(config-if)# standby priority 120 preempt delay 910Related Commands
Configures the standby track on an interface so that the Hot Standby priority changes based on the availability of other interfaces.
standby timers
To configure the time between hellos and the time before other routers declare the active Hot Standby or standby router to be down, use the standby timers interface configuration command. To restore the timers to their default values, use the no form of this command.
standby [group-number] timers hellotime holdtime
no standby [group-number] timers hellotime holdtime
Syntax Description
Defaults
The default group number is 0.
The default hellotime is 3 seconds.
The default holdtime is 3 seconds.
Command Modes
Interface configuration
Command History
Usage Guidelines
The standby timers command configures the time between standby hellos and the time before other routers declare the active or standby router to be down. Routers or access servers on which timer values are not configured can learn timer values from the active or standby router. The timers configured on the active router always override any other timer settings. All routers in a Hot Standby group should use the same timer values. Normally, holdtime is greater than or equal to 3 times hellotime (holdtime > 3 * hellotime).
When group number 0 is used, no group number is written to NVRAM, providing backward compatibility.
Examples
In the following example, for group number 1 on Fast Ethernet interface 1, the time between hello packets is set to 5 seconds, and the time after which a router is considered to be down is set to 15 seconds:
Router(config)# interface fastethernet 1Router(config-if)# standby 1 ipRouter(config-if)# standby 1 timers 5 15standby track
To configure an interface so that the Hot Standby priority changes based on the availability of other interfaces, use the standby track interface configuration command. To remove the tracking, use the no form of this command.
standby [group-number] track type number [interface-priority]
no standby [group-number] track type number [interface-priority]
Syntax Description
