ServerIron ADX Server Load Balancing Guide

Release 12.0.00

June 15, 2009

Symmetric SLB

Symmetric SLB (SSLB) is active-standby VIP. Both ServerIrons handle traffic, but the active VIP handles the L4-7 and the standby VIP serves only as a standby. Each ServerIron is the active ServerIron for a specific set of VIPs, while the other ServerIron is the backup for the same set of VIPs.

In SSLB, you determine which ServerIrons are active and backup for a VIP by associating a sym-priority with the VIP. You assign a different priority to the same VIP on each ServerIron. The ServerIron on which the VIP has the highest priority is the active ServerIron for that VIP and the others are standbys. When all ServerIrons and associated links are available, the ServerIron with the highest priority for the VIP services the VIP.

SSLB does not require any changes to the Spanning Tree configuration in the network. Regardless of whether the network is using Spanning Tree, SSLB provides redundancy for the VIPs and allows all the ServerIrons configured for SSLB to actively perform Server Load Balancing.

In addition, you do not need to dedicate ServerIron links to SSLB. SSLB works within the network’s topology.

NOTE: You cannot have a router hop between the ServerIrons. They must have Layer 2 connectivity. Additionally, you cannot use Hot Standby and SSLB features on the same ServerIron.

NOTE: If a ServerIron is running software with a router image and the ServerIrons are in an Active-Active configurations, you need to enable VRRP or VRRP-E on these ServerIrons; otherwise, FTP, RTSP, and MMS protocols may not work. Also, configure the IP address of the real server’s default gateway IP address in VRRP-E configuration and the "owner" IP address in VRRP configuration.

NOTE: System limitation. The ServerIron does not support symmetric SLB with shared source NAT IPs. The reason is because the VIP and the source IP may not be active on the same ServerIron, and as a result, the ServerIron will not know how to forward return traffic. Configure sym-active as a workaround.

Minimum Required Configuration

 

Figure 6.4

Common Symmetric Configuration

In the previous diagram, two upstream routers are connected to two different ISPs. This setup allows clients to access the ServerIrons from different directions. Clients coming from ISP1 want an active VIP1 (on ServerIron-A). The same VIP1 accessed by ISP2 is on standby (on ServerIron-B). On a per ServerIron basis, some VIPs are active while others are on standby. In contrast, all VIPs per ServerIron are either active or standby in a Hot Standby scenario.

To configure Symmetric SLB, configure the sym-priority <value> command on each active and standby VIP. The higher the <value>, the higher the preference (priority). The range is from 0 – 255. You also can configure the priority to dynamically adjust to changes in the health of applications on the VIP.

In the diagram, ServerIron-A’s VIP1 has a priority of 10. ServerIron-B’s VIP1 has a priority of 5. Therefore, ServerIron-A is active. When traffic comes to VIP1, ServerIron-A creates the session. When VIP1 on ServerIron-A goes down, VIP1 on ServerIron-B becomes active. Only the active VIP owner responds to ARP, traffic, session synching, and so on. The Symmetric solution provides granular control of the VIPs.

Enabled by default, any L2 link can be used for automatic session synchronization between the ServerIrons. Unlike Hot Standby, the ServerIrons need not be directly connected. To specify a specific port (optional), use the session-sync server subcommand on both devices. See “Configuring VLAN Option for Active-Active Links”.

NOTE: To correctly handle the return traffic in this scenario, you should apply Source-NAT or DSR to a Symmetric SLB configuration. Enable one or the other (not both) for a real server.

Following is another common Symmetric topology, where the real servers are directly connected to the ServerIrons.

Figure 6.5

Common Symmetric Configuration

 

NOTE: To see the session sync, go to the BP and issue show session all 0.

Failover Conditions

Both ServerIrons are active with SSLB. Therefore, failover depends on which device has ownership of the VIP. If a link is broken, both ServerIrons are still active. The only time a VIP can failover is during a reload or system crash. Use show log and show server virtual-name-or-ip to gather failover information. The show server virtual-name-or-ip command displays state information (5 = active, 3 = standby, 2 = inactive, 1 = inactive).

Enabling Session Synchronization on a Port

For each port you use for load balancing, you must define the session-sync and port number to enable session synchronization.

To enable session synchronization for port 80 (HTTP), enter the following commands:

