Downloads |
Table Of Contents
IOS SLB Functions and Capabilities
Algorithms for Server Load Balancing
Client-Assigned Load Balancing
Delayed Removal of TCP Connection Context
Automatic Server Failure Detection
Dynamic Feedback Protocol for IOS SLB
Transparent Web Cache Balancing
Redundancy Enhancement—Stateless Backup
Supported Standards, MIBs, and RFCs
Specifying a Server Farm (Required)
Specifying a Load-Balancing Algorithm (Optional)
Specifying a Bind ID (Optional)
Specifying a Real Server (Required)
Configuring Real Server Attributes (Optional)
Enabling the Real Server for Service (Required)
Specifying a Virtual Server (Required)
Associating a Virtual Server with a Server Farm (Required)
Configuring Virtual Server Attributes (Required)
Adjusting Virtual Server Values (Optional)
Preventing Advertisement of Virtual Server Address (Optional)
Enabling the Virtual Server for Service (Required)
Configuring IOS SLB Dynamic Feedback Protocol (Optional)
Implementing IOS SLB Stateless Backup (Optional)
How IOS SLB Stateless Backup Works
Configuring IOS SLB Stateless Backup
Verifying the IOS SLB Stateless Backup Configuration
Sample IOS SLB Stateless Backup Configuration
Verifying IOS SLB Installation
Verifying Server Failure Detection
Monitoring and Maintaining IOS SLB
Sample IOS SLB Network Configuration
IOS Server Load Balancing
This feature module describes the Cisco IOS Server Load Balancing (SLB) feature for Cisco IOS Release 12.1(1)E. It includes the following sections:
•
Supported Standards, MIBs, and RFCs
•
Feature Overview
The IOS SLB feature is an IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, the network administrator defines a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. In this environment the clients are configured to connect to the IP address of the virtual server. The virtual server IP address is configured as a loopback address, or secondary IP address, on each of the real servers. When a client initiates a connection to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured load-balancing algorithm.
Note
Figure 1 illustrates IOS SLB.
Figure 1
Logical View of IOS SLB
IOS SLB Functions and Capabilities
This section describes the following functions and capabilities supported in IOS SLB:
•
•
•
•
•
•
•
•
Algorithms for Server 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
Port-Bound Servers
When you define a virtual server, you must specify the TCP or UDP port handled by that virtual server. However, if you configure NAT on the server farm, you can also configure port-bound servers. Port-bound servers allow one virtual server IP address to represent one set of real servers for one service, such as Hypertext Transfer Protocol (HTTP), and a different set of real servers for another service, such as Telnet.
Packets destined for a virtual server address for a port that is not specified in the virtual server definition are not redirected.
IOS SLB supports both port-bound and non-port-bound servers, but port-bound servers are recommended.
Client-Assigned Load Balancing
Client-assigned load balancing allows you to limit access to a virtual server by specifying the list of client IP subnets that are permitted to use that virtual server. With this feature, you can assign a set of client IP subnets (such as internal subnets) connecting to a virtual IP address to one serverfarm, and assign another set of clients (such as external clients) to a different serverfarm.
Content Flow Monitor Support
IOS SLB supports the Cisco Content Flow Monitor (CFM), a Web-based status monitoring application within the CiscoWorks2000 product family. You can use CFM to manage Cisco server load-balancing devices. CFM runs on Windows NT and Solaris workstations, and is accessed using a Web browser.
Sticky Connections
When you use sticky connections, new connections from a client IP address or subnet are assigned to the same real server as were previous connections from that address or subnet.
IOS SLB creates sticky objects to track client assignments. The sticky objects remain in the IOS SLB database after the last sticky connection is deleted, for a period defined by a configurable sticky timer. If the timer is configured on a virtual server, new connections from a client are sent to the same real server that handled the previous client connection, provided one of the following is true:
•
•
Sticky connections also permit the coupling of services that are handled by more than one virtual server. This allows connection requests for related services to use the same real server. For example, Web server (HTTP) typically uses TCP port 80, and HTTP over Secure Socket Layer (HTTPS) uses port 443. If HTTP virtual servers and HTTPS virtual servers are coupled, connections for ports 80 and 443 from the same client IP address or subnet are assigned to the same real server.
Maximum Connections
The maximum connections feature allows you to configure a limit on the number of active connections that a real server can handle.
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.
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.
Automatic Server Failure Detection
IOS SLB automatically detects each failed Transmission Control Protocol (TCP) connection attempt to a real server, and increments a failure counter for that server. (The failure counter is not incremented if a failed TCP connection from the same client has already been counted.) If a server's failure counter exceeds a configurable failure threshold, the server is considered out of service and is removed from the list of active real servers.
Automatic Unfail
When a real server fails and is removed from the list of active servers, it is assigned no new connections for a length of time specified by a configurable retry timer. After that timer expires, the server is again eligible for new virtual server connections and IOS SLB sends the server the next connection for which it qualifies. 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.
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.
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.
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.
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.
Transparent Web Cache Balancing
You can balance transparent Web caches if you know in advance the IP addresses they are serving. In IOS SLB, configure the IP addresses, or some common subset of them, as virtual servers.
Note
NAT
Cisco IOS Network Address Translation (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:
•
•
The main advantage of dispatched mode is performance. In dispatched mode, the Layer 3 and Layer 4 addresses are not modified so IP header checksum adjustment is fast, and checksum adjustment or recalculation for TCP or UDP is not required. Dispatched mode is also simpler because packets for applications with IP addresses in the packet do not have to be examined and modified.
The main disadvantage of dispatched mode is that the virtual server IP address is not modified, so the real servers must be Layer 2 adjacent with the load balancer or intervening routers may not be able to route to the chosen real server.
NAT (directed mode) is used to solve these dispatched mode problems.
IOS SLB currently supports only server NAT. By replacing the virtual server IP address with the real server IP address (and vice versa), servers can be many hops away from the load balancer and intervening routers can route to them without requiring tunnelling. Additionally, loopback and secondary interfaces need no longer be on the real server.
Note
The network designer must ensure that outbound packets travel through IOS SLB, using one of the following methods:
•
•
•
A less common form of server NAT is server port translation, which involves replacement of a virtual server port. Server port translation does not require server IP address translation, but the two translations can be used together.
Redundancy Enhancement—Stateless Backup
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 a stateless backup option you can use to reduce that risk. Stateless backup, based on Hot Standby Router Protocol (HSRP), provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of a single Layer 3 switch.
HSRP is configured on Layer 3 switches that run IP over Ethernet. If a Layer 3 switch fails, HSRP automatically allows another Layer 3 switch to assume the function of the failing switch. HSRP is therefore particularly useful when you require continuous access to resources in the network.
HSRP is compatible with Novell's Internetwork Packet Exchange (IPX) and with AppleTalk.
Note
Benefits
IOS SLB shares the same software code base as Cisco IOS and has all the software features sets of Cisco IOS software. IOS SLB is recommended for customers desiring complete integration of SLB technology into traditional Cisco switches and routers.
On the Cisco Catalyst 6500 switch, IOS SLB takes advantage of hardware acceleration to forward data packets at very high speed when running in dispatched mode.
IOS SLB assures continuous, high availability of content and applications with proven techniques for actively managing servers and connections in a distributed environment. By distributing user requests across a cluster of servers, IOS SLB optimizes responsiveness and system capacity, and dramatically reduces the cost of providing Internet, database, and application services for large-scale as well as small- and medium- sized sites.
IOS SLB facilitates scalability, availability, and ease of maintenance:
•
•
•
Administration of server applications is easier. Clients know only about virtual servers; no administration is required for real server changes.
Security of the real server is provided because its address is never announced to the external network. Users are familiar only with the virtual IP address. You can filter unwanted flows based on both IP address and TCP or UDP port numbers. Additionally, though it does not eliminate the need for a firewall, IOS SLB can help protect against some denial-of-service attacks.
In a branch office, IOS SLB allows balancing of multiple sites and disaster recovery in the event of full-site failure, and distributes the work of load balancing.
Restrictions
IOS SLB has the following restrictions:
•
•
•
•
•
•
•
–
–
–
–
–
–
•
–
–
–
Supported Platforms
•
•
Supported Standards, MIBs, and RFCs
Standards
•
MIBs
•
RFCs
•
Configuration Tasks
Configuring IOS SLB involves identifying server farms, configuring groups of real servers in server farms, and configuring the virtual servers that represent the real servers to the clients. See the following sections for configuration tasks for the IOS SLB feature. Perform these tasks in the order given. Some of the tasks are required; others are optional.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Specifying a Server Farm (Required)
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.
To configure a server farm, use the following command in global configuration mode:
Specifying a Load-Balancing Algorithm (Optional)
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.) To specify the load-balancing algorithm, use the following command in server farm configuration mode:
Specifying a Bind ID (Optional)
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.
Specifying a Real Server (Required)
A server farm comprises a number of real servers. The real servers are the physical devices that provide the load-balanced services.
To identify a real server in your network, use the following command in server farm configuration mode:
Identifies a real server to the IOS SLB function and initiates real server configuration mode. See the real command for more details.
Configuring Real Server Attributes (Optional)
You can configure any of the following real server attributes, by using the following commands in real server configuration mode:
Enabling the Real Server for Service (Required)
To place the real server into service, use the following command in real server configuration mode:
Enables the real server for use by IOS SLB. See the inservice (real server) command for more details.
Specifying a Virtual Server (Required)
To specify a virtual server, use the following command in global configuration mode:
Identifies a virtual server and initiates virtual server configuration mode. See the ip slb vserver command for more details.
Associating a Virtual Server with a Server Farm (Required)
To associate the virtual server with a server farm, use the following command in virtual server configuration mode:
Associates a real server farm with a virtual server. See the serverfarm command for more details.
Configuring Virtual Server Attributes (Required)
To configure virtual server attributes, use the following command in virtual server configuration mode:
Adjusting Virtual Server Values (Optional)
To change the default settings of the virtual server values, use the related command in virtual server configuration mode:
Preventing Advertisement of Virtual Server Address (Optional)
By default, virtual server addresses are advertised. That is, static routes to the Null0 interface are installed for the virtual server addresses. To advertise these static routes using the routing protocol, you must configure redistribution of static routes for the routing protocol. To prevent the installation of a static route, use the no form of the advertise command, in virtual server configuration mode:
Omits the virtual server IP address from the routing protocol updates. See the advertise command for more details.
Enabling the Virtual Server for Service (Required)
To place the virtual server into service, use the following command in virtual server configuration mode:
Enables the virtual server for use by IOS SLB. See the inservice (virtual server) command for more details.
Configuring IOS SLB Dynamic Feedback Protocol (Optional)
To configure IOS SLB DFP, enter the following commands in order, beginning in global configuration mode:
Configuring NAT (Optional)
To configure IOS SLB NAT mode for a specific server farm, enter the following commands in order, beginning in global configuration mode:
Implementing IOS SLB Stateless Backup (Optional)
Stateless backup, based on the Hot Standby Router Protocol (HSRP), provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of any single Layer 3 switch. Stateless backup is particularly useful for hosts that do not support a router discovery protocol (such as the Intermediate System-to-Intermediate System [IS-IS] Interdomain Routing Protocol [IDRP]) and do not have the functionality to shift to a new Layer 3 switch when their selected Layer 3 switch reloads or loses power.
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 IOS SLB switches, perform the following tasks in order:
Step 1
Step 2
Step 3
Note
Step 4
Step 5
Step 6
Step 7
Step 8
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:
Enables HSRP.
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 4:
Router(config-if)# standby 100 ip 172.20.100.10Router(config-if)# standby 100 priority 110Router(config-if)# standby 100 preemptRouter(config-if)# standby 100 timers 5 15Router(config-if)# standby 100 name Web_group1Router(config-if)# standby 100 authentication SecretRouter(config-if)# exitRouter#Verifying IOS SLB
This section describes how to verify the following different aspects of the IOS SLB feature:
•
•
Verifying IOS SLB Installation
To verify that the IOS SLB is installed and working properly, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
Step 6
Step 7
Step 8
Verifying Server Failure Detection
To verify that server failures are detected correctly, follow these steps:
Step 1
Step 2
Step 3
•
•
•
Troubleshooting IOS SLB
The following questions and answers can help you troubleshoot IOS SLB, if you have problems.
Monitoring and Maintaining IOS SLB
To obtain and display runtime information about IOS SLB, use the following commands in EXEC mode:
Configuration Examples
This section provides the following IOS SLB configuration examples:
•
Sample IOS SLB Network Configuration
This section provides a configuration example based on the network layout shown in Figure 2.
Figure 2 IOS SLB Network Configuration
As shown in the following sample code, 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.
This configuration is coded as follows:
ip slb serverfarm PUBLIC Unrestricted Web server farmpredictor leastconns Use weighted least connections algorithmreal 10.1.1.1 First real serverweight 16inservicereal 10.1.1.2 Second real serverweight 4maxconns 1000 Restrict maximum number of connectionsinservicereal 10.1.1.3 Third real serverweight 24inserviceip slb serverfarm RESTRICTED Restricted Web server farmpredictor leastconns Use weighted least connections algorithmreal 10.1.1.20 First real serverin-servicereal 10.1.1.21 Second real serverin-serviceip slb vserver PUBLIC_HTTP Unrestricted Web virtual servervirtual 10.0.0.1 tcp www Handle HTTP requestsserverfarm PUBLIC Use public Web server farminserviceip slb vserver RESTRICTED_HTTP Restricted HTTP virtual servervirtual 10.0.0.1 tcp www Handle HTTP requestsserverfarm RESTRICTED Use restricted Web server farmclient 10.4.4.0 255.255.255.0 Only allow clients from 10.4.4.xsticky 60 idle 120 group 1 Couple connections with RESTRICTED_SSLinserviceip slb vserver RESTRICTED_SSL Restricted SSL virtual servervirtual 10.0.0.1 tcp https Handle SSL requestsserverfarm RESTRICTED Use restricted Web server farmclient 10.4.4.0 255.255.255.0 Only allow clients from 10.4.4.xsticky 60 idle 120 group 1 Couple connections with RESTRICTED_HTTPinserviceSample NAT Configuration
This section provides a configuration example based on the network layout shown in Figure 3.
Figure 3 IOS SLB NAT Topology
The topology in Figure 3 has four Web servers, configured as follows:
•
•
Servers 1 and 2 are load balanced using Switch A, which is performing server address translation.
Servers 3 and 4 are load balanced using Switches B and C. These two switches are performing server address translation. These switches also 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 serverfarm FARM2! Translate server addressesnat server! 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 serverfarm FARM2! Translate server addressesnat server! 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 FARM2inserviceSample HSRP Configuration
Figure 4 shows the topology of an IP network with two Layer 3 switches configured for HSRP. In this network:
•
•
•
•
Note
If the connection between Device A and the client accessing virtual IP 1.0.0.3 fails, fast-converging routing protocols (such as Enhanced IGRP and OSPF) can respond within seconds, ensuring that Device B is prepared to transfer packets that would have gone through Device A.
Figure 4 HSRP Example Network Topology
The following is the configuration for Device A:
hostname Device Ainterface GigabitEthernet 41ip address 1.0.0.1 255.0.0.0standby 1 ip 1.0.0.3standby 1 preemptstandby 1 priority 110standby 1 authentication denmarkstandby 1 timers 5 15standby 1 name Web-Groupinterface FastEthernet 1ip address 3.0.0.1 255.0.0.0router eigrp 1network 1.0.0.0network 3.0.0.0The following is the configuration for Device B:
hostname Device Binterface GigabitEthernet 41ip address 1.0.0.2 255.0.0.0standby 1 ip 1.0.0.3standby 1 preemptstandby 1 authentication denmarkstandby 1 timers 5 15standby 1 name Web-Groupinterface FastEthernet 41ip address 2.0.0.1 255.0.0.0router eigrp 1network 1.0.0.0network 2.0.0.0The standby ip interface configuration command enables HSRP and establishes 1.0.0.3 as the IP address of the virtual router. The configurations of both Layer 3 switches include this command so that both switches share the same virtual IP address. The number 1 establishes Hot Standby group 1. (If you do not specify a group number, the default is group 0.) The configuration for at least one of the Layer 3 switches in the Hot Standby group must specify the IP address of the virtual router; specifying the IP address of the virtual router is optional for other routers in the same Hot Standby group.
The standby preempt interface configuration command allows the Layer 3 switch to become the active switch when its priority is higher than all other HSRP-configured switches in this Hot Standby group. The configurations of both switches include this command so that each can be the standby Layer 3 switch for the other switch. The number 1 indicates that this command applies to Hot Standby group 1. If you do not use the standby preempt command in the configuration for a Layer 3 switch, that switch cannot become the active Layer 3 switch.
The standby priority interface configuration command sets the Layer 3 switch's HSRP priority to 110, which is higher than the default priority of 100. Only the configuration of Device A includes this command, which makes Device A the default active Layer 3 switch. The number 1 indicates that this command applies to Hot Standby group 1.
The standby authentication interface configuration command establishes an authentication string whose value is an unencrypted eight-character string that is incorporated in each HSRP multicast message. This command is optional. If you choose to use it, each HSRP-configured Layer 3 switch in the group should use the same string so that each switch can authenticate the source of the HSRP messages that it receives. The number 1 indicates that this command applies to Hot Standby group 1.
The standby timers interface configuration command sets the interval (in seconds) between hello messages (called the hello time) to five seconds, and sets the interval (in seconds) that a Layer 3 switch waits before it declares the active Layer 3 switch to be down (called the hold time) to eight seconds. (The defaults are three and 10 seconds, respectively.) To modify the default values, you must configure each Layer 3 switch to use the same hello time and hold time. The number 1 indicates that this command applies to Hot Standby group 1.
The standby name interface configuration command associates the IOS SLB interface with an HSRP group name (in this case, Web-Group), previously specified on an inservice (virtual server) command. The number 1 indicates that this command applies to Hot Standby group 1.
Command Reference
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 and 12.0(7)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
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
The default timeout is 0 seconds (no timeout).
The default retry count is 0 (infinite retries).
The default retry interval is 180 seconds.
Command Modes
DFP configuration
Command History
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 on the DFP manager, sets the DFP password to Cookies and the timeout to 360 seconds, changes the CLI to DFP configuration mode, sets the IP address of the DFP agent to 10.1.1.1, and sets the port number of the DFP agent to 2221 (FTP):
Router(config)# ip slb dfp password Cookies 360Router(config-slb-dfp)# agent 10.1.1.1 2221Related Commands
bindid
To configure a bind ID, use the bindid server farm configuration command. To remove a bind ID from the server farm configuration, use the no form of this command.
bindid [bind_id]
no bindid [bind_id]
Syntax Description
Defaults
The default bind ID is 0.
Command Modes
Server farm configuration
Command History
Usage Guidelines
You can configure one bind ID on each bindid command.
The bind ID allows a single physical server to be bound to multiple virtual servers and report a different weight for each one. Thus, the single real server is represented as multiple instances of itself, each having a different bind ID. DFP uses the bind ID to identify for which instance of the real server a given weight is specified.
Examples
The following example configures bind ID 309:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# bindid 309Related Commands
clear ip slb
To clear IP IOS SLB connections or counters, use the clear ip slb command.
clear ip slb {connections [serverfarm farm_name | vserver server_name] | counters}
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following example clears the connection database of server farm FARM1:
Router# clear ip slb connections serverfarm FARM1
The following example clears the connection database of virtual server VSERVER1:
Router# clear ip slb connections vserver VSERVER1
The following example clears the IOS SLB counters:
Router# clear ip slb counters
Related Commands
Displays information about the IOS SLB server farms.
Displays information about the IOS SLB virtual servers.
Displays information about the IOS SLB connections.
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
The default IP address is 0.0.0.0 (all clients).
The default network mask is 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.
Configures the virtual server attributes.
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
The default duration is 10 seconds.
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The delay timer allows out-of-sequence packets and final acknowledgments (ACKs) to be delivered after a TCP connection ends.
Do not set this value to zero (0).
If you are configuring a delay timer for HTTP flows, choose a low number such as 5 seconds as a starting point.
Examples
The following example specifies that IOS SLB maintains TCP connection context for 30 seconds after a connection has terminated:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# delay 30Related Commands
Displays information about the virtual servers.
virtual
Configures the virtual server attributes.
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 you do not specify the faildetect command, the default value of the connection reassignment threshold is 8.
If you do not specify the numclients keyword, the default value of the unique client failure threshold is 2.
Command Modes
Real server configuration
Command History
Examples
In the following example the connection reassignment threshold is set to 16 and, because the number-clients keyword is not configured, the threshold for unique client connection failure is set to the default value 8. The real server is considered to have failed when 8 unique clients have had connection failures and there have been 16 connection reassignments.
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# faildetect numconns 16Related Commands
real
Identifies a real server.
Displays information about the server farm configuration.
Displays information about the real servers.
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
The default duration is 3600 seconds.
Command Modes
Virtual server configuration
Command History
Usage Guidelines
TCP connections that do not send flows or keepalives before the idle timer expires are assumed to be inactive and are reset (RST).
If you are configuring an idle timer for HTTP flows, choose a low number such as 120 seconds as a starting point. A low number ensures that the IOS SLB connection database maintains a manageable size if problems at the server, client, or network result in a large number of connections. However, do not choose a value under 60 seconds; such a low value can reduce the efficiency of IOS SLB.
Examples
The following example instructs IOS SLB to maintain connection information for an idle connection for 120 seconds.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# idle 120Related Commands
Displays information about the virtual servers.
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 you do not specify the inservice command, 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
standby
(Optional) Configures the HSRP standby virtual server.
groupname
(Optional) Specifies the HSRP group name with which the IOS SLB virtual server is associated.
Defaults
If you do not specify the inservice command, 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.
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
The password timeout default is 180 seconds.
Command Modes
Global configuration
Command History
Usage Guidelines
The optional password, if configured, must match the password configured on the host agent.
The timeout option allows you to change the password without stopping messages between the DFP agent and its manager. The default value is 180 seconds.
During the timeout, the agent sends packets with the old password (or null, if there is no old password), and receives packets with either the old or new password. After the timeout expires, the agent sends and receives packets only with the new password; received packets that use the old password are discarded.
If you are changing the password for an entire load-balanced environment, set a longer timeout. This allows enough time for you to update the password on all agents and servers before the timeout expires. It also prevents mismatches between agents and servers that have begun running the new password and agents, and servers on which you have not yet changed the old password.
Examples
The following example configures DFP, sets the 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 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
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
The default maximum number is 4294967295.
Command Modes
Real server configuration
Command History
Examples
The following example limits the real server to a maximum of 1000 simultaneous active connections:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1Router(config-slb-real)# maxconns 1000Related Commands
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 server farm configuration command. To remove a NAT configuration, use the no form of this command.
nat server
no nat server
Syntax Description
server
Specifies that the destination address in load-balanced packets sent to the real server is the address of the real server chosen by the server farm load-balancing algorithm.
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
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 serverRelated 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
The default predictor is 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.
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
no real ip-address
Syntax Description
Defaults
No default behavior or values.
Command Modes
Server farm configuration
Command History
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.1Related Commands
inservice
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
The default threshold is 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.
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 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 3 show ip slb reals Command Field Information
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 4 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 5 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 group real conns ftp-cntrl--------------------------------------------------------------10.10.2.12 4097 10.10.3.2 1 0Table 6 show ip slb sticky Command Field Information
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 7 show ip slb vservers Command Field Information
standby 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 preemptRouter(config-if)# standby 1 name Web-GroupRelated Commands
sticky
To assign all connections from a client to the same real server, use the sticky virtual server configuration command. To remove the client/server coupling use the no form of this command.
sticky duration [group group-id]
no sticky
Syntax Description
Defaults
Sticky connections are not tracked.
Virtual servers are not associated with any groups.
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The last real server that was used for a connection from a client is stored for the set duration seconds. If a new connection from the client to the virtual server is initiated during that time, the same real server that was used for the previous connection is chosen for the new connection. If two virtual servers are placed in the same group, coincident connection requests for those services from the same IP address are handled by the same real server.
Examples
The following example specifies that if a client's subsequent request for a virtual server is made within 60 seconds of the previous request, then the same real server is used for the connection. This example also places the virtual server in group 10.
Router(config)# ip slb vserver VS1Router(config-slb-vserver)# sticky 60 group 10Related Commands
synguard
To limit the rate of TCP SYNs handled by a virtual server to prevent an SYN flood denial of service attack, use the synguard virtual server configuration command. To remove the threshold, use the no form of this command.
synguard syn-count [interval]
no synguard
Syntax Description
Defaults
The default SYN count is 0 (off).
The default interval is 100 ms.
Command Modes
Virtual server configuration
Command History
Examples
The following example sets the threshold of unanswered SYNs to 50:
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# synguard 50Related Commands
Displays information about the virtual servers.
virtual
Configures the virtual server attributes.
virtual
To configure virtual server attributes, use the virtual virtual server configuration command. To remove the attributes, use the no form of this command.
virtual ip-address {tcp | udp} port-number [service service-name]
no virtual
Syntax Description
Defaults
No default behavior or values.
Command Modes
Virtual server configuration
Command History
Usage Guidelines
The no virtual command is allowed only if the virtual server was removed from service by the no inservice command.
For some applications, it is not feasible to configure all the virtual server TCP or UDP port numbers for IOS SLB. To support such applications, you can configure IOS SLB virtual servers to accept flows destined for all ports. To configure an all-port virtual server, specify a port number of 0.
Note
Examples
The following example specifies that the virtual server with the IP address 10.0.0.1 performs load balancing for TCP connections for the port named www. The virtual server processes HTTP requests.
Router(config)# ip slb vserver PUBLIC_HTTPRouter(config-slb-vserver)# virtual 10.0.0.1 tcp wwwRelated Commands
ip slb vserver
Identifies a virtual server.
Displays information about the virtual servers.
weight
To specify a real server's capacity, relative to other real servers in the server farm, use the weight real server configuration command. To restore the default weight value, use the no form of this command.
weight weighting-value
no weight
Syntax Description
weighting-value
Weighting value to use for real server predictor algorithm. Valid values range from 1 to 155. The default weighting value is 8.
Defaults
The default weighting-value is 8.
Command Modes
Real server configuration
Command History
Examples
The following example specifies the relative weighting values of three real servers as 16, 8 (by default), and 24, respectively:
Router(config)# ip slb serverfarm PUBLICRouter(config-slb-sfarm)# real 10.10.1.1 First real serverRouter(config-slb-real)# weight 16 Assigned weight of 16Router(config-slb-real)# inservice EnabledRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.10.1.2 Second real serverRouter(config-slb-real)# inservice Enabled; default weightRouter(config-slb-real)# exitRouter(config-slb-sfarm)# real 10.10.1.3 Third real serverRouter(config-slb-real)# weight 24 Assigned weight of 24; not enabledRelated Commands
real
Identifies a real server.
Displays information about the server farm configuration.
Displays information about the real servers.
Debug Commands
This section documents the following new debug command related to the IOS SLB feature:
debug ip slb
To display debug messages for IOS SLB, use the debug ip slb EXEC command. To stop debug output, use the no form of this command.
debug ip slb {conns | dfp | icmp | reals | all}
no debug ip slb {conns | dfp | icmp | reals | all}
Syntax Description
Defaults
No default behavior or values.
Command History
Usage Guidelines
See the following caution before using debug commands:
Caution
Examples
The following example configures a debug session to check all IP IOS SLB parameters:
Router# debug ip slb all
SLB All debugging is on
Router#
The following example stops all debugging:
Router# no debug all
All possible debugging has been turned off
Router#
The following example shows IOS SLB DFP debug output:
router# debug ip slb dfpSLB DFP debugging is onrouter#022048 SLB DFP Queue to main queue - type 2 for Agent 161.44.2.3458229022048 SLB DFP select_rc = -1 readset = 0022048 SLB DFP Sleeping ...022049 SLB DFP readset = 0022049 SLB DFP select_rc = -1 readset = 0022049 SLB DFP Processing Q event for Agent 161.44.2.3458229 - OPEN022049 SLB DFP Queue to conn_proc_q - type 2 for Agent 161.44.2.3458229022049 SLB DFP readset = 0022049 SLB DFP Set SLB_DFP_SIDE_QUEUE022049 SLB DFP Processing Conn Q event for Agent 161.44.2.3458229 - OPEN022049 SLB DFP Open to Agent 161.44.2.3458229 succeeded, socket = 0022049 SLB DFP Agent 161.44.2.3458229 start connect022049 SLB DFP Connect to Agent 161.44.2.3458229 successful - socket 0022049 SLB DFP Queue to main queue - type 6 for Agent 161.44.2.3458229022049 SLB DFP Processing Conn Q unknown MAJOR 80022049 SLB DFP Reset SLB_DFP_SIDE_QUEUE022049 SLB DFP select_rc = -1 readset = 0022049 SLB DFP Sleeping ...022050 SLB DFP readset = 1022050 SLB DFP select_rc = 1 readset = 1022050 SLB DFP Agent 161.44.2.3458229 fd = 0 readset = 1022050 SLB DFP Message length 44 from Agent 161.44.2.3458229022050 SLB DFP Agent 161.44.2.3458229 setting Host 17.17.17.17, Bind ID 1 Weight 1022050 SLB DFP Agent 161.44.2.3458229 setting Host 34.34.34.34, Bind ID 2 Weight 2022050 SLB DFP Agent 161.44.2.3458229 setting Host 51.51.51.51, Bind ID 3 Weight 3022050 SLB DFP Processing Q event for Agent 161.44.2.3458229 - WAKEUP022050 SLB DFP readset = 1022050 SLB DFP select_rc = 1 readset = 1022050 SLB DFP Agent 161.44.2.3458229 fd = 0 readset = 1022050 SLB DFP Message length 64 from Agent 161.44.2.3458229022050 SLB DFP Agent 161.44.2.3458229 setting Host 17.17.17.17, Bind ID 1 Weight 1022050 SLB DFP Agent 161.44.2.3458229 setting Host 68.68.68.68, Bind ID 4 Weight 4022050 SLB DFP Agent 161.44.2.3458229 setting Host 85.85.85.85, Bind ID 5 Weight 5022050 SLB DFP Agent 161.44.2.3458229 setting Host 17.17.17.17, Bind ID 111 Weight 111022050 SLB DFP readset = 1022115 SLB DFP Queue to main queue - type 5 for Agent 161.44.2.3458229022115 SLB DFP select_rc = -1 readset = 0022115 SLB DFP Sleeping ...022116 SLB DFP readset = 1022116 SLB DFP select_rc = -1 readset = 0022116 SLB DFP Processing Q event for Agent 161.44.2.3458229 - DELETE022116 SLB DFP Queue to conn_proc_q - type 5 for Agent 161.44.2.3458229022116 SLB DFP readset = 1022116 SLB DFP Set SLB_DFP_SIDE_QUEUE022116 SLB DFP Processing Conn Q event for Agent 161.44.2.3458229 - DELETE022116 SLB DFP Connection to Agent 161.44.2.3458229 closed022116 SLB DFP Agent 161.44.2.3458229 deleted022116 SLB DFP Processing Conn Q unknown MAJOR 80022116 SLB DFP Reset SLB_DFP_SIDE_QUEUE022116 SLB DFP Set SLB_DFP_SIDE_QUEUE022116 SLB DFP Reset SLB_DFP_SIDE_QUEUE
Glossary
CASA—Content Aware Services Architecture. CASA is a protocol designed to allow network appliances to selectively control the flow of IP packets through a router, switch, or other network device.
cluster—Set of computer systems that are connected through multisystem hardware or software to supply services traditionally provided by a single system. This arrangement provides higher availability and better scalability of the system.
content-aware networking—Networking strategy that enables content to be dynamically distributed. Because content can be dynamically cached, it can be located at any given place at any given time and distributed between the servers and the location of the Web cache. Cisco has developed the ContentFlow architecture and the DFP to enable networks to provide content-aware networking services.
ContentFlow architecture—Cisco's content-aware networking architecture that describes message flows and actions in a distributed environment.
DFP—Dynamic Feedback Protocol. Allows host agents to dynamically report the change in status of the host systems providing a virtual service. The status reported is a relative weight that specifies a host server's capacity to perform work.
DFP agent—Host agent in a load-balanced environment that dynamically reports changes in status of the host systems that provide a virtual service. The status reported is a relative weight that specifies a host server's capacity to perform work. See also DFP manager.
DFP manager—Host manager in a load-balanced environment that collects status reports from DFP agents. See also DFP agent.
directed mode—Session redirection mode in which the virtual server can be assigned an IP address that is not known to any of the real servers. IOS SLB translates packets exchanged between a client and real server, translating the virtual server IP address to a real server address through NAT. See also dispatched mode, NAT.
dispatched mode—Session redirection mode in which the virtual server address is known to the real servers. The virtual server IP address must be configured as a loopback address, or secondary IP address, on each of the real servers. IOS SLB redirects packets to the real servers at the media access control (MAC) layer. Since the virtual server IP address is not modified in dispatched mode, the real servers must be Layer 2-adjacent to IOS SLB, or intervening routers might not be able to route to the chosen real server. See also directed mode.
Dynamic Feedback Protocol—See DFP.
Hot Standby Routing Protocol—See HSRP.
HSRP—Hot Standby Router Protocol. Provides high network availability and transparent network topology changes. HSRP creates a Hot Standby router group with a lead router that services all packets sent to the Hot Standby address. The lead router is monitored by other routers in the group, and if it fails, one of these standby routers inherits the lead position and the Hot Standby group address. See also redundancy, stateless backup.
IOS SLB—IOS Server Load Balancing. Load-balancing scheme in which the network administrator defines a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. When a client initiates a connection to the virtual server, IOS SLB chooses a real server for the connection based on a configured load-balancing algorithm.
load balancing—Spreading user requests among available servers within a cluster of servers, based on a variety of algorithms.
MD5—Message Digest Algorithm Version 5. Neighbor router authentication scheme used to ensure reliability and security when routing updates are exchanged between neighbor routers.
Message Digest Algorithm Version 5—See MD5.
NAT—Network Address Translation. Modification of one or more of the following fields in an IP packet: source IP address, destination IP address, source TCP/UDP port, destination TCP/UDP port.
NetFlow switching—High-performance network-layer switching path that captures as part of its switching function a rich set of flow statistics including user, protocol, port, and type of service information.
Network Address Translation—See NAT.
port-bound—Server configuration scheme in which a virtual server IP address represents one set of real servers for one service, such as Hypertext Transfer Protocol (HTTP), and a different set of real servers for another service, such as Telnet.
real server—The specification of a physical server associated with a virtual server. The specification includes the real server's IP address and an optional weight to be used by the virtual server predictor.
redundancy—The duplication of devices, services, or connections so that, in the event of a failure, the redundant devices, services, or connections can perform the work of those that failed. See also stateless backup.
round robin—See weighted round robin.
Secure Socket Layer—See SSL.
server cluster—See server farm.
server farm—Also called a server cluster. Group of real servers that provide various applications and services.
Server Load Balancing—See IOS SLB.
server port translation—Translation scheme in which the virtual server port number is replaced with the real server port number (and vice versa), allowing servers to be many hops away from the load-balancing device, and enabling intervening routers to route to them without requiring tunnelling. See also directed mode.
services manager—Functionality built into IOS SLB that makes load-balancing decisions based on application availability, server capacity, and load distribution algorithms such as weighted round robin or weighted least connections, or the DFP. The services manager determines a real server for the packet flow using load balancing and server/application feedback.
SLB—See IOS SLB.
SSL—Secure Socket Layer. Encryption technology for the Web used to provide secure transactions such as the transmission of credit card numbers for e-commerce.
stateless backup—Redundancy scheme that provides high network availability by routing IP flows from hosts on Ethernet networks without relying on the availability of a single Layer 3 switch.
sticky connections—Load-balancing scheme in which new connections from a client IP address or subnet are assigned to the same real server (for server load balancing) or firewall (for firewall load balancing) as were previous connections from that address or subnet.
virtual server—Presents a single address that represents an application server farm to clients.
weighted least connection—Load-balancing algorithm in which the next real server chosen for a new connection to the virtual server is the server with the fewest active connections. Each real server is assigned a weight, n, that represents its capacity to handle connections, as compared to the other real servers associated with the virtual server. The server with the fewest connections is based on the number of active connections on each server, and on the relative capacity of each server. The capacity of a given real server is calculated as the assigned weight of that server divided by the sum of the assigned weights of all of the real servers associated with that virtual server, or n1/(n1+n2+n3...).
weighted round robin—Load-balancing algorithm in which the real server used for a new connection to the virtual server is chosen in a circular fashion. Each real server is assigned a weight, n, that represents its capacity to handle connections, as compared to the other real servers associated with the virtual server. New connections are assigned to a given real server n times before the next real server in the list is chosen.
workload agents—Value-added software components developed for specific platforms by third-party developers. Workload agents run on server platforms or on platforms that manage server farms. Workload agents deliver server and application information to the services manager. This information enables the services manager to make optimum server selection.
