Configuring Server Load Balancing PDF
Configuring Server Load Balancing PDF
This chapter describes how to configure the IOS Server Load Balancing (SLB) feature. For a complete
description of the SLB commands in this chapter, refer to the Cisco IOS IP Application Services
Command Reference. To locate documentation of other commands that appear in this chapter, use the
command reference master index or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the “Identifying Supported Platforms”
section in the “Using Cisco IOS Software” chapter in this book.
The SLB feature is a Cisco IOS-based solution that provides IP server load balancing. Using the
IOS SLB feature, the network administrator defines a virtual server that represents a group of real
servers in a cluster of network servers known as a server farm. In this environment the clients are
configured to connect to the IP address of the virtual server. The virtual server IP address is configured as a
loopback address, or secondary IP address, on each of the real servers. When a client initiates a connection
to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured
load-balancing algorithm.
IOS SLB shares the same software code base as Cisco IOS software 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 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 sites as well as
small- and medium-sized sites.
IOS SLB facilitates scalability, availability, and ease of maintenance as follows:
• The addition of new physical (real) servers, and the removal or failure of existing servers, can occur
at any time, transparently, without affecting the availability of the virtual server.
• The slow start capability of IOS SLB allows a new server to increase its load gradually, preventing
failures caused by assigning the server too many new connections too quickly.
• IOS SLB supports fragmented packets and packets with IP options, buffering your servers from
client or network vagaries that are beyond your control.
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. Though it does not eliminate the need for a firewall, IOS SLB
also 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.
Figure 23 illustrates a logical view of IOS SLB.
Virtual server
Catalyst 4840G
with IOS SLB
29164
Client Client
Client Client
Note Assigning a weight of n = 1 to all of the servers in the server farm configures the IOS SLB switch to
use a simple round robin algorithm.
Note Assigning a weight of n = 1 to all of the servers in the server farm configures the IOS SLB switch to
use a simple least-connection algorithm.
Port-Bound Servers
When you define a virtual server, you must specify the TCP or UDP port handled by that virtual server.
However, if you configure NAT on the server farm, you can also configure port-bound servers.
Port-bound servers allow one virtual server IP address to represent one set of real servers for one service,
such as HTTP, and a different set of real servers for another service, such as Telnet.
Packets destined for a virtual server address for a port that is not specified in the virtual server definition
are not redirected.
IOS SLB supports both port-bound and nonport-bound servers, but port-bound servers are
recommended.
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 conditions is true:
• A connection for the same client already exists.
• The amount of time between the end of a previous connection from the client and the start of the
new connection is within the timer duration.
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.
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 again 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, the slow start feature controls the number of new
connections that are directed to a real server that has just been placed in service.
SynGuard
The SynGuard feature limits the rate of TCP 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.
Alternate IP Addresses
IOS SLB enables you to Telnet to the load-balancing device using an alternate IP address. To do so, use
either of the following methods:
• Use any of the interface addresses to Telnet to the load-balancing device.
• Define a secondary IP address to Telnet to the load-balancing device.
This function is similar to that provided by the LocalDirector (LD) Alias command.
Note A Web cache can start its own connections to real sites if pages are not available in its cache. Those
connections cannot be load balanced back to the same set of caches. IOS SLB addresses this situation
by allowing you to configure “client exclude” statements so that IOS SLB does not load balance
connections initiated by the Web caches.
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:
• Directed mode—The virtual server can be assigned an IP address that is not known to any of the real
servers. IOS SLB translates packets exchanged between a client and real server, translating the
virtual server IP address to a real server address via NAT.
• Dispatched mode—The virtual server address is known to the real servers; you must configure the
virtual server IP address as a loopback address, or secondary IP address, on each real server. IOS SLB
redirects packets to the real servers at the media access control (MAC) layer. Because 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.
The main advantage of dispatched mode is performance. In dispatched mode, the Layer 3 and Layer 4
addresses are not modified, which means IP header checksum adjustment occurs quickly, and checksum
adjustment or recalculation for TCP or UDP is not required. Dispatched mode is also simpler than in
directed mode because packets for applications with IP addresses in the packet need not be examined
and modified.
The main disadvantage of dispatched mode is that the virtual server IP address is not modified, which
means that 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 tunneling. Additionally, loopback and secondary interfaces
need no longer be on the real server.
Note On the Catalyst 6000 family switches and Cisco 7200 series routers, if an IP address is configured as
a real IP address for a NAT virtual server, you cannot balance connection requests from that address
to a different virtual server (whether NAT or dispatch) on the same load balancer.
The network designer must ensure that outbound packets travel through IOS SLB using one of the
following methods:
• Direct wiring (all packets flow through a branch office IOS SLB device)
• Default gateways or policy-based routing
• IOS SLB NAT of client addresses, enabled as an outbound feature on server-side interfaces
A less common form of server NAT is server port translation, which involves replacement of a virtual
server port. Server port translation does not require server IP address translation, but the two translations
can be used together.
Note To avoid any single point of failure in an IOS SLB network, use multiple Layer 2 switches to provide
connectivity between the IOS SLB devices and the servers.
Restrictions
IOS SLB has the following restrictions:
• Does not support load balancing of flows between clients and real servers that are on the same local
area network (LAN) or virtual LAN (VLAN). The packets being load balanced cannot enter and
leave the load-balancing device on the same interface.
• Operates in a standalone mode and currently does not operate as a MultiNode Load Balancing
(MNLB) Services Manager. The presence of IOS SLB does not preclude the use of the existing
MNLB Forwarding Agent with an external Services Manager in an MNLB environment.
• Does not support coordinating server load-balancing statistics among different IOS SLB instances
for backup capability.
• Supports FTP only in dispatched mode.
• Does not support IOS SLB and Cisco Applications and Services Architecture (CASA) configured
with the same virtual IP address, even if they are for different services.
• Does not support both IOS server load balancing and firewall load balancing on the same flow, nor
on the same server port. You can configure both server load balancing and firewall load balancing
on the same device at the same time, but they must apply to different flows (different client-server
pairs). These functions can run on the same EPIF (for example, server load balancing on port 1 and
firewall load balancing on port 2). Load-balancing the server farm after a packet exits the
load-balanced firewall farm requires a separate load-balancing device.
• When operating in dispatched mode, real servers must be Layer 2-adjacent, tag-switched, or via
generic routing encapsulation (GRE) tunnel.
• When operating in directed mode with server NAT, real servers need not be Layer 2-adjacent to
IOS SLB. This allows for more flexible network design, since servers can be placed several Layer 3
hops away from the IOS SLB switch.
• The DFP agent requires a delay between hello messages of at least 3 seconds. Therefore, if your DFP
manager provides a timeout specification, you must set the timeout to at least 3 seconds.
• For firewall load balancing:
– Limited to a single firewall farm in each load-balancing device.
– Limited to a single active firewall load-balancing device on each side of the firewall farm. Each
firewall must have its own unique MAC address and must be Layer 2-adjacent to each device.
The firewalls can be connected to individual interfaces on the device, or they can all share a
VLAN and connect using a single interface.
– Requires Ethernet between each firewall load-balancing device and each firewall.
– On each firewall load-balancing device, requires that each Layer 2 firewall be connected to a
single Layer 3 (IP) interface.
– Flows with a destination IP address on the same subnet as the configured firewall IP addresses
are not load-balanced. (Such flows could be a firewall console session or other flows on the
firewall LAN.)
– Does not support the following IOS SLB functions:
- Active standby
- Client-assigned load balancing
- Network Address Translation (NAT)
- Port-bound servers
- SynGuard
- TCP session reassignment
- Transparent webcache load balancing
Command Purpose
Router(config)# ip slb serverfarm serverfarm-name Adds a server farm definition to the IOS SLB
configuration and initiates SLB server farm
configuration mode.
Command Purpose
Router(config-slb-sfarm)# predictor [roundrobin | leastconns] Specifies whether the weighted round robin
algorithm or the weighted least connections
algorithm is to be used to determine how a real
server is selected.
Specifying a Bind ID
To configure a bind ID on the server farm for use by DFP, use the following command in SLB server
farm configuration mode:
Command Purpose
Router(config-slb-sfarm)# bindid [bind-id] Specifies a bind ID on the server farm for use by
DFP.
Command Purpose
Router(config-slb-sfarm)# real ip-address Identifies a real server to the IOS SLB function
and initiates real server configuration mode.
Command Purpose
Router(config-slb-real)# faildetect numconns number-conns Specifies the number of consecutive connection
[numclients number-clients] failures and, optionally, the number of unique
client connection failures, that constitute failure of
the real server.
Router(config-slb-real)# maxconns maximum-number Specifies the maximum number of active
connections allowed on the real server at one time.
Router(config-slb-real)# reassign threshold Specifies the number of consecutive unanswered
SYNs that initiates assignment of the connection
to a different real server.
Router(config-slb-real)# retry retry-value Specifies the interval (in seconds) to wait between
the detection of a server failure and the next
attempt to connect to the failed server.
Router(config-slb-real)# weight weighting-value Specifies the workload capacity of the real server
relative to other servers in the server farm.
Command Purpose
Router(config-slb-real)# inservice Enables the real server for use by IOS SLB.
Command Purpose
Router(config)# ip slb vserver virtserver-name Identifies a virtual server and enters SLB virtual
server configuration mode.
Command Purpose
Router(config-slb-vserver)# serverfarm serverfarm-name Associates a real server farm with a virtual server.
Command Purpose
Router(config-slb-vserver)# virtual ip-address {tcp | udp} Specifies the virtual server IP address, type of
port-number [service service-name] connection, port number, and optional service
coupling.
Command Purpose
Router(config-slb-vserver)# client ip-address network-mask Specifies which clients are allowed to use the
virtual server.
Router(config-slb-vserver)# delay duration Specifies the amount of time IOS SLB maintains
TCP connection context after a connection has
terminated. The default value is 10 seconds.
Router(config-slb-vserver)# idle duration Specifies the minimum amount of time IOS SLB
maintains connection context in the absence of
packet activity. The default value is 3600 seconds
(1 hour).
Command Purpose
Router(config-slb-vserver)# sticky duration [group group-id] Specifies that connections from the same client
use the same real server, as long as the interval
between client connections does not exceed the
specified duration.
Router(config-slb-vserver)# synguard syn-count interval Specifies the rate of TCP SYNs handled by a
virtual server in order to prevent a SYN flood
denial-of -service attack.
Command Purpose
Router(config-slb-vserver)# no advertise Omits the virtual server IP address from the
routing protocol updates.
Command Purpose
Router(config-slb-vserver)# inservice Enables the virtual server for use by IOS SLB.
Command Purpose
Step 1 Router(config)# ip slb dfp [password password Configures DFP and, optionally, sets a password
[timeout]] and initiates SLB DFP configuration mode.
Step 2 Router(config-slb-dfp)# agent ip-address port [timeout Configures a DFP agent.
[retry-count [retry-interval]]]
Configuring NAT
To configure IOS SLB NAT mode for a specific server farm, use the following commands beginning in
global configuration mode:
Command Purpose
Step 1 Router(config)# ip slb serverfarm serverfarm-name Adds a server farm definition to the IOS SLB
configuration and initiates server farm
configuration mode.
Step 2 Router(config-slb-sfarm)# nat server Configures server NAT.
Step 3 Router(config-slb-sfarm)# real ip-address Identifies a real server to the IOS SLB function
and initiates real server configuration mode.
At any time, HSRP-configured Layer 3 switches are in one of the following states:
• Active—The switch is performing packet-transfer functions.
• Standby—The switch is prepared to assume packet-transfer functions if the active router fails.
• Speaking and listening—The switch is sending and receiving hello messages.
• Listening—The switch is receiving hello messages.
Step 1 Configure the server farms. See the “Specifying a Server Farm” section earlier in this chapter.
Step 2 Configure the real servers. See the “Specifying a Real Server” section earlier in this chapter.
Step 3 Configure the virtual servers. See the “Specifying a Virtual Server”section earlier in this chapter.
Note When you use the inservice (virtual service) command to configure the virtual server as
“in-service” you must use the optional standby interface configuration command and
configure an HSRP group name.
Step 4 Configure the IP routing protocol. See the “IP Routing Protocols” part of the Cisco IOS IP Configuration
Guide.
Step 5 Configure the VLAN between the switches. See the “Virtual LANs” chapter of the Cisco IOS
Switching Services Configuration Guide.
Step 6 Enable HSRP. See the “Enabling HSRP” section earlier in this chapter.
Step 7 Customize group attributes. See the “Customizing Group Attributes” section earlier in this chapter.
Step 8 Verify the IOS SLB HSRP configuration. See the “Verifying the IOS SLB Stateless Backup
Configuration” section earlier in this chapter.
A sample stateless backup configuration is shown in the “IOS SLB Stateless Backup Configuration
Example” section.
Enabling HSRP
To enable HSRP on an IOS SLB interface, enable the protocol, then customize it for the interface. Use
the following command in interface configuration mode:
Command Purpose
Router(config-if)# standby [group-number] ip [ip-address Enables HSRP.
[secondary]]
Command Purpose
Router(config-if)# standby [group-number] authentication Selects an authentication string to be carried in all
string HSRP messages.
Router(config-if)# standby [group-number] name group-name Specifies an HSRP group name with which to
associate an IOS SLB interface.
Router(config-if)# standby [group-number] preempt Specifies that if the local router has priority over
the current active router, the local router should
attempt to take its place as the active router.
Router(config-if)# standby [group-number] priority priority Sets the Hot Standby priority used to choose the
active router.
Router(config-if)# standby [group-number] timers hellotime Configures the time between hello packets and the
holdtime hold time before other routers declare the active
router to be down.
Router(config-if)# standby [group-number] track type-number Configures the interface to track other interfaces,
[interface-priority] so that if one of the other interfaces goes down the
Hot Standby priority for the device is lowered.
To verify that server failures are detected correctly, perform the following steps:
Step 1 Use a large client population. If the number of clients is very small, tune the numclients keyword on the
faildetect SLB real server configuration command so that the servers are not displayed as failed.
Step 2 Enter the show ip slb reals detail EXEC command to show the status of the real servers.
Step 3 Examine the status and connection counts of the real servers:
• Servers that failed show a status of failed, testing, or ready_to_test, based on whether IOS SLB is
checking that the server came back up when the command was sent.
• When a real server fails, connections that are assigned but not established (no SYN or ACK is
received) are reassigned to another real server on the first inbound SYN after the reassign threshold
is met. However, any connections that were already established are forwarded to the same real server
because, although it may not be accepting new connections, it may be servicing existing ones.
• For weighted least connections, a real server that has just been placed in service starts slowly so that
it is not overloaded with new connections. (See the “Slow Start” section for more information on
this feature.) Therefore, the connection counts displayed for a new real server show connections
going to other real servers (despite the lower count of the new real server). The connection counts
also show “dummy connections” to the new real server, which IOS SLB uses to artificially inflate
the connection counts for the real server during the slow start period.
Question Answer
Why can I connect to real servers directly, but not Make sure that the virtual IP address is configured as a loopback in each
to the virtual server? of the real servers (if you are running in dispatched mode).
Why is IOS SLB not marking my real server as Tune the values for the numclients, numconns, and delay keywords.
failed when I disconnect it from the network?
If you have a very small client population (for example, in a test
environment), the numclients keyword could be causing the problem.
This parameter prevents IOS SLB from mistaking the failure of a small
number of clients for the failure of a real server.
Why is IOS SLB not marking my connections as If you are using dispatched mode, make sure there are no alternate paths
established even though I am transferring data? that allow outbound flows to bypass IOS SLB. Also, make sure that the
clients and real servers are not on the same IP subnet.
Why does IOS SLB show my real server as The inservice and outofservice states indicate whether the network
inservice even though I have taken it down or administrator intends for that real server to be used when it is operational.
physically disconnected it? A real server that was inservice but was removed from the selection list
dynamically by IOS SLB as a result of automatic failure detection, is
marked as failed. Use the show ip slb reals detail EXEC command to
display these real server states.
Beginning with Cisco IOS Release 12.1(1)E, the inservice keyword is
changed to operational, to better reflect actual condition.
Why is IOS SLB not balancing correctly? I am Enter the show mls flow command:
using dispatched mode, the servers are leaving Router# show mls flow
sockets open, and I am seeing RSTs in response
to a number of SYNs. Curiously, sometimes current ip flowmask for unicast: full flow
things work fine. current ipx flowmask for unicast: destination only
The current IP flowmask must be full flow. If it is not, correct the problem
using the mls flow ip full global configuration command:
Router# configure terminal
Enter configuration commands, one per line.
End with CNTL/Z.
Router(config)# mls flow ip full
Router(config)#
Command Purpose
Router# show ip slb conns [vservers virtserver-name] [client Displays all connections handled by IOS SLB, or,
ip-address] [detail] optionally, only those connections associated with
a particular virtual server or client.
Router# show ip slb dfp [agent ip-address port-number] Displays information about DFP and DFP agents,
[detail] [weights] and about the weights assigned to real servers.
Router# show ip slb reals [vservers virtserver-name] [detail] Displays information about the real servers defined
to IOS SLB.
Router# show ip slb serverfarms [name serverfarm-name] Displays information about the server farms
[detail] defined to IOS SLB.
Router# show ip slb stats Displays IOS SLB statistics.
Router# show ip slb sticky [client ip-address] Displays information about the sticky connections
defined to IOS SLB.
Router# show ip slb vservers [name virtserver-name] [detail] Displays information about the virtual servers
defined to IOS SLB.
Configuration Examples
This section provides the following IOS SLB configuration examples:
• IOS SLB Network Configuration Example
• NAT Configuration Example
• HSRP Configuration Example
• IOS SLB Stateless Backup Configuration Example
Restricted Restricted
Web server Web server Web server web server web server
10.1.1.1 10.1.1.2 10.1.1.3 10.1.1.20 10.1.1.21
10.1.1.x
Virtual server
10.0.0.1
10.4.4.x
29163
Client Human
Resources
Client Client
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 farm
predictor leastconns Use weighted least connections algorithm
real 10.1.1.1 First real server
weight 16
inservice
real 10.1.1.2 Second real server
weight 4
maxconns 1000 Restrict maximum number of connections
inservice
real 10.1.1.3 Third real server
weight 24
inservice
Clients
33459
• Server 4 has multiple HTTP server applications listening on ports 8080, 8081, and 8082.
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 as follows:
ip slb serverfarm FARM1
! Translate server addresses
nat server
! Server 1 port 80
real 10.1.1.1
inservice
! Server 2 port 80
real 10.2.1.1
inservice
!
ip slb vservers HTTP1
! Handle HTTP (port 80) requests
virtual 128.1.0.1 tcp www
serverfarm FARM1
inservice
Note Some configurations that use HSRP still require a routing protocol for convergence when
a topology change occurs. The standby Layer 3 switch becomes active, but connectivity
does not occur until convergence occurs.
If the connection between Device A and the client accessing virtual 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.
Client
33604
HSRP group = Web_Group HSRP group = Web_Group
interface GigabitEthernet 41
ip address 1.0.0.1 255.0.0.0
standby 1 ip 1.0.0.3
standby 1 preempt
standby 1 priority 110
standby 1 authentication denmark
standby 1 timers 5 15
standby 1 name Web-Group
interface FastEthernet 1
ip address 3.0.0.1 255.0.0.0
router eigrp 1
network 1.0.0.0
network 3.0.0.0
interface GigabitEthernet 41
ip address 1.0.0.2 255.0.0.0
standby 1 ip 1.0.0.3
standby 1 preempt
standby 1 authentication denmark
standby 1 timers 5 15
interface FastEthernet 41
ip address 2.0.0.1 255.0.0.0
router eigrp 1
network 1.0.0.0
network 2.0.0.0
The 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 HSRP priority of the Layer 3 switch 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 5 seconds, and sets the interval (in seconds) that a Layer 3 switch
waits before it declares the active Layer 3 switch to be down (called the hold time) to 15 seconds. (The
defaults are 3 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.