ServerIron(config)# server port 80
ServerIron(config-port-80)# session-sync

Syntax: server port <TCP/UDP-portnum>

Syntax: [no] session-sync

Symmetric SLB in a IPsec/IKE Configuration

Figure 6.6 shows an example of an active-standby IPsec and VPN configuration. A hot-standby ServerIron provides redundancy. If the active ServerIron becomes unavailable, the standby ServerIron takes over.

Figure 6.6

Active-Standby IPsec and VPN Load Balancing

Here are the CLI commands to implement the configuration shown in Figure 6.6. Notice that the VPN configuration commands on both ServerIrons are identical. The only information unique to each ServerIron is the management IP address.

Active ServerIron

The following commands change the CLI to global CONFIG level, add the management IP address, and identify the default gateway.

ServerIron> enable
ServerIron# configure terminal
ServerIron(config)# ip address 192.168.1.1 255.255.255.0
ServerIron(config)# ip default-gateway 192.168.1.254

The following commands add the real server definitions for the VPN devices:

ServerIron(config)# server real-name VPN1 192.168.1.10
ServerIron(config-rs-VPN1)# port 500
ServerIron(config-rs-VPN1)# exit
ServerIron(config)# server real-name VPN2 192.168.1.11
ServerIron(config-rs-VPN2)# port 500
ServerIron(config-rs-VPN2)# exit

The following commands configure the virtual server definition for the VPN address.

ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100
ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel
ServerIron(config-vs-VPNaddr)# port 500
ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500
ServerIron(config-vs-VPNaddr)# exit

The following commands configure the hot-standby information. Since the backup link between the ServerIrons should be in its own port-based VLAN, the vlan command creates a new port-based VLAN and changes the CLI to the configuration level for the VLAN. The untag ethernet command adds the port that is connected to the other ServerIron as an untagged port. The no spanning-tree command disables STP in the VLAN.

ServerIron(config)# vlan 2
ServerIron(config-vlan-2)# untag ethernet 2/1
ServerIron(config-vlan-2)# no spanning-tree
ServerIron(config-vlan-2)# exit

The following commands enable Layer 4 switching for TCP traffic and save the configuration changes to the startup-config file.

ServerIron(config)# ip policy 1 cache tcp 0 global
ServerIron(config)# write memory

The following commands reload the software. This is required to place the backup configuration into effect.

ServerIron(config)# end
ServerIron# reload

Standby ServerIron

Here are the commands for configuring the standby ServerIron. The only difference between these commands and the commands for the active ServerIron is the management IP address. For simplicity, the same port number is used on each ServerIron for the backup port. If you use different backup port numbers, the backup port numbers also will differ between the two configurations.

ServerIron> enable
ServerIron# configure terminal
ServerIron(config)# ip address 192.168.1.2 255.255.255.0
ServerIron(config)# ip default-gateway 192.168.1.254

ServerIron(config)# server real-name VPN1 192.168.1.10
ServerIron(config-rs-VPN1)# port 500
ServerIron(config-rs-VPN1)# exit
ServerIron(config)# server real-name VPN2 192.168.1.11
ServerIron(config-rs-VPN2)# port 500
ServerIron(config-rs-VPN2)# exit

ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100
ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel
ServerIron(config-vs-VPNaddr)# port 500
ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500
ServerIron(config-vs-VPNaddr)# exit

ServerIron(config)# vlan 2
ServerIron(config-vlan-2)# untag ethernet 2/1
ServerIron(config-vlan-2)# no spanning-tree
ServerIron(config-vlan-2)# exit

ServerIron(config)# ip policy 1 cache tcp 0 global
ServerIron(config)# write memory

ServerIron(config)# end
ServerIron# reload

Configuring the Interval and Wait Time for SSLB Discovery Packets

A ServerIron in an SSLB configuration uses discovery packets to request SSLB information from the other ServerIrons. SSLB discovery packets are proprietary Layer 2 broadcast packets and are sent on all ports in all port-based VLANs. Use the server sym-pdu-rate command to change the interval and wait time for SSLB discovery packets.

By default, a ServerIron in an SSLB configuration sends discovery packets at 200-millisecond intervals while the default wait time interval is twice the send interval at 400-millisecond. The ServerIron will wait up to 20 equivalent intervals to receive a discovery packet from another ServerIron. If the ServerIron does not receive a discovery packet from the other ServerIron within 20 intervals, the ServerIron concludes that its partner ServerIron is unavailable and assumes control of the VIPs being managed by that ServerIron. For example, if the interval for sending SSLB discovery packets is 200 milliseconds (the default), the ServerIron will wait 20 X 400 milliseconds (eight seconds) to receive a discovery packet from another ServerIron.

You can change the send interval multiplier and the wait time multiplier.

•	The send interval is equal to 200 milliseconds multiplied by the send interval multiplier. The default send interval multiplier is 1, so the default send interval is 200 milliseconds. You can specify a multiplier from 1 – 60.

•	The total wait time interval is equal to 400 milliseconds multiplied by the wait time multiplier. The default wait time multiplier is 20; therefore, the default wait time is eight seconds (20 x 400 milliseconds).

The SSLB timer affects the rate at which the ServerIron sends SSLB protocol packets to its SSLB partners. The timer does not affect client or server traffic to or from a VIP.

All the ServerIrons in your configuration must use the same SSLB send interval and wait time. If you change the interval and wait time on one ServerIron, make the same change on all the other ServerIrons in the SSLB configuration.

To configure the interval and wait time for SSLB discovery packets, enter a command such as the following:

ServerIron(config)# server sym-pdu-rate 2 30

This command does the following:

•	Changes the default send interval (200 ms) and wait interval (400 ms) by a factor of 2

•	Increases the wait time multiplier from the default 20 to 30.

In effect, this command:

•	Changes the interval at which the ServerIron sends SSLB discovery packets to once every 400 milliseconds

•	Changes the wait interval for discovery packet to once every 800 milliseconds

•	Changes the maximum amount of time the ServerIron will wait for an SSLB discovery packet from another ServerIron to 24 seconds (30 x 2 x 400 milliseconds).

Syntax: [no] server sym-pdu-rate <send-wait-multiplier> <wait-time-multiplier>

The <send-wait-multiplier> variable specifies the multiplier for the SSLB send and wait interval. You can specify a multiplier from 1 – 60. The default is 1.

The <wait-time-multiplier> variable specifies how many multiples of the wait interval the ServerIron will wait for an SSLB discovery packet. You can specify a multiplier from 1 – 60. The default is 20.

Configuring Dynamic Priority

The software automatically adjusts a VIP application’s SSLB priority to a lower value if a given application fails a health check. With this enhancement, the SSLB priority provides failover for the individual application even if the ServerIron and the application’s VIP are both still active.

The priority determines which ServerIron becomes the active one for the VIP and application by default. The priority is static and does not change if the status of the VIP’s application changes. As a result, it is possible for SSLB to continue trying to use a real server farm that is no longer responding, instead of failing over to the other ServerIron to load balance requests for the VIP and application.

You can configure a decrement value for the SSLB priority. If an application on a VIP that is enabled for SSLB fails a health check, the ServerIron decrements the VIP’s SSLB priority by the amount you specify for the decrement. If the priority value becomes lower than the VIP’s priority on the other ServerIron, the software fails the VIP over to the other ServerIron.

NOTE: When you configure a decrement value, the value takes effect only if all the application’s ports on the real servers fail their health checks. Thus, if the application is still available on at least one of the real servers bound to the VIP, the software does not decrement the priority.

NOTE: When you configure the decrement value, do not specify a value that will make the VIP’s priority 0. For example, if the VIP’s SSLB priority is 10, do not specify 10 as the decrement value. Specify a lower number. Priority value 0 disables SSLB, in which case the VIP becomes active on both ServerIrons.

Figure 6.7 shows an example of an SSLB configuration that uses the default priority handling (not the dynamic priority handling).

Figure 6.7

SSLB without dynamic priority

Using the default priority handling, the software fails over a VIP to the other ServerIron only of the entire VIP or the ServerIron itself becomes unavailable. If an application on the VIP becomes unavailable on all the real servers bound to the VIP, but the VIP itself is still available, the software continues using the same ServerIron for the VIP. As a result, clients are unable to access the unavailable application even if the application is available through the other ServerIron.

Figure 6.8 shows an example of a configuration that uses dynamic SSLB priority.

Figure 6.8

SSLB with dynamic priority

In this configuration, a ServerIron fails over a VIP to the other ServerIron if more than one application on the VIP becomes unavailable. If one application becomes unavailable, the software reduces the VIP’s priority by 9 (the decrement value), in this case to 21. At this point, the ServerIron that is active by default for the VIP still has the higher priority, so failover does not occur. However, if a second application becomes unavailable, then the priority becomes 12, which is less than the priority for the VIP on the other ServerIron (20).

When an application becomes available again (and passes a health check), the ServerIron increments the VIP’s priority by the decrement amount, thus replacing the priority amount that the software removed when the application failed. If the increment makes the VIP’s priority higher than the priority on the other ServerIron, the software fails back over to the ServerIron that originally had the higher priority for the VIP.

If more than one ServerIron has the highest priority for a VIP, the ServerIron that has the highest value for the lowest four bytes of its base MAC address becomes the active ServerIron for the VIP.

NOTE: If all the applications that are configured for SSLB on the VIP become unavailable, the software sets the SSLB priority for that VIP to 1 (the lowest value).

The following commands configure the SSLB priority parameters for the configuration in Figure 6.8.

Commands on ServerIron A

ServerIronA(config-vs-VIP1)# sym-priority 30
ServerIronA(config-vs-VIP1)# dyn-sym-pri-factor 9

Commands on ServerIron B

ServerIronB(config-vs-VIP1)# sym-priority 20
ServerIronB(config-vs-VIP1)# dyn-sym-pri-factor 9

The dyn-sym-pri-factor commands in this example configure the decrement value to 9. Each time an application on the VIP fails a health check (fails on all the real servers bound to the VIP), the ServerIron decrements the VIP’s SSLB priority by 9. If the priority reaches a value that is lower than the VIP’s priority on the other ServerIron, the software fails over active load balancing for the VIP to the other ServerIron. In this example, failover of the VIP from ServerIron A to ServerIron B occurs if two applications are unavailable (have failed their health checks).

Syntax: [no] dyn-sym-pri-factor <num>

The <num> variable can be a value from 0 – 255 and specifies the amount by which you want the ServerIron to decrement a VIP’s priority when an application on the VIP fails a health check. There is no default. If you specify a value, then the software performs dynamic SSLB priority for the VIP.

To remove a configured decrement, issue dyn-sym-pri-factor 0. The no form of the command does not disable the command.

NOTE: Make sure you specify priority and decrement values that provide the level of sensitivity you want. For example, if you want the software to fail over load balancing of a VIP if even a single application fails a health check, then configure the values so that the difference between the two priorities (sym-priority command) is less than the decrement value (dyn-sym-pri-factor command).

NOTE: Do not specify a value that will make the VIP’s priority 0. For example, if the VIP’s SSLB priority is 10, do not specify 10 as the decrement value. Specify a lower number. Priority value 0 disables SSLB, in which case the VIP becomes active on both ServerIrons.

Displaying Dynamic Priority Information

To display the dynamic SSLB configuration and current value for a VIP, enter a command such as the following at any level of the CLI:

Syntax: show server virtual-name-or-ip [<name>]

This example shows the configuration and priority information for VIP1 in Figure 6.8. The priority information is shown by the fields in bold type. These fields show the following information.

Table 6.2: Virtual Server Information for SSLB  

This Field...

Displays...

Sym

Information for SSLB. The following information is displayed: • group – The SSLB group number. • state – The state, which should be 5 for the active ServerIron and 3 for other ServerIrons. • priority – The SSLB priority configured on the ServerIron. • keep – The number of times an SSLB backup has failed to communicate with the active ServerIron. By default, the counter is incremented by 1 every 400 milliseconds the backup ServerIron is late responding to the active ServerIron’s keepalive message. The counter is reset to 0 each time the backup ServerIron replies to a keepalive message. If the counter goes higher than the maximum number allowed (20 by default, thus 8 seconds), the standby ServerIron takes over as the new active ServerIron. Normally, this field almost always contains 0. Note: This field is applicable only on the active ServerIron. • dyn priority/factor – The current dynamically set priority and the decrement value. In this example, an application has failed a health check, so the dynamic priority is 20 instead of 30. The decrement value is 10. If the priority and dyn priority values match, then all the VIP’s applications that are configured for SSLB are responding to their health checks. • Activates – The number of times this ServerIron has become the active ServerIron. • Inactive – The number of times this ServerIron has changed from being the active ServerIron. • Best-standby-mac – The MAC address of the backup ServerIron with the second-highest priority. This ServerIron will become the active ServerIron if a failover occurs.

Configuring Delay Reactivation

Use the server delay-symmetric command to delay the reactivation of a failed ServerIron in an SSLB configuration following the ServerIron’s recovery. By delaying reactivation of a recovered ServerIron, you provide time for sessions created by the standby ServerIron to terminate normally.

When you enable session synchronization in a ServerIron SSLB configuration, the active ServerIron for a VIP sends session synchronization information to the standby ServerIron. If the VIP’s active ServerIron becomes unavailable, the open sessions for the VIP fail over to the other ServerIron, which provides uninterrupted service for the sessions.

The active ServerIron sends session synchronization information to a VIP’s standby ServerIron when the session is created. Following a failover, when the standby ServerIron for a VIP has taken over, the standby ServerIron can create new sessions for the VIP. However, because the ServerIron with the higher priority for the VIP is unavailable, the standby ServerIron cannot send synchronization information for the newly created sessions. As a result, when the other ServerIron becomes available again, it resumes service for the VIP but cannot continue the sessions that were created by the standby ServerIron.

You can minimize interruption to sessions created on the standby ServerIron by configuring each ServerIron to delay reactivation following its recovery after a failover. By delaying reactivation of a recovered ServerIron, you provide time for sessions created by the standby ServerIron to terminate normally.

To configure delay reactivation, enter the following command:

ServerIron(config)# server delay-symmetric

Syntax: [no] server delay-symmetric [<mins>]

The <mins> variable specifies the number of minutes you want the recovered ServerIron to wait before becoming active again. You can specify from 2 – 120 minutes. The default is 60 minutes. You must enter the same command using the same number of minutes on both ServerIrons in the configuration.

Displaying SSLB Information

Use the show server symmetric command to display SSLB information:

Table 6.3: SSLB Display Information  

This Field...	Displays...
Server Symmetric port	The ServerIron port number on which the ServerIron perceives other ServerIrons running SSLB.
Group_id	The SSLB group ID. The group ID is always 1.
Candidate cnt	The number of ports on which the ServerIron perceives a partner ServerIron running SSLB.
Port	The port connected to the other ServerIron.
No-rx	Information Brocade technical support can use to help resolve SSLB configuration issues.

VIP Failover Following a Link Failure

In an active-active SLB configuration, each VIP is managed by one of the ServerIrons by default. The other ServerIron is a backup for the VIP.

If the interface that has the VIP’s subnet becomes unavailable on the default active ServerIron for the VIP, the ServerIron changes the Symmetric SLB priority for that VIP to 1 to cause a failover to the other ServerIron. Once the unavailable link is restored, the ServerIron changes the Symmetric SLB priority back to the value you configured.

NOTE: Failover occurs only if the entire link becomes unavailable. If the link is a trunk group or a virtual routing interface residing on multiple ports, failover occurs only if all the ports become unavailable.

Configuring VIP Failover in VRRP Extended with Symmetric SLB

In Symmetric SLB and Sym-Active configurations with VRRP-E, when the device switches from the Master router to a Backup router, there is a CLI command that guarantees simultaneous VIP failover in the event VRRP-E fails over to a Backup router. To enable this feature, first define a VIP group that includes VIP addresses, then bind the VIP group to a Virtual Router ID (VRID).

NOTE: Before defining and binding VIP groups, ensure that the standby VIP priority (sym-priority command) is not set to 1. This value is reserved for internal use.

NOTE: In Symmetric SLB, the VIP is active on both ServerIrons if there is no default gateway configured, even though all clients, servers, and ServerIrons are on the same subnet.

To enable this feature, enter commands such as the following:

1.	Define a VIP group:

ServerIron(config)# server vip-group 1
ServerIron(config-vip-group-[1])# vip 10.10.1.100
ServerIron(config-vip-group-[1])# exit

2.	Bind the VIP group to a VRID:

ServerIron(config)# router vrrp (-extended)
ServerIron(config)# interface e 1/2
ServerIron(config-if-e100-1/2)# ip vrrp vrid 1
ServerIron(config-if-e100-12-vrid-1)# vip-group 1

NOTE: Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one VRID associated with it.

Enhanced VIP Group Support

The ServerIron VIP Group feature helps grouping of several virtual server addresses and associating them with the VRRP-E tracking mechanism.

Syntax: [no] server vip-group <number>

The <number> parameter is the VIP group number from 1 to 100.

Syntax: [no] vip <ip address>

The <ip address> parameter is the Virtual IP address to be included in the VIP group. There is not limit to the number of Virtual IP addresses in a VIP group; however, each virtual IP address can belong to only one VIP group.

Syntax: [no] vip-group <number>

The <number> parameter is the VIP group number (from 1 to 100) that you are binding to the VRID. Note that each VIP group can have only one VRID associated with it.

Configuring VLAN Option for Active-Active Links

Active-active SYN-Guard and NAT configurations use the server active-active-port ethernet <portnum> command to identify the port that connects the ServerIron to its active-active partner. The port you specify must be in its own port-based VLAN.

To use a tagged port, specify the VLAN ID for the active-active link when you specify the port. When you specify the VLAN ID, the ServerIron forwards active-active traffic on the specified VLAN only. The traffic is not sent to the other VLANs of which the port is a member.

To configures the active-active link, enter the command such as the following:

ServerIron(config)# server active-active-port ethernet 3/5 200

This command configures the active-active link on port 3/5 on VLAN 200 only. The active-active traffic is not forwarded to the other VLANs that port 3/5 is in.

Syntax: [no] server active-active-port ethernet <portnum> [<vlan-id>]

Allowing Pass-Through Traffic to a VIP

In a symmetric-active SLB configuration, the ServerIron intercepts SYN packets to a VIP if the destination MAC address is not the VIP's MAC address.

The server allow-pass-through-vip-traffic command causes the ServerIron to ignore SYN packets addressed to a symmetric VIP IP address if the destination MAC address is not the symmetric VIP MAC address.

To allow pass-through traffic to a VIP, enter the following command:

ServerIron(config)# server allow-pass-through-vip-traffic

Syntax: [no] server allow-pass-through

Fast Session Synchronization with VRRP

ServerIrons in symmetric high-availability configuration will support the fast session synchronization. Fast session synchronization applies to symmetric and symmetric-active topologies. With the fast session synchronization, if a software reload occurs in one ServerIron, the other ServerIron in the symmetric high-availability pair synchronizes all existing sessions with the newly reloaded ServerIron. This process ensures that multiple failovers for symmetric high-availability ServerIrons occur seamlessly and without loss of traffic.

Fast session synchronization is enabled by default. There are no CLI commands to enable or disable this feature. However, if VRRP is configured on your ServerIrons you need to configure a primary and secondary IP address on the VRRP interface of the VRID owner. The secondary IP address must be associated with the VRID.

NOTE: Associating the secondary IP with the VRID and other configuration mentioned above is a requirement only for VRRP. There is no such requirement for VRRP-E in order to support fast session synchronization feature.

The configuration examples below show how to configure the VRRP owner and backup with the primary and secondary IP addresses.

Configuring the Owner

Router1(config)# router vrrp
Router1(config)# interface e 1/6
Router1(config-if-1/6)# ip address 192.53.5.1/24
Router1(config-if-1/6)# ip address 192.53.5.2/24 secondary
Router1(config-if-1/6)# ip vrrp vrid 1
Router1(config-if-1/6-vrid-1)# owner
Router1(config-if-1/6-vrid-1)# ip-address 192.53.5.2
Router1(config-if-1/6-vrid-1)# activate

Configuring a Backup

Router2(config)# router vrrp
Router2(config)# inter e 1/5
Router2(config-if-1/5)# ip address 192.53.5.3/24
Router2(config-if-1/5)# ip vrrp vrid 1
Router2(config-if-1/5-vrid-1)# backup
Router2(config-if-1/5-vrid-1)# ip-address 192.53.5.2
Router2(config-if-1/5-vrid-1)# activate

NOTE: You can provide more redundancy to the ServerIrons by also configuring a second VRID with Router 2 as the Owner and on Router 1 as the Backup. This type of configuration is sometimes called Multigroup VRRP. In order to support fast session synchronization feature in this type of configuration, you would also need a secondary IP address on Router 2 and the second VRID needs to be associated with this secondary IP address on Router 2.