ACOS 4.1.1-P11 Configuring VRRP-A High Availability: For A10 Thunder Series and AX™ Series 29 May 2019

ACOS 4.1.
1-P11
Configuring VRRP-A High Availability
for A10 Thunder® Series and AX™ Series
29 May 2019
© 2019 A10 NETWORKS, INC. CONFIDENTIAL AND PROPRIETARY- ALL RIGHTS RESERVED
Information in this document is subject to change without notice.
PATENT PROTECTION
A10 Networks products are protected by patents in the U.S. and elsewhere. The following website is provided to satisfy the virtual pat-
ent marking provisions of various jurisdictions including the virtual patent marking provisions of the America Invents Act. A10 Net-
works' products, including all Thunder Series products, are protected by one or more of U.S. patents and patents pending listed at:
https://www.a10networks.com/company/legal-notices/a10-virtual-patent-marking
TRADEMARKS
A10 Networks trademarks are listed at:
https://www.a10networks.com/company/legal-notices/a10-trademarks
CONFIDENTIALITY
This document contains confidential materials proprietary to A10 Networks, Inc. This document and information and ideas herein may
not be disclosed, copied, reproduced or distributed to anyone outside A10 Networks, Inc. without prior written consent of A10 Net-
works, Inc.
A10 NETWORKS INC. SOFTWARE LICENSE AND END USER AGREEMENT

Software for all A10 Networks products contains trade secrets of A10 Networks and its subsidiaries and Customer agrees to treat Soft-
ware as confidential information.
Anyone who uses the Software does so only in compliance with the terms of the End User License Agreement (EULA), provided later in
this document or available separately. Customer shall not:
1. Reverse engineer, reverse compile, reverse de-assemble, or otherwise translate the Software by any
means.
2. Sub-license, rent, or lease the Software.
DISCLAIMER
This document does not create any express or implied warranty about A10 Networks or about its products or services, including but not
limited to fitness for a particular use and non-infringement. A10 Networks has made reasonable efforts to verify that the information
contained herein is accurate, but A10 Networks assumes no responsibility for its use. All information is provided "as-is." The product
specifications and features described in this publication are based on the latest information available; however, specifications are sub-
ject to change without notice, and certain features may not be available upon initial product release. Contact A10 Networks for current
information regarding its products or services. A10 Networks’ products and services are subject to A10 Networks’ standard terms and
conditions.
ENVIRONMENTAL CONSIDERATIONS
Some electronic components may possibly contain dangerous substances. For information on specific component types, please con-
tact the manufacturer of that component. Always consult local authorities for regulations regarding proper disposal of electronic com-
ponents in your area.
FURTHER INFORMATION
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10 Networks loca-
tion, which can be found by visiting www.a10networks.com.
Table of Contents
Overview of VRRP-A ..................................................................................................................... 9

VRRP-A Overview....................................................................................................................9
VRRP-A Configuration ..........................................................................................................10
Basic VRRP-A Configuration ................................................................................................................... 10
Multicast Heartbeat Destination Addresses ................................................................................. 11
Unicast Hearbeat Destination Addresses ...................................................................................... 11
VRRP-A and Virtual Router IDs ............................................................................................................... 12
Leader and Follower VRIDs ............................................................................................................... 13
VRID Virtual MAC Addresses ............................................................................................................ 13
VRRP-A, Virtual Router IDs, and Partitions ........................................................................................... 13
VRRP-A Active / Standby Device Selection ........................................................................14
VRRP-A Active Device Selection Overview ........................................................................................... 15
Event Tracking for Weight and Priority .................................................................................................. 16
Priority Calculation .................................................................................................................................... 16
Track Event Delay ...................................................................................................................................... 16
Preemption and VRRP-A Failover Behavior with Preemption Disabled .......................................... 17
Preemption Delay ....................................................................................................................................... 17
Active Device Selection Examples .......................................................................................................... 18
VRRP-A Failover....................................................................................................................21
Policy-Based Failover ................................................................................................................................ 21
Dynamic Priority Reduction ..................................................................................................................... 21
Force-Self-Standby .................................................................................................................................... 22
VRRP-A and Floating IP Addresses .....................................................................................23
VRRP-A and Configuration Synchronization.......................................................................24
VRRP-A and Session Synchronization ................................................................................24
VRRP-A Interfaces ................................................................................................................25
Explicitly Configured VRRP-A Interfaces ............................................................................................... 25
VRRP-A Interface Types and VRRP-A State ......................................................................................... 26
Using the GUI to Configure a VRRP-A Interface .................................................................................. 26
Using the CLI to Configure a VRRP-A Interface ................................................................................... 27
Preferred Receive Interface for Session Synchronization ................................................................. 28
Manually Synchronizing Configuration Information ..........................................................29
Requirements for Synchronization Link ................................................................................................ 29
Configuration Items That Are Backed Up ............................................................................................. 30
Configuration Items That Are Not Backed Up ..................................................................................... 30
Performing Configuration Synchronization .......................................................................................... 31
Using the GUI ....................................................................................................................................... 31
Using the CLI ........................................................................................................................................ 31
page 3
ACOS 4.1.1-P11 Configuring VRRP-A High Availability
Contents
Displaying the Configure Sync State ..................................................................................................... 31
Deploying VRRP-A ...................................................................................................................... 35

Basic VRRP-A Deployment...................................................................................................35
Force-Self-Standby Reload or Restart Persistence ............................................................36
Viewing VRRP-A Information ...............................................................................................37
Viewing VRRP-A Config-Sync Status in the CLI ................................................................................... 37
Configuring Preemption Delays...........................................................................................40
Use the GUI to Configure VRRP-A Preemption Delay ......................................................................... 40
Use the CLI to Configure VRRP-A Preemption Delay ......................................................................... 40
VRRP-A Configuration Examples.........................................................................................43
Simple Deployment ................................................................................................................................... 43
Deployment with Custom Priority Settings .......................................................................................... 43
Configuration of Tracking Options ......................................................................................................... 45
Ethernet Interface Tracking .............................................................................................................. 46
Trunk Tracking ..................................................................................................................................... 46
VLAN Tracking ..................................................................................................................................... 46
Gateway Tracking ............................................................................................................................... 47
Route Tracking .................................................................................................................................... 47
Preemption Delay ................................................................................................................................ 47
Increased VLANs for VRRP-A Failover Tracking .......................................................................... 48
VLAN Tracking Configuration Example .......................................................................................... 48
Configuring a Leader and Follower VRID ............................................................................49
Configuration Example 1 ................................................................................................................... 49
Configuration Example 2 ................................................................................................................... 50
Configuring VRRP-A VRID Lead Switching .........................................................................51
Manual VRID Lead Switching Using Manual Configuration ....................................................... 52
Automatic VRID Lead Switching Using aVCS ............................................................................... 53
VRRP-A Status in CLI Prompt ..............................................................................................53
VRRP-A Policy-Based Failover Template ................................................................................... 55

Template Rules and Partitions ............................................................................................55
Policy-Based Failover Template Rules for the Shared Partition ...................................................... 55
Policy-Based Failover Template Rules for L3V Partitions ................................................................. 56
Preemption and Levels.........................................................................................................56
Precedence Causing a Failover ...........................................................................................57
Higher Weight Scenario ............................................................................................................................ 57
Higher Priority Scenario ............................................................................................................................ 58
Equal Weight and Priority Scenario ........................................................................................................ 59
Events Tracked for Weight via the Templates ....................................................................60
Configuring VRRP-A Policy-Based Failovers ......................................................................62
Using the GUI to Configure VRRP-A Policy-Based Failovers ............................................................ 62
Using the CLI to Create VRRP-A Policy-Based Failovers ................................................................... 63
Configuring Templates in the Shared Partition ............................................................................ 63
Configuring Templates in L3V Partition ......................................................................................... 64
page 4
Contents
Verifying the Fail-Over Policy Template Configuration ............................................................... 65
High Availability ......................................................................................................................... 67

Overview................................................................................................................................67
Layer 3 Active-Standby HA ...................................................................................................................... 69
Layer 3 Active-Active HA .......................................................................................................................... 71
Layer 2 Active-Standby HA (Inline Deployment) .................................................................................. 73
Preferred HA Port ................................................................................................................................ 75
Port Restart .......................................................................................................................................... 76
Layer 3 Active-Standby HA (Inline Deployment) .................................................................................. 77
HA Messages .............................................................................................................................................. 78
HA Heartbeat Messages ................................................................................................................... 78
Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6) ..................................... 79
HA Interfaces .............................................................................................................................................. 79
VLAN ID Requirement ........................................................................................................................ 81
Session Synchronization .......................................................................................................................... 81
Optional Failover Triggers ........................................................................................................................ 82
VLAN-based Failover .......................................................................................................................... 82
Gateway-based Failover .................................................................................................................... 82
Route-based Failover ......................................................................................................................... 83
Real Server or Port Health-based Failover ..................................................................................... 83
VIP-based Failover .............................................................................................................................. 84
How the Active ACOS Device Is Selected ............................................................................................. 86
HA Pre-Emption .......................................................................................................................................... 88
HA Sets ........................................................................................................................................................ 89
HA Configuration Parameters ................................................................................................................. 90
HA Status Indicators ............................................................................................................99
In the GUI .............................................................................................................................................. 99
Configuring Layer 3 HA ..................................................................................................... 101
Configuring Layer 2 HA (Inline Mode) .............................................................................. 109
Layer 2 Inline HA Configuration Example ...........................................................................................110
Configuring Layer 3 HA (Inline Mode) .............................................................................. 117
Layer 3 Inline HA Configuration Example ...........................................................................................117
Configuring Optional Failover Triggers ............................................................................ 122
VLAN-Based Failover Example ..............................................................................................................122
Gateway-Based Failover Example ........................................................................................................123
Route-Based Failover Example .............................................................................................................124
VIP-Based Failover Example ..................................................................................................................126
Forcing Active Groups to Change to Standby Status...................................................... 128
Enabling Session Synchronization................................................................................... 128
Configuring OSPF-Related HA Parameters...................................................................... 130
OSPF Awareness of HA ..........................................................................................................................130
OSPF Support on Standby ACOS Device in Layer 3 Inline Mode ...................................................131
Manually Synchronizing Configuration Information ....................................................... 131
Configuration Items That Are Backed Up ........................................................................................... 132
page 5
Contents
Configuration Items That Are Not Backed Up .............................................................................133

Performing HA Synchronization ...........................................................................................................135
Tip for Ensuring Fast HA Failover..................................................................................... 137
HA To VRRP-A Migration .......................................................................................................... 139

Migration Exceptions ..............................................................................................................................140
Differences between HA and VRRP-A .................................................................................................140
Migrating from HA to VRRP-A ...............................................................................................................144
Reverting to HA from VRRP-A ...............................................................................................................147
VRRP-A CLI Commands ........................................................................................................... 149

VRRP-A Global Configuration Mode Commands............................................................. 150
vrrp-a common ...........................................................................................................................150
vrrp-a fail-over-policy-template ...............................................................................................150
vrrp-a force-self-standby ..........................................................................................................153
vrrp-a force-self-standby-persistent .......................................................................................154
vrrp-a interface ...........................................................................................................................155
vrrp-a l2-inline-peer-ip ................................................................................................................156
vrrp-a l3-inline-mode ..................................................................................................................156
vrrp-a ospf-inline .........................................................................................................................157
vrrp-a peer-group ........................................................................................................................157
vrrp-a preferred-session-sync-port ethernet .........................................................................157
vrrp-a restart-port-list ................................................................................................................158
vrrp-a vrid .....................................................................................................................................159
vrrp-a vrid-lead ............................................................................................................................159
VRRP-A Common Configuration Mode Commands ........................................................ 160
arp-retry ........................................................................................................................................161
dead-timer ...................................................................................................................................161
device-id .......................................................................................................................................162
disable ..........................................................................................................................................162
disable-default-vrid ....................................................................................................................162
enable ...........................................................................................................................................163
forward-l4-packet-on-standby .................................................................................................163
get-ready-time .............................................................................................................................163
hello-interval ................................................................................................................................164
hostid-append-to-vrid ................................................................................................................164
inline-mode ..................................................................................................................................165
preemption-delay ....................................................................................................................... 165
restart-time ..................................................................................................................................166
set-id .............................................................................................................................................166
track-event-delay ........................................................................................................................ 166
VRRP-A VRID Configuration Commands.......................................................................... 167
blade-parameters .......................................................................................................................167
floating-ip .....................................................................................................................................168
follow ............................................................................................................................................168
preempt-mode ............................................................................................................................169
page 6
Contents
VRRP-A Blade Parameter Configuration Commands ...................................................... 169

fail-over-policy-template ...........................................................................................................170
priority ..........................................................................................................................................170
tracking-options ......................................................................................................................... 171
VRRP-A Show Commands ................................................................................................ 172
show vrrp-a ..................................................................................................................................173
show vrrp-a all-partitions ..........................................................................................................176
show vrrp-a fail-over-policy-template ....................................................................................177
show vrrp-a hostid .....................................................................................................................178
show vrrp-a mac .........................................................................................................................178
show vrrp-a partition .................................................................................................................179
show vrrp-a setid-monitor ........................................................................................................179
show vrrp-a statistics ................................................................................................................180
show vrrp-a vrid-lead .................................................................................................................180
page 7
Contents
page 8
Overview of VRRP-A
This chapter provides an overview of VRRP-A high availability.
The following topics are covered:
• VRRP-A Overview
• VRRP-A Configuration
• VRRP-A Active / Standby Device Selection
• VRRP-A Failover
• VRRP-A and Floating IP Addresses
• VRRP-A and Configuration Synchronization
• VRRP-A and Session Synchronization
• VRRP-A Interfaces
VRRP-A Overview
VRRP-A is the ACOS implementation of high availability that is completely different from the industry-
standard implementation of Virtual Router Redundancy Protocol (VRRP). For purposes of operational
familiarity, it borrows concepts from VRRP, but is significantly different from VRRP. VRRP-A will not
inter-operate with VRRP.
VRRP-A simplifies configuration of multi-system redundancy, and allows up to eight physical or virtual
ACOS devices to serve as mutual backups for IP addresses.
VRRP-A inline mode is supported only with one VRRP-A VRID ID group.
VRRP-A can provide redundancy for the following IP resources:
• Virtual server IP addresses (VIPs)
• Floating IP addresses used as default gateways by downstream devices
• IPv6 NAT pools
• IPv4 NAT pools
• IPv4 static range lists and individual mappings for inside source NAT
page 9
VRRP-A Configuration
This section contains the following:
• Basic VRRP-A Configuration
• VRRP-A and Virtual Router IDs
• VRRP-A, Virtual Router IDs, and Partitions
Basic VRRP-A Configuration

Below figure illustrates a basic VRRP-A configuration with two devices.
FIGURE 1 Basic VRRP-A Configuration
This type of configuration is called Active-Standby mode, because only the active device processes
traffic.
The elements in this illustration are described in table below.
TABLE 1 VRRP-A Basic Configuration Elements

Element Description
Set ID Unique identifier for a set of VRRP-A devices. All devices in the set must in the same Layer 2
broadcast domain.
Device ID Unique identifier for each device within the VRRP-A set.
page 10
TABLE 1 VRRP-A Basic Configuration Elements

Element Description
Heartbeat The active ACOS device in the VRID periodically sends hello messages to the standby ACOS
device and other backup devices. The hello messages indicate that the active device for the
VRID is still operating.
For more information, see:
• “Multicast Heartbeat Destination Addresses” on page 11

• “Unicast Hearbeat Destination Addresses” on page 11
Priority Priority is used to help determine the order in which standby devices should become active
devices.
For more information, see “VRRP-A Active / Standby Device Selection” on page 14.
Multicast Heartbeat Destination Addresses

By default, VRRP-A uses an IP multicast address as the destination for VRRP-A heartbeat messages to
peers. VRRP-A sends multicast hello messages to the following addresses:
• IPv4 multicast address 224.0.0.210, MAC address 01:00:5e:00:00:D2
• IPv6 link-local multicast address FF02::D2, MAC address 33:33:00:00:00:D2
If the standby device stops receiving hello messages from the active device, operation for the VRID
fails over to the standby device. The device to which operation fails over becomes the new active
device for the VRID.
To configure multicast heartbeats, use the hello-interval command.
Unicast Hearbeat Destination Addresses

Instead of multicast heartbeat messages, you can configure VRRP-A to use unicast heartbeats instead
for layer 3 redundancy across subnets using VRRP-A.
To do so, configure a VRRP-A peer group on each device in the VRRP-A set. For redundancy in the peer
group on each ACOS device, you can configure multiple IP addresses for multiple data interfaces. You
can configure a maximum of 16 IP addresses on the peer group.
NOTE: At least one unicast address must be configured on a data interface per
peer ACOS device.
For reliability and redundancy, configure at least four IP Addresses in a peer-group, with each IP
address belonging to a different interface. This will enable you to allocate at least two interfaces per
ACOS device. The peer group configuration on each VRRP-A device in the set should be the same,
including the device’s own IP address. When a device sends VRRP-A heartbeats to the members of a
peer group, that device skips any IP addresses that belong to itself.
page 11
To configure peer groups for unicast heartbeat messages, use the vrrp-a peer-group command.
VRRP-A and Virtual Router IDs

VRRP-A device ID, set ID, and priority can be configured per Virtual Router ID (VRID), as shown below:
FIGURE 2 VRRP-A Configuration with VRIDs
The configuration example in Figure 2 is called Active-Active mode, because both devices can poten-
tially process traffic on different VIPs.
A VRID is a logical container grouping functional configuration elements (for example, NAT pools, vir-
tual servers, or floating IP addresses) together. Those elements, in turn, are picked up and processed
by another device in the VRRP-A set in case of a failover.
By default, the shared partition and each L3V partition has its own VRID. The numerical value for this
default VRID is 0; in previous releases, you could configure this VRID using the keyword default, which
is no longer supported in Release 4.0.
Note: By default, a server load balancing virtual IP (VIP) is associated with VRID 0.
Admins with write privileges for the partition can assign a floating IP address to the partition’s VRID.
Generally, the floating IP address provides redundancy for the default gateway IP address used by
downstream devices. (For more information, see “VRRP-A and Floating IP Addresses” on page 23.)
Parameters related to selection of the active device and to failover also can be configured.
page 12
The total number of VRIDs that can be configured is dependent upon the device model.
Leader and Follower VRIDs

Configure a VRID as a “leader” VRID and some others as “follower” VRIDs. The benefit of configuring the
leader VRID is that when you are running the risk of consuming all your resources, one VRID can serve
as the leader and others can be configured to operate as followers. This means that only on one VRID
will you be able to configure all capabilities, such as configuring the failover policy template, the pre-
empt mode, priority, and tracking options, while in the follower VRID, you can only configure Floating IP
Addresses.
Any time the maximum number of VRIDs is exceeded for a device, the VRIDs are automatically config-
ured as follower VRIDs or can be explicitly configured to be added as a follower VRID. To configure a
leader or a follower VRID. refer to “Configuring a Leader and Follower VRID” on page 49.
VRID Virtual MAC Addresses

VRRP-A assigns a virtual MAC address to each VRID. The VRRP-A virtual MAC addresses are num-
bered as follows:
021f.a000.nnnn
The last 2 bytes (nnnn portion) of the address indicate the partition ID, VRRP-A set ID, and VRID.
VRRP-A, Virtual Router IDs, and Partitions

VRRP-A is supported in the shared partition and L3V partitions. Layer 3 Virtualization allows each L3V
partition to have its own VRID, independent from the VRIDs belonging to other partitions.
page 13
VRRP-A Active / Standby Device Selection
Figure 3 shows an example configuration with VRID instances spanning L3V partitions across sepa-
rate physical devices.
FIGURE 3 VRRP-A Configuration with Partitions
In this example, a pair of ACOS devices are configured with L3V partitions. The VIPs and other IP
resources in each partition are backed up by the partition’s VRID. At any given time, one of the devices
is the active device (A) for a VRID and the other device is the standby (S) for the VRID. For more infor-
mation about how the active device is selected, see “VRRP-A Active / Standby Device Selection” on
page 14.

• VRRP-A Active Device Selection Overview
• Event Tracking for Weight and Priority
• Priority Calculation
• Track Event Delay
• Preemption and VRRP-A Failover Behavior with Preemption Disabled
• Preemption Delay
• Active Device Selection Examples
page 14
VRRP-A Active Device Selection Overview

Figure 4 shows the flowchart about how a device is selected as the Active device. This process is per-
formed per VRID.
FIGURE 4 VRRP-A Device Selection Flowchart
NOTE: VRRP-A active device selection is unrelated to, and completely indepen-
dent of, aVCS vMaster device selection in a virtual chassis.
The VRRP-A device selection process consists of two levels of failover considerations:
• The weight assigned to an event.
• Priority value assigned as part of the VRRP-A deployment.
While both weight and priority are factored in to failover decisions, the weight of the VRID takes prece-
dence over the VRID’s priority.
Each VRID is allocated a fixed, total weight of 65534 and each event is allocated a corresponding, con-
figurable weight of 1-255. When the event occurs, the configured weight for the event is deducted from
the total weight assigned to the VRID. Some events (for example, when an interface goes down) are
considered to be critical for a VRID and will reduce the VRID’s weight. ACOS devices that are part of the
same set periodically exchange their weight information with peer ACOS devices.
VRRP-A determines the Active or Standby status based on received weight information. Based on the
newly computed weight, a failover will occur from an ACOS device of a lower weight to another ACOS
device of a higher weight. This concept is called preemption.
page 15
Preemption based on weight is always enabled. Preemption based on priority can be enabled or dis-
abled.
Event Tracking for Weight and Priority

An ACOS device can be configured to track VRRP-A events for weight or priority or for both. While both
weight and priority can be configured to track the exact same events, such as the state of gateways,
trunks, VLANs, interfaces, or routes, how they are accessed and assigned these values are different.
When you configure VRRP-A using the GUI or command line at the VRRP-A configuration level, you can
specify the priority assigned to each event. When the event occurs, the value you assign to the event
will be deducted from the priority you configure from 1-255 for the VRID of a given ACOS device.
However, if you specify a value for a failed event using a VRRP-A failover template, you are configuring
the weight assigned to an event that will be deducted from a fixed total weight of 65534 assigned to
every VRID for an ACOS device.
The fixed total weight for a VRID is not user configurable, unlike the priority assigned the VRID for an
ACOS device which is configurable. A failed event will result in a deduction of the weight assigned to
the event from the fixed total weight for the VRID. Since the weight of each VRID is tallied to figure out
the weight and/or priority of an ACOS device, when multiple devices are configured with VRRP-A, this
value is used to gauge the device that will serve as the Active or the Standby device. When the weight
for all VRRP-A enabled devices are unequal, the device with the highest weight will serve as the Active
device, the rest will be placed in a Standby state.
Priority Calculation
Every few seconds, VRRP-A recalculates the priority for each VRID on the active device for the VRIDs.
To calculate the priority, VRRP-A subtracts the priority values for all optional failover trigger events that
have occurred from the configured priority value. The lowest value to which the priority can be reduced
is 1.
Once the link or server health is restored, the failover trigger event is no longer occurring and the priority
value is not subtracted during the next priority calculation.
Track Event Delay

To prevent unnecessary failovers caused by brief, temporary link or server health changes, VRRP-A
uses a track event delay. The track event delay is the number of seconds a failover-causing event must
persist before failover occurs.
page 16
For example, if the track event delay is 5 seconds, and a tracked link goes down for 3 seconds, then
comes back up, no failover is triggered. Failover is triggered only if the link stays down for at least 5
seconds.
The track event delay can be from 1-tenth second to 10 seconds. The default is 3 seconds.
Preemption and VRRP-A Failover Behavior with Preemption Disabled

Preemption allows failover to be triggered by manually changing the priority on one or more devices so
that the active device no longer has the highest priority for the VRID.
Preemption is enabled by default. If preemption is disabled, failover is not triggered by manual priority
changes. If disabling preemption, it is strongly recommended to configure a VRRP-A Policy-Based
Failover Template to govern any failover events.
The VRRP-A failover behavior with preemption mode disabled is as follows. When a heartbeat link is
lost, the VRRP pair becomes Active / Active. If preemption is disabled, during the time that a heartbeat
link is re-established, the VRRP device that received the heartbeat message first becomes the Standby
device.
NOTE: CLI configuration for disabling preemption mode is preempt-mode dis-

able.
Preemption can be configured on an individual VRID basis, by shared partition admins and private par-
tition admins.
Preemption Delay
If VRRP-A preemption is enabled, failover can be triggered by VRRP-A configuration changes, in addi-
tion to network changes. By default, when preemption is enabled, failover can occur as soon as 3 sec-
onds after an applicable configuration change takes effect.
This release enables you to configure a delay between VRRP-A configuration changes and the failover
that occurs due to the changes. The default VRRP-A preemption delay is 6 seconds (60 units of 100
ms); the value can be customized to a value from 100 ms (1 unit of 100 ms) to 25.5 seconds (255 units
of 100 ms).
NOTE: Preemption delay is only valid when VRRP-A is configured in multi-active

environments, where a minimum of three active devices are configured.
In deployments where many sessions are synchronized, setting the preemption delay to a longer value
can help ensure there is time for session synchronization to be completed before failover.
page 17
For more information about configuring preemption delays, see “Configuring Preemption Delays” on
page 40.
Active Device Selection Examples

One device in the VRRP-A set can be active at any given time for a given partition’s VRID. The active
device for a given VRID is selected based on VRRP-A priority. The device with the highest VRRP-A prior-
ity for a VRID becomes the active device for that VRID. Each VRID has its own priority value, which can
be 1-255. The default is 150. Figure 5 shows an example.
FIGURE 5 Selection of Active Device
In this example, the priority of VRID 0 is set to 255 for the shared partition and partition CorpB on device
1, and for partitions CorpA and CorpC on device 2. The active/standby state of each VRID on each
device is based on these priority settings. The “A” in the illustration denotes the active
If more than one device has the highest priority value, the device with the lowest device ID becomes the
active device. For example, if the VRID priority is left set to the default value on all devices, device 1
becomes the active device for the VRID.
VRRP-A selects the device that has the second-highest priority for a VRID as the standby device for the
VRID. In VRRP-A deployments on more than 2 devices, if more than one device has the second-highest
priority value, the device with the lowest device ID becomes the standby device. Figure 6 shows an
example.
page 18
FIGURE 6 Selection of Standby Device
The priority for VRID 0 in partition CorpB is set to 255 on device 1 but is left to its default value on the
other devices. Since device 2 is has the lowest device ID number among the remaining devices, device
2 becomes the standby for the VRID (denoted by “S” in the illustration). The other devices are backups
(denoted by “B” in the illustration).
If session synchronization is enabled, sessions are copied from device 1 to device 2. If a failover
occurs, device 2 becomes the active device and device 1 becomes the standby device. Sessions are
not synchronized to the backups.
If the standby device becomes unavailable or its priority value is reduced below the priority value on
another backup device, the other device becomes the new standby for the VRID, as shown in Figure 7.
page 19
FIGURE 7 Selection of New Standby Device
NOTE: In VRRP-A deployments of 3 or more devices, moving the active role to a

backup other than the standby can cause loss of synchronized sessions,
since sessions are synchronized only from the active device to the
standby device.
To avoid loss of sessions in this case, first change the priority on the
backup so that it will assume the role of standby. Then, when VRRP-A
fails over, the standby will have the synchronized sessions.
page 20
VRRP-A Failover
VRRP-A Failover
Failover of a VRID from the active ACOS device to the standby ACOS device can be triggered by any of
the following events:
• The standby ACOS device stops receiving VRRP-A hello messages from the active ACOS device.
• The VRRP-A priority on the active device is dynamically reduced below the priority on the standby
device. The priority can be dynamically reduced when a tracked default gateway, data port, or
VLAN goes down, a tracked route is not in the data route table (see tracking-options for further
information), or a server bound to a service group in a VIP fails its health check.
• The VRRP-A priority on the active device is manually reduced below the priority on the standby
device by an administrator, and preemption is enabled.
• The force-self-standby option is used on the active device by an administrator.
Policy-Based Failover
VRRP-A provides flexible event tracking and policy-based failover support through configurable tem-
plates. This feature allows policy-based failover even when VRRP-A preemption is disabled and the
ACOS device typically would remain in an Active state, despite VRID priority changes. It allows for
event-based failover once a tracked event occurs.
For more information, see “VRRP-A Policy-Based Failover Template” on page 55.
Dynamic Priority Reduction

Depending on configuration, failover can be triggered even if the active device is still operational. For
each VRID, each device begins with a statically configured priority for the VRID.
You can configure the priority of a VRID to be dynamically reduced based on changes in system or net-
work conditions. For example, you can configure link tracking on an Ethernet port. If the link goes down,
the VRID priority on the device is reduced by the configured amount. Figure 8 shows an example.
page 21
VRRP-A Failover
FIGURE 8 Failover Based on Dynamic Priority Reduction
In this example, link tracking is enabled for Ethernet port 6, and configured to reduce the VRID priority
by 155 if the link goes down. Device 1 has the higher configured priority value for VRID 0 in partition
CorpB, and is the active device. However, if the link on Ethernet port 6 goes down, the priority is dynam-
ically reduced below the priority value on device 2. Device 2 therefore becomes the active device for the
VRID.
See “Events Tracked for Weight via the Templates” on page 60 for a summary of events that can be
tracked.
By default, none of the dynamic failover triggers are configured. They can be configured on an individ-
ual partition basis.
Force-Self-Standby
The force-self-standby option in vrrp-a force-self-standby provides a simple method to force a failover,
without the need to change VRID priorities and use preemption.
The option can be entered by shared partition admins and private partition admins. If entered in the
shared partition, the option applies to all VRIDs on the device. If entered in a private partition, the option
applies to all VRIDs within that partition but does not affect VRIDs in other partitions.
The option remains in effect until one of the other failover triggers occurs or the device is reloaded or
rebooted. The option is not added to the configuration and does not persist across reloads or reboots.
page 22
VRRP-A and Floating IP Addresses
VRRP-A and Floating IP Addresses

VRRP-A supports use of floating IP addresses. Floating IP addresses can reside on any device in the
VRRP-A set, and always reside on the device that is currently active. Because floating IP addresses are
always reachable regardless of the VRRP-A states of individual devices, the floating IP addresses pro-
vide network stability.
In a typical VRRP-A deployment, floating IP addresses are configured for each of the ACOS device inter-
faces that are used as nexthop interfaces by other devices. Figure 9 shows a simple example.
FIGURE 9 Floating IP Address
In this example, a device uses ACOS device IP address 10.8.8.6 as its default gateway. This address is
configured as a floating IP address on the ACOS device, and always resides on the active VRRP-A
device.
Because the address is configured as a floating IP address on the ACOS device, the address remains
reachable by the client even if a VRRP-A failover occurs. For example, if VRRP-A fails over from device
1to device 2, then the floating IP address also moves to device 2.
page 23
VRRP-A and Configuration Synchronization
NOTE: A floating IP address cannot be the same as an address that already

belongs to a device. For example, the IP address of an ACOS device inter-
face cannot be a floating IP address.
Advertisement of the Floating IP MAC Address After Failover
When a floating IP address moves from one ACOS device to another following failover, the MAC
address associated with the floating IP address changes.
To help other devices find a floating IP address following failover, the new active ACOS device sends
IPv4 gratuitous ARPs (for an IPv4 floating IP address) or ICMPv6 neighbor advertisements (for an IPv6
floating IP address). The other devices in the network learn the new MAC address from the gratuitous
ARPs or neighbor advertisements.
VRRP-A and Configuration Synchronization

VRRP-A supports the following methods of configuration synchronization:
• Automated – Uses ACOS Virtual Chassis System (aVCS) to automatically synchronize the con-
figuration. See “Automated Configuration Synchronization” in Configuring ACOS Virtual Chassis Systems.
• Manual – Use the configure sync CLI command. For more information, refer to the Command Line
Interface Reference.
See Viewing VRRP-A Information for further detail about viewing the configuration synchronization sta-
tus.
VRRP-A and Session Synchronization

VRRP-A uses one active device and one standby device for a given VRID. If session synchronization
(also called connection mirroring) is enabled, the active device backs up active sessions on the standby
device.
Session synchronization applies primarily to Layer 4 sessions. Session synchronization does not apply
to DNS sessions. Since these sessions are typically very short-lived, there is no benefit to synchronizing
them. Likewise, session synchronization does not apply to NATted ICMP sessions or to any static NAT
sessions. Synchronization of these sessions is not needed since the newly active device will create a
new flow for the session following failover.
Session synchronization is disabled by default and can be enabled on individual virtual ports.
page 24
VRRP-A Interfaces
To enable session synchronization, in the configuration of a virtual port for a virtual server, add the
ha-conn-mirror CLI command. This is only allowable on certain port types, and whether the port type is
configurable for session synchronization can be identified by doing a query for the ha-conn-mirror CLI
command after the port type configuration.
slb virtual-server VS 192.0.2.0

port 80 tcp
ha-conn-mirror
A specific port for session synchronization can be configured by using the

vrrp-a preferred-session-sync-port ethernet CLI command.
• For more information on ha-conn-mirror CLI command, refer to the Command Line Interface Reference
for ADC Guide.
• For more information on the vrrp-a preferred-session-sync-port ethernet CLI command, see
“vrrp-a preferred-session-sync-port ethernet” on page 157.
VRRP-A Interfaces
VRRP-A sends hello messages and session synchronization messages on the ACOS device’s VRRP-A
interfaces.
Each ACOS device providing VRRP-A for a VRID must have at least one Up Ethernet interface that can
reach the other ACOS devices. If an ACOS device cannot receive hello messages from the other devices
for the VRID, the ACOS device's VRRP-A state becomes Active. In this case, there is more than one
active VRRP-A device for the same VRID, which is invalid. One of the active VRRP-A devices is the
ACOS device that does not have a connection to the other devices. The other active VRRP-A device is
the ACOS device that can still reach the other ACOS devices (standby VRRP-A devices).
By default, no VRRP-A interfaces are explicitly configured. In this case, VRRP-A uses all Up Ethernet
interfaces to send and listen for hello messages. For an interface that belongs to more than 1 VLAN,
the ACOS device uses the lowest VLAN ID to which the interface belongs.
If a data interface has both IPv4 and IPv6 addresses, the primary IPv4 address is used.
Admins with write privileges for the shared partition can explicitly specify the ACOS device interfaces to
use as VRRP-A interfaces. In this case, the specified interfaces are used as VRRP-A interfaces by the shared
partition and all L3V partitions.
Explicitly Configured VRRP-A Interfaces

Optionally, you can explicitly configure individual interfaces to act as VRRP-A interfaces. In this case,
the ACOS device uses only the configured VRRP-A interfaces for hello messages.
page 25
VRRP-A Interfaces
For individual L3V partitions, the interface requirement differs depending on whether VRRP-A inter-
faces are explicitly configured:
• If no VRRP-A interfaces are explicitly configured (the default situation), each L3V partition must
have at least one Ethernet interface that can reach the other L3V partitions for the VRID.
• If at least one interface in the shared partition is explicitly configured as an VRRP-A interface, that
interface is used for the shared partition's VRID hello messages, and for the hello messages of all
the VRIDs in the L3V partitions.
VRRP-A Interface Types and VRRP-A State

Changes to the state of a VRRP-A interface can trigger a failover. By default, the VRRP-A state of an
interface can be Up or Down. Optionally, you can specify the VRRP-A interface type as one of the fol-
lowing:
• Server interface – A real server can be reached through the interface.
• Router interface – An upstream router (and ultimately, clients) can be reached through the inter-
face.
• Both – Both a server and upstream router can be reached through the interface.
Note: The both option is not recommended for new VRRP-A configurations and exists as an inherited
attribute for legacy High Availability (HA) configuration.
Using the GUI to Configure a VRRP-A Interface

To use the GUI to configure a VRRP-A interface:
1. Hover over System in the menu bar, the select VRRP-A.

2. Select the VRRP-A Interface tab, then select the interface type you want to enable from the drop-
down list.
3. For the interface you want to enable for VRRP-A, click Edit in the Actions column. The Update
VRRP-A Interface window is displayed.
page 26
VRRP-A Interfaces
FIGURE 10 Update VRRP-A Interface Window
NOTE: For specific information about the fields on this screen, please refer to
the online help.
4. On the Update VRRP-A Interface page, select the options you want to configure for the VRRP-A
interface.
You can enable or disable VRRP-A, or set the interface type and state (see “VRRP-A Interface
Types and VRRP-A State” on page 26).
Using the CLI to Configure a VRRP-A Interface

Use the vrrp-a interface command to configure a VRRP-A interface. For example, to configure ethernet
interface 2 as the VRRP-A interface:
ACOS(config)# vrrp-a interface ethernet 2

ACOS(config-ethernet:2)#
Then, you can configure the interface type and state. The following example allows upstream routers to
be reached through this interface, and assign the interface to VLAN 2:
ACOS(config-ethernet:2)# router-interface vlan 2
See “vrrp-a interface” on page 155 for more details.
page 27
VRRP-A Interfaces
Preferred Receive Interface for Session Synchronization

By default, VRRP-A on a backup device automatically selects the Ethernet interface on which to receive
synchronized sessions. The ACOS device provides an option that enables you to specify the Ethernet
interface(s) on which it is preferred to receive synchronized sessions.
Using the GUI to Configure the Session Synchronization Interface for VRRP-A
1. Hover over System in the menu bar, then select VRRP-A.
2. Click the Settings tab and select Global; this should be the active page by default.
3. Near the bottom of the page, expand the Session Sync Port category to display the configuration
area for the feature.
FIGURE 11 . Session Sync Port Category
4. Select “Ethernet” from the Interface Type drop-down list.

5. Specify the interface number in the Interface field.
6. If the interface belongs to more than one VLAN, specify the VLAN ID in the VLAN field.
7. Click Add.
8. Repeat for an additional interfaces.
9. Click OK
Using the CLI to Configure the Session Synchronization Interface for VRRP-A
To specify the Ethernet interface on which to receive synchronized sessions, use the vrrp-a preferred-
session-sync-port ethernet command on the device that you want to receive the session information.
For example, if you want to receive session information on Ethernet port 2 on device ACOS-2:
ACOS-2(config)# vrrp-a preferred-session-sync-port ethernet 2
page 28
Manually Synchronizing Configuration Information

Manual synchronization of configurations is done by running the configure sync command. This
replaces the 2.7.x series ha sync command. See configure sync in the “Command Line Interface Refer-
ence” Guide for more information on configuration options. For information on configuration objects
that are included and not included in a manual synchronization, see the appropriate topic below:
NOTE: Manual configuration is not necessary if running ACOS Virtual Chassis

System (aVCS). See the Configuration Synchronization without Reload sec-
tion in the “Configuring ACOS Virtual Chassis Systems” Guide for more
information.
• Requirements for Synchronization Link
• Configuration Items That Are Backed Up
• Configuration Items That Are Not Backed Up
• Performing Configuration Synchronization
• Displaying the Configure Sync State
Requirements for Synchronization Link

SSH management access must be enabled on both ends of the link before performing a manual syn-
chronization.
Before synchronizing the Active and Standby ACOS devices, verify that both are running the same soft-
ware version. Configuration synchronization between two different software versions is not recom-
mended, since some configuration commands in the newer version might not be supported in the older
version.
The configuration synchronization process does not check user privileges on the Standby ACOS device
and will synchronize to it using read-only privileges. However, you must be logged onto the Active
ACOS device with configuration (read-write) access.
If the configuration includes Policy-based SLB (black/white lists), the time it takes for synchronization
depends on the size of the black/white-list file. This is because the synchronization process is blocked
until the files are transferred from active to standby.
Do not make other configuration changes to the Active or Standby ACOS device during synchroniza-
tion.
page 29
Data that is synchronized from a Standby ACOS device to an Active ACOS device is not available on the
Active ACOS device until that device is rebooted or the software is reloaded.
The configure sync command will not function if vcs enabled is active.
NOTE: In 4.x, the reload action is not allowed.
Configuration Items That Are Backed Up

The following configuration items are backed up during the configuration synchronization:.
• Admin accounts and settings • SLB

• AAA settings • RAM caching
• DDoS protection settings • DNS security and caching
• ICMP rate limiting • FWLB
• Floating IP addresses • GSLB
• IP NAT configuration, including LSN and DS-Lite • Data Files:
• ACLs • aFleX files
• Health monitors • External health check files
• IP limiting settings • SSL certificates, private-key files, and CRLs
• PBSLB settings • Class-list files
• Black/white-list files
NOTE: The objects backed up in 4.x is same as 2.7.x.
Configuration Items That Are Not Backed Up

The following configuration items are not backed up during the configuration synchronization.
• Interface-specific management access settings • LACP settings

• Hostname • Interface settings
• MAC addresses • OSPF or IS-IS settings
• Management IP addresses • ARP entries or settings
• Static Trunks or VLANs
NOTE: The objects not backed up in 4.x is same as 2.7.x.
page 30
Performing Configuration Synchronization

To synchronize the ACOS device configurations, use the steps described below.
Using the GUI

1. Select System > Settings > Sync Settings.
2. In the User, Password and Destination IP Address fields, enter the admin username, password cre-
dentials and IP address of the peer device.
3. Configure the other fields on this page as desired; refer to the GUI online help for more information
about each field.
4. Click OK.
Using the CLI

The configure sync commands are available at the global configuration level of the CLI.
• To synchronize the running-config and startup-config, use the configure sync all command.
This will also sync data files in addition to the local running configuration and start up configura-
tion to the peer device.
• To synchronize the Active ACOS device’s running-config to the Standby ACOS device’s running-
config, use the configure sync running command. This will sync data files in addition to the run-
ning configuration to the peer device.
For more detailed information, see “configure sync” in the Command Line Interface Reference.
NOTE: Synchronization of just the data files is not available in 4.x.
Displaying the Configure Sync State

Introduced in 4.x, the synchronization state for running and start-up configurations can be viewed by
using the CLI command show config-sync.
An example output is shown from the source device.
vThunder-Active(config)# show config-sync

Partition Name Sync Status for running-config and startup-config
----------------------------------------------------------
shared (running-config) sync to ip 192.168.105.127 at 20:04:04 IST Thu Jul 17 2008
page 31
shared (startup-config) sync to ip 192.168.105.127 at 20:04:04 IST Thu Jul 17 2008
An example output is shown from the destination device.
vThunder-standby# show config-sync

----------------------------------------------------------
shared (running-config) is synced from ip 192.168.105.120 at 06:25:19 GMT Mon Nov
27 2017
shared (startup-config) is synced from ip 192.168.105.120 at 06:25:20 GMT Mon Nov
27 2017
Performing a write operation, or modifying a configuration will change the sync status for the modified
configuration.
For example, running the write memory command will change the start-up config state from “sync” to
“not-synced”.
vThunder-Active# write memory

Building configuration...
Write configuration to profile "conn_40"
[OK]
vThunder-Active#show con
vThunder-Active#show config-s
vThunder-Active# show config-sync
----------------------------------------------------------
shared (running-config) sync to ip 192.168.105.127 at 20:04:04 IST Thu Jul 17 2008
shared (startup-config) not synced because write memory at 20:09:25 IST Thu Jul
17 2008
If the running configuration is modified, the running-config state will change from “sync” to “not-
synced”.
For example, the following configuration is added to the running-configuration.
vThunder-Active(config)# cgnv6 nat pool a 1.1.1.1 netmask /24
Now, running the show config-sync command, the running configuration is no longer synced.
page 32
vThunder-Active(config)# show config-sync

----------------------------------------------------------
shared (running-config) not synced because it's changed at 07:02:33 GMT Mon Nov
27 2017
shared (startup-config) not synced because write memory at 06:30:24 GMT Mon Nov
27 2017
page 33
page 34
Deploying VRRP-A
This chapter provides examples of VRRP-A deployment.
The following are covered:
• Basic VRRP-A Deployment
• Force-Self-Standby Reload or Restart Persistence
• Viewing VRRP-A Information
• Configuring Preemption Delays
• VRRP-A Configuration Examples
• Configuring a Leader and Follower VRID
• VRRP-A Status in CLI Prompt
Basic VRRP-A Deployment

Basic VRRP-A deployment requires only the following steps on each ACOS device:
1. Specify the VRRP-A device ID and set ID, then enable VRRP-A using the enable command:
ACOS(config)# vrrp-a common
ACOS(config-common)# device-id 5
ACOS(config-common)# set-id 10
ACOS(config-common)# enable
ACOS-Active(config-common)# exit
ACOS-Active(config)#
You can specify a device ID from 1-8, and a set ID from 1-15. Note that the prompt is updated to
reflect whether the device is a standby device, or the active device. Ensure that each VRRP-A clus-
ter in a Layer 2 broadcast domain have unique set IDs.
NOTE: If aVCS is configured, its device ID is the same as the VRRP-A device ID.
If Scaleout is configured and enabled, VRRP-A should NOT be enabled.
2. As needed, configure floating IP addresses for individual VRIDs.
page 35
Force-Self-Standby Reload or Restart Persistence
The following example configures a floating IP address (192.168.9.9) for VRID 13:
ACOS-Active(config)# vrrp-a vrid 13
ACOS-Active(config-vrid:13)# floating-ip 192.168.9.9
Force-Self-Standby Reload or Restart Persistence

If the force-self-standby option is selected via the CLI, this feature will allow a single partition, multiple
partitions, or the device to remain in a forced self-standby state even though the device or partition
goes through a reload or device restart.
To place VRRP-A VRID 2 into a forced-self-standby state, issue the following command:
ACOS(config)# vrrp-a force-self-standby vrid 2 enable
To place VRID 2 in a self-standby state even after a restart or reload, use the following command:
ACOS(config)# vrrp-a force-self-standby-persistent vrid 2

Doing so may cause some of the VRID(s) to become inactive in the whole vrrp-a set.
WARNING: Please confirm that you want to perform this operation.
Doing so may cause some of the VRID(s) to become inactive in the whole vrrp-a set; make
sure you verify that an active device will be available after performing this operation.
[yes/no]: yes
If you issue the vrrp-a force-self-standby command, the partition or device will not be placed in a force-
self-standby state after the device reload or restart completes. You must configure self-standby with
vrrp-a force-self-standby-persistent to have your device retain its self-standby state after a future
reload or restart operation.
To place all VRIDs in partition (partA) in self-standby state even after a restart or reload, execute the fol-
lowing command in partition “partA:”
ACOS[partA](config)# vrrp-a force-self-standby enable

[yes/no]: yes
page 36
Viewing VRRP-A Information

To view VRRP-A configuration information and statistics, use the commands described in VRRP-A
Show Commands.
To view VRRP-A synchronization status information, see Viewing VRRP-A Config-Sync Status in the
CLI.
Viewing VRRP-A Config-Sync Status in the CLI

For config-sync status, use the show config-sync command.
In the following examples, ACOS1 is the local device and ACOS2 is the peer.
Config-Sync Status for New and Reloaded/Rebooted Devices
In the case of a new device with no config-sync configuration, or when a device is reloaded or rebooted,
the sync status of the running-config will always be reset and the sync status will be “N/A”. For exam-
ple:
ACOS1(config)# show config-sync detail

------------------------------------------------------------------------------------
shared (running-config)N/A
shared (startup-config)N/A
shared (running-config)N/A
This means that if you already have config-sync configured and the device is rebooted, you will have to
reconfigure the config-sync settings in the running-config. The sync status of the startup-config per-
sists through any reload or reboot operation; and will not be changed by the reload or reboot process.
Config-Sync Status After HA Sync
The following commands sync both the running-config and startup-config for the shared partition from
the local device to the peer, then view the config-sync status:
ACOS1(config)# configure sync all partition shared 192.168.216.202

Running config will be sync’ed, but it has been changed.
Do you want to save before sync’ing? [y/n]:y
Running-config saved.
User name []? admin
Password []?
ACOS1(config)#
page 37
ACOS1(config)# show config-sync

------------------------------------------------------------------------------------
shared (running-config) sync to ip 192.168.216.202 at 20:32:05 IST Wed May 18 2016
shared (startup-config) sync to ip 192.168.216.202 at 20:32:27 IST Wed May 18 2016
The output from the peer device (ACOS2) shows that both the running-config and startup-config are
synced from ACOS1:

------------------------------------------------------------------------------------
shared (running-config) is synced from ip 192.168.216.201 at 20:31:54 IST Wed May
18 2016
shared (startup-config) is synced from ip 192.168.216.201 at 20:32:13 IST Wed May
18 2016
Config-Sync Status After Changes are Made in the Running-Config
If any configuration changes are made in the running-config on ACOS1, the status will change. Sup-
pose we make a configuration change on ACOS1 (for example, specify a VRRP-A failover policy tem-
plate), then view the config-sync status again:
ACOS1(config)# vrrp-a fail-over-policy-template temp

ACOS1(config-failover-policy)# show config-sync
------------------------------------------------------------------------------------
shared (running-config) not synced because it's changed at 20:36:50 IST Wed May
18 2016
shared (startup-config) sync to ip 192.168.216.202 at 20:32:27 IST Wed May 18 2016
The status is changed to “not synced” because of the change made in the running-config. After running
the write memory command, the status appears as shown below:
ACOS1(config)# write memory

Building configuration...
Write configuration to primary default startup-config
[OK]
------------------------------------------------------------------------------------
18 2016
shared (startup-config) not synced because write memory at 20:37:50 IST Wed May
page 38
18 2016
The sync status of the startup-config is now “not synced” because of the change.
Config-Sync Status When Synced From the Peer Device
Suppose that later on, we sync the running-config from ACOS2 to ACOS1. Below is the detail output
from the local device (ACOS1) after this happens:

------------------------------------------------------------------------------------
shared (running-config) sync to ip 192.168.216.202 at 08:19:37 IST Fri May 13 2016
shared (running-config) is synced from ip 192.168.216.202 at 18:40:39 IST Mon May
16 2016
Viewing Detailed Config-Sync Status
The detail option shows when the “sync to” status changed to the “is synced from” status, or vice
versa.
In this example, the configuration is synced from ACOS2 to ACOS1:
ACOS2(config)# configure sync all partition shared 192.168.216.201

User name []? admin
Password []?
ACOS2(config)#
The show config-sync command on ACOS1 will now show the “is sync from” status as the most recent
sync status:

------------------------------------------------------------------------------------
18 2016
18 2016
The detail option can be used to view information about when the sync status was changed:

page 39
Configuring Preemption Delays
------------------------------------------------------------------------------------
18 2016
shared (startup-config) not synced because write memory at 20:37:50 IST Wed May
18 2016
18 2016
18 2016
The highlighted lines above show the previous sync status of both the running-config and startup-con-
fig on ACOS1 before the sync from ACOS2 to ACOS1.
For more information, see “show config-sync” in the Command Line Interface Reference.

• Use the GUI to Configure VRRP-A Preemption Delay
• Use the CLI to Configure VRRP-A Preemption Delay
Use the GUI to Configure VRRP-A Preemption Delay

1. Navigate to System >> VRRP-A >> Global.
2. Edit the value in the Preemption Delay field, to a value from 1-255. The default VRRP-A preemption
delay is 6 seconds (60 units of 100 ms). You can globally set the delay to a value from 100 ms (1
unit of 100 ms) to 25.5 seconds (255 units of 100 ms).
3. Click OK.
Use the CLI to Configure VRRP-A Preemption Delay

To configure the VRRP-A preemption delay, use the preemption-delay command at the VRRP-A com-
mon configuration level of the CLI.
In the example below, the show vrrp-a command reveals three devices in Active-Active-Active mode:
ACOS# show vrrp-a

vrid 0
Unit State Weight Priority
page 40
1 (Local) Active 65534 200

became Active at: Aug 5 05:09:20 2015
for 0 Day, 5 Hour,10 min
2 (Peer) Standby 65534 180 *
3 (Peer) Standby 65534 160
vrid 1
1 (Local) Standby 65534 160
became Standby at: Aug 4 06:23:39 2015
2 (Peer) Active 65534 200
3 (Peer) Standby 65534 180 *
vrid 2
2 (Peer) Standby 65534 160 *
vrid that is running: 0 1 2
To see how preemption delay works, suppose we track route 110.0.0.0 255.255.255.0:
ACOS# show run | sec vrrp-a vrid 0
vrrp-a vrid 0
blade-parameters
priority 200
tracking-options
route 110.0.0.0 255.255.255.0 priority-cost 255
vrrp-a vrid 0
blade-parameters
priority 200
tracking-options
blade-parameters
priority 180
tracking-options
blade-parameters
priority 160
tracking-options
page 41
An interface becoming unavailable would also cause the route to disappear and then reappear. Without
preemption delay, the following sequence of events would occur (all times given are approximate and
will depend on your exact configuration):
• After the interface goes down, the route disappears (less than 1 second)
• The ACOS device notices the missing route and lowers the device priority for the VRID (less than
1 second).
• Failover occurs (less than 1 second)
• The route is restored (several seconds, depending on your specific configuration)
• The devices notice the route and restore the original device priority for the VRID (less than 1 sec-
ond)
• Preemption happens 8 seconds after the original device priority is restored
In the same scenario, with preemption delay configured for 25.5 seconds:
ACOS# show run | sec vrrp-a common

vrrp-a common
device-id 1
set-id 1
enable
preemption-delay 255
Below is the timing of the same sequence of events:
• After the interface goes down, the route disappears (less than 1 second)
• The ACOS device notices the missing route and lowers the device priority for the VRID (less than
1 second).
• Failover occurs (less than 1 second)
• The route is restored (several seconds, depending on your specific configuration)
• The devices notice the route and restore the original device priority for the VRID (less than 1 sec-
ond)
• Preemption happens 25 seconds after the original device priority is restored
page 42
VRRP-A Configuration Examples

The following sections show configuration examples for VRRP-A. The first example shows a very basic
deployment using the minimum required commands. The second example includes priority configura-
tion changes and tracking.
Simple Deployment
The following commands deploy VRRP-A on a set of 2 ACOS devices.
Commands on ACOS-1
Enter the following commands on ACOS-1:
ACOS-1(config)# vrrp-a common

ACOS-1(config-common)# device-id 1
ACOS-1(config-common)# set-id 1
ACOS-1(config-common)# enable
Commands on ACOS-2
Enter the following commands on ACOS-2:

Deployment with Custom Priority Settings

The following commands configure VRRP-A on 2 ACOS devices, with the priority settings shown in
Figure 5 on page 18.
• On device ACOS-1, the priority value is set to 255 on the shared partition’s VRID 0 and partition
CorpB’s VRID 0. The priority value is left set to its default (150) for CorpA and CorpC; the priority
does not need to be set since this is the default value.
• On device ACOS-2, the priority value is set to 255 on the VRID 0s in partitions CorpA and CorpC.
The priority value is left set to its default (150) for the shared partition and for CorpB; the priority
does not need to be set since this is the default value.
page 43
These commands also configure a floating IP address for each VRID. Figure 5 on page 18 does not
include the floating IP addresses. (For more on floating IP addresses, see “VRRP-A and Floating IP
Addresses” on page 23.)
Commands on ACOS-1
ACOS-1(config-common)# exit
ACOS-1(config)# vrrp-a vrid 0
ACOS-1(config-vrid:0)# floating-ip 10.10.10.2
ACOS-1(config-vrid:0)# blade-parameters
ACOS-1(config-vrid:0-blade-parameters)# priority 255
ACOS-1(config-vrid:0-blade-parameters)# exit
ACOS-1(config-vrid:0)# exit
ACOS-1(config)# active-partition CorpB
Current active partition: CorpB
ACOS-1[CorpB](config)# vrrp-a vrid 0
ACOS-1[CorpB](config-vrid:0)# floating-ip 30.30.30.2
ACOS-1[CorpB](config-vrid:0)# blade-parameters
ACOS-1[CorpB](config-vrid:0-blade-parameters)# priority 255
ACOS-1[CorpB](config-vrid:0-blade-parameters)# exit
ACOS-1[CorpB](config-vrid:0)# exit
ACOS-1[CorpB](config)#
ACOS-1(config)# active-partition CorpA
Current active partition: CorpA
ACOS-1[CorpA](config)# vrrp-a vrid 0
ACOS-1[CorpA](config-vrid:0)# floating-ip 20.20.20.2
ACOS-1[CorpA](config-vrid:0)# exit
ACOS-1[CorpA](config)#
ACOS-1(config)# active-partition CorpC
Current active partition: CorpC
ACOS-1[CorpC](config)# vrrp-a vrid 0
ACOS-1[CorpC](config-vrid:0)# floating-ip 40.40.40.2
ACOS-1[CorpC](config-vrid:0)# exit
ACOS-1[CorpC](config)#
Commands on ACOS-2
page 44
ACOS-2(config-common)# exit
ACOS-2# active-partition CorpA
Current active partition: CorpA
ACOS-2[CorpA]# config
ACOS-2[CorpA](config)# vrrp-a vrid 0
ACOS-2[CorpA](config-vrid:0)# floating-ip 20.20.20.2
ACOS-2[CorpA](config-vrid:0)# blade-parameters
ACOS-2[CorpA](config-vrid:0-blade-parameters)# priority 255
ACOS-2[CorpA](config-vrid:0-blade-parameters)# exit
ACOS-2[CorpA](config-vrid:0)# exit
ACOS-2[CorpA](config)# active-partition CorpC
Currently active partition: CorpC
ACOS-2[CorpC](config)# vrrp-a vrid 0
ACOS-2[CorpC](config-vrid:0)# floating-ip 40.40.40.2
ACOS-2[CorpC](config-vrid:0)# blade-parameters
ACOS-2[CorpC](config-vrid:0-blade-parameters)# priority 255
ACOS-2[CorpC](config-vrid:0-blade-parameters)# exit
ACOS-2[CorpC](config-vrid:0)# exit
ACOS-2[CorpC](config)# active-partition CorpB
Current active partition: CorpB
ACOS-1[CorpB](config)# vrrp-a vrid 0
ACOS-1[CorpB](config-vrid:0)# floating-ip 30.30.30.2
ACOS-1[CorpB](config-vrid:0)# exit
ACOS-1[CorpB](config)#
Configuration of Tracking Options

The following commands configure VRRP-A tracking options. For simplicity, commands for only a sin-
gle device are shown.
More information about these commands can be found in “VRRP-A VRID Configuration Commands” on
page 167.
Note: When finished configuring specific tracking options, use the exit or end CLI commands to return
to the global configuration mode.
Example of using the exit command to reach the global configuration mode:
ACOS(config-vrid:1-blade-parameters)# exit
ACOS(config-vrid:1)# exit
ACOS(config)#
page 45
Ethernet Interface Tracking

The following command configures tracking of Ethernet port 1. If the port’s link goes down, 100 is sub-
tracted from the VRID’s priority value.
ACOS(config)# vrrp-a vrid 1

ACOS(config-vrid:1)# blade-parameters
ACOS(config-vrid:1-blade-parameters)# tracking-options
ACOS(config-vrid:1-blade-parameters-track...)# interface ethernet 1 priority-cost 100
Trunk Tracking
The following commands configure the ACOS device to track the status of a trunk (but not ports within
the trunk). The VRRP-A protocol will reduce the priority of the device by 100 if the trunk goes down.

ACOS(config-vrid:1-blade-parameters-track...)# trunk 1 priority-cost 100
The following commands configure the ACOS device to track the status of a trunk, as well as the status
of ports within the trunk. If trunk 2 goes down, the priority of the associated VRID is reduced by 150. If a
port within the trunk goes down, the priority of the associated VRID is reduced by 40.

ACOS(config-vrid:2-blade-parameters-track...)# trunk 2 priority-cost 150 per-port-pri 40
VLAN Tracking
The following command configures tracking of VLAN 69. If the VLAN is quiet for more than 30 seconds,
50 is subtracted from the VRID priority.

ACOS(config-vrid:1-blade-parameters-track...)# vlan 69 timeout 30 priority-cost 50
For more information about enhanced VLAN tracking capabilities, see “Increased VLANs for VRRP-A
Failover Tracking” on page 48.
page 46
Gateway Tracking
The following commands configure tracking of gateway 10.10.10.1. If the gateway stops responding to
pings, 100 is subtracted from the VRID’s priority value.
ACOS(config)# health monitor gatewayhm1

ACOS(config-health:monitor)# method icmp
ACOS(config-health:monitor)# exit
ACOS(config)# slb server gateway1 10.10.10.1
ACOS(config-real server)# health-check gatewayhm1
ACOS(config-real server)# exit
ACOS(config-vrid:0-blade-parameters-track...)# gateway 10.10.10.1 priority-cost 100
Route Tracking
The following command configures tracking of routes to destination network 3000::/64. If the IPv6
route table does not contain any routes to the destination, 105 is subtracted from the VRID priority.

ACOS(config-vrid:0-blade-parameters-track...)# route 3000::/64 priority-cost 105
The following commands configure tracking of routes to destination network 5000::/64. If the IPv6
route table does not contain any routes to the destination, 80 is subtracted from the VRID priority.

ACOS(config-vrid:1-blade-parameters-track...)# route 5000::/64 priority-cost 80
Preemption Delay
The following commands configure the desired preemption delay value of 200 milliseconds:

ACOS(config-common)# preemption-delay 200
For more information about preemption delay, see “Preemption Delay” on page 17.
page 47
Increased VLANs for VRRP-A Failover Tracking

The VRRP-A failover tracking feature supports an increased number of VLANs. The weight (as
assigned using failover policy templates—for details refer to “VRRP-A Policy-Based Failover Template”
on page 55) or priority assigned to the VLAN tracked event will be used in calculations that will impact
VRRP-A failover decisions.
If VRRP-A stops detecting traffic on a VLAN, VRRP-A reduces the priority for the VRID. The priority
value to subtract can be specified individually for each VLAN.
To configure VLAN tracking use the following command:
vlan vlan-id timeout timeout-value priority-cost value
ACOS provides two ways to track VLANs for VRRP-A:
• Using the priority tracking option—The tracking option performs failover by decreasing a VRID's
priority value.
• Using failover policy templates—The failover policy template performs failover by decreasing a
VRID's weight value.
You can track a total of 64 different VLANs in three possible ways:
• Configure all 64 VLANs that can be tracked using tracking options.
• Configure all 64 VLANs that can be tracked using a single failover policy template or split over
multiple templates.
• Configure a mix of both options mentioned above. That is configure 32 VLANS using the tracking
option and configure the remaining 32 VLANs using a failover policy template.
NOTE: Tracking options and the failover policy template can track the same
VLANs. For example, you configure 64 VLANs using the tracking option.
You can also configure tracking of 64 of the same VLANs using a fail-
over-policy template. In essence, you are still only tracking 64 VLANs.
VLAN Tracking Configuration Example

After you have enabled VRRP-A on the devices, set the VRRP-A VRID, and then to set VLAN tracking-
options for 11 existing VLANs based on their priority cost:
vrrp-a vrid 31
blade-parameters
tracking-options
vlan 1000 timeout 30 priority-cost 1
page 48
Configuring a Leader and Follower VRID

The following example shows how 11 VLANs of differing timeout values and weights are being
tracked in a failover template called test.
!
vrrp-a fail-over-policy-template test
vlan 222 timeout 50 weight 100
!

Configuration Example 1
To configure a leader VRID, do the following:
1. In the shared partition, configure a vrid-lead:

ACOS(config) #vrrp-a vrid-lead lead1
ACOS(config-vrid-lead:lead1)# partition shared vrid 1
2. In the L3V partition, configure the VRID you wish to designate as the follower.
a. To do so, enter the partition:
ACOS# active-partition p1
page 49
b. In the currently active partition, p1, enter the following command:

ACOS[p1](config)# vrrp-a vrid 1
ACOS[p1](config-vrid:1)# follow vrid-lead lead1
c. Use the show vrrp-a command to view your configuration:

ACOS[p1](config-vrid-follow)# show vrrp-a
vrid 0
became Active at: May 20 12:04:05 2013
for 0 Day,22 Hour,54 min
2 (Peer) Standby 65534 150 *
vrid 1 (follow vrid-lead lead1)
2 (Peer) Standby 65534 150 *
vrid that is running: 0 1
3. By default, the default-vrid-lead exists in the shared partition:

vrrp-a vrid-lead default-vrid-lead
partition shared vrid 1
Configuration Example 2
To configure a leader in the shared partition, issue the following commands:
1. Define a VRID called myname as the leader:

ACOS(config)# vrrp-a vrid-lead myname
ACOS(config-vrid-lead:myname)# partition p1 vrid 0
2. Use the following show command to display your VRID leader configuration:
ACOS(config)# show vrrp-a vrid-lead
vrrp-a vrid-lead myname
partition p1 vrid 0
3. In the L3V partition, configure the VRID to follow the lead VRID:
ACOS[p1](config-vrid:3)# follow vrid-lead myname
page 50
Configuring VRRP-A VRID Lead Switching
4. Observe your configuration using the following command:

ACOS[p1](config)# show running-config | sec vrrp-a
vrrp-a vrid 0
follow vrid-lead default-vrid-lead
vrrp-a vrid 3
follow vrid-lead myname
5. As the Admin, if you want to change the VRID’s role from being a follower to standalone VRID
again, issue the following command:
Change the role of vrid 3 from follower to standalone? (y/n)y
Again, to view your configuration, use the show run command:
ACOS[p1](config)# show running-config
!
vrrp-a vrid 3
!
If you try to remove a VRID that is configured as a lead VRID and that has other VRIDs that follow it, you
will not be allowed to remove it. You must remove the VRIDs that are configured as followers before
you remove the lead VRID.

This section describes how to switch lead VRIDs in a VRRP-A configuration without affecting traffic
when doing so.
The example in this section utilizes the topology shown in Figure 12:
page 51
FIGURE 12 VRRP-A VRID Lead Switching Example Topology
Suppose you want to change the default VRID (VRID 0) on partition p1 to follow ACOS2. Using the
vrrp-a vrid 0 follow vrid-lead-ACOS2 command could accomplish this, however there may be a dis-
ruption of the traffic on partition p1’s VRID because of the time interval required for manual configura-
tion on both sides.During this time interval, the VRID 0 could be double active or double standby on
both devices.
This section provides alternative solutions that do not affect traffic:
• “Manual VRID Lead Switching Using Manual Configuration” on page 52
• “Automatic VRID Lead Switching Using aVCS” on page 53
Manual VRID Lead Switching Using Manual Configuration

To manually configure VRID lead switching without affecting traffic:
1. Use either an existing VRID whose up or down status is the same as the VRID you are configuring,
or create a new VRID. In the steps below, the example is creating a new VRID called vrid 5. The fol-
lowing shows ACOS1, do the same on ACOS2.
ACOS1-Active(config)# vrrp-a vrid 5
[yes/no]: yes
page 52
VRRP-A Status in CLI Prompt
2. Ensure that the new VRID’s active device is the same as the current VRID (in this example, the
active device is ACOS1). You can accomplish this by manually setting the dynamic priority of the
new VRID on ACOS2 to a lower number than on ACOS1, or by using the vrrp-a force-self-
standby vrid vrid# command for the new VRID on ACOS2.
ACOS2(config)# vrrp-a force-self-standby vrid 5 enable
3. Create the VRID lead that you will use in the next step.
ACOS1-Active(config)# vrrp-a vrid-lead lead1
ACOS1-Active((config-vrid-lead:lead1)# partition shared vrid 5
4. In partition p1 on both devices, use the follow vrid-lead vrid_lead_template command to make
the traffic in the partition follow the new VRID. Since the new VRID has the same VRRP-A status as
the existing lead VRID, traffic is not impacted during this step. The following shows ACOS1, do the
same on ACOS-2.
ACOS1(config)# active-partition p1
Current active partition: p1
ACOS1-Active[p1](config)#vrrp-a vrid 0
ACOS1-Active[p1](config-vrid:5)#follow vrid-lead lead1
ACOS1-Active[p1](config-vrid:5)#exit
5. Change the dynamic priority of the new VRID on ACOS1, or the vrrp-a force-self-standby vrid
vrid# disable command for the new VRID on ACOS2, thus causing the new VRID to become
active on ACOS2. This switch is done by message negotiation among peer devices, so no traffic is
lost in this step.
ACOS2(config)# vrrp-a force-self-standby vrid 5 disable
Automatic VRID Lead Switching Using aVCS

aVCS uses an almost-real-time config sync across devices in the same virtual cluster. This means
when the VRID lead is switched the configurations on both devices are updated almost simultaneously
so that traffic is preserved.

The CLI prompt can be customized to identify the devices that are running VRRP-A configuration.
For information about how to do this, see “VRRP-A/aVCS Status in Command Prompt” in the Command
Line Interface Reference.
page 53
page 54
VRRP-A Policy-Based Failover Template
VRRP-A provides flexible event tracking and policy-based failover support via a template. This feature
allows policy-based failover even when VRRP-A preemption is disabled and the ACOS device typically
would remain in an Active state, despite VRID priority changes. It allows for event-based failover once a
tracked event occurs.
The following topics are covered in this chapter:
• Template Rules and Partitions
• Preemption and Levels
• Precedence Causing a Failover
• Events Tracked for Weight via the Templates
• Configuring VRRP-A Policy-Based Failovers
Template Rules and Partitions

• Policy-Based Failover Template Rules for the Shared Partition
• Policy-Based Failover Template Rules for L3V Partitions
Policy-Based Failover Template Rules for the Shared Partition

When creating templates in the shared partition, adhere to the following rules:
• You may create multiple templates, however only one template can be associated with a particu-
lar VRID. For example, if you create two templates called “template1” and “template2,” you can
only associate either template1 or template2 with VRID1. Assuming template1 and template2
have different events configured and you want template1 (that tracks for VLANs and gateways)
to also address the events that template2 tracks (for interfaces and routes), edit template1 to
include the events covered by template2. You cannot associate both templates to VRID1 to have
it track all four events (VLANs, gateways, interfaces, and routes).
page 55
Preemption and Levels
• Create templates with unique names, however, the second time you try to create a template with
the same name, you will enter the template module and can edit the events listed in the template.
• You can create a maximum of 32 templates in the shared partition.
• You can associate the same template to multiple VRIDs. For example, VRID1 and VRID23 can
both be attached to template1.
Policy-Based Failover Template Rules for L3V Partitions

When creating policy-based failover templates in an L3V partition, adhere to the following rules:
• You may create multiple templates, however only one template can be associated with a particu-
lar VRID. For example, if you create two templates called “template1” and “template2,” you can
only associate either template1 or template2 with VRID1. Assuming template1 and template2
have different events configured and you want template1 (that tracks for VLANs and gateways)
to also address the events that template2 tracks (for interfaces and routes), edit template1 to
include the events covered by template2. You cannot associate both templates to VRID1 to have
it track all four events (VLANs, gateways, interfaces, and routes).
• Create templates with unique names, however, the second time you try to create a template with
the same name, you will enter the template module and can edit the events listed in the template.
• To associate a template to a private partition, you must switch to an active-partition.
• Since each private partition can have its own template, and templates cannot be shared across
multiple partitions, template names do not need to be unique. For example, template1 can be the
template for private partition1 and template1 can be the template for private partition2. They can
be named the same, but can track different events for different VRIDs.
• You can create a maximum of 32 templates in the private partition.
Preemption and Levels

Preemption is always enabled on Level 1 (weight) and can be configured to be as enabled or disabled in
Level 2 (priority). With preemption always being enabled on Level 1, the higher weight of an ACOS
device will always place it in Active state and the remaining ACOS devices in Standby state. Level 1
weight assignments for events will result in the deduction of that weight from the VRID when an event
occurs. When the weight is reduced for a particular VRID, it may result in a failover to another device if
its total weight is lower than that of its peer devices. Since preemption works at the VRID level, any
VRID with a higher weight can take over for another VRID in a different ACOS device of a lower weight.
When the original Active device is operational again, its weight is subject to change, and if it has the
highest weight amongst its peers, it will resume its role and take over as the Active device.
page 56
Precedence Causing a Failover

The VRRP-A policy failover template provides a flexible way of defining events that will trigger failover
of an ACOS device from Active to Standby state or vice versa. The following briefly summarizes the
order in which VRRP-A failover is determined:
• When the ACOS devices in a VRRP-A configuration have unequal weight, the one with the higher
weight will be the Active device. Refer to Higher Weight Scenario“Higher Weight Scenario” on
page 57.
• If all ACOS devices have equal weight, the ACOS device with the higher priority will be the Active
device. Refer to Higher Priority Scenario“Higher Priority Scenario” on page 58.
• If the two ACOS devices have equal weight and equal priority, the device with the lower Device ID
will be the Active device. Refer to “Equal Weight and Priority Scenario” on page 59.
Higher Weight Scenario

Use the show vrrp-a command to view the Active/Standby status of the ACOS devices: Note that Unit 1
is the Active device and its weight is “65534” for VRID1:
AOCS(config)# show vrrp-a

vrid 0
2 (Local) Standby 65534 150 *
became Standby at: May 20 12:10:05 2013
vrid 1
After an event results in a reduction of the weight, Unit 1 now has a weight of “65334” for VRID1, and a
failover was triggered that placed Unit 1 in a Standby state:
ACOS(config)# show vrrp-a

vrid 0
page 57
vrid 1
2 (Local) Active 65534 150 *
Higher Priority Scenario

Use the show vrrp-a command to view the Active/Standby status of the ACOS devices: Note for VRID1
that Unit 1 is the Active device and its priority is “200:”

vrid 0
vrid 1 became Standby at: May 20 12:10:05 2013

After an event results in a reduction of the priority, Unit 1 now has a priority of “1” for VRID1, and a
failover was triggered that placed Unit 1 in a Standby state:

vrid 0
vrid 1
1 (Peer) Standby 65534 1 *
page 58
Equal Weight and Priority Scenario

Use the show vrrp-a command to view the Active/Standby status of the ACOS devices: Note that
VRID1 has an unequal weight of “65534” and an equal priority of “150:”

vrid 0
vrid 1
1 (Peer) Standby 65334 150 *
After an event results in an increase in weight, Unit 1 and Unit 2 both have an equal weight and priority,
yet a failover is triggered based on the device ID. For VRID1, Unit 1 is lower than Unit 2, it is now is in
Active state instead of the Standby state:

vrid 0
vrid 1
page 59
Events Tracked for Weight via the Templates

Several events can be tracked for weight or priority. However, the failover policy templates only allow
you to specify the weight for each event, not the priority. If configured using the GUI or the CLI, the fol-
lowing events may cause a change in the VRID and result in an ACOS device failover:
TABLE 2 Configurable Event Tracking

Event Description
Lost link a default gate- VRRP-A periodically tests connectivity to the IPv4 and IPv6 default gateways
way. connection to a real server by pinging them. If a gateway stops responding,
VRRP-A reduces the weight or priority for the VRID. The weight value to subtract
can be specified individually for each gateway’s IP address that you configure in
the tracking events list.
VLAN inactivity. If VRRP-A stops detecting traffic on a VLAN, VRRP-A reduces the device’s priority
for the VRID. The priority value to subtract can be specified individually for each
VLAN.
VLAN tracking is only supported in the shared partition.

Lost link on a trunk. If the trunk or individual ports in the trunk go down, VRRP-A reduces the device’s
priority for the VRID. The priority value to subtract can be specified for the trunk
and for individual ports within the trunk.
If you track a trunk that does not exist, VRRP-A will not reduce the device priority.
To track a trunk port within an L3V partition, you must verify that the tracked port
is actually being used within that partition (for example, verify that the port is
used in a VLAN of the partition):
• If the tracked trunk is down, VRRP-A reduces the device priority based on the
trunk value and ignores the status of the ports within the trunk.
• If the tracked trunk is up, VRRP-A checks the ports within the trunk, and if any
of them are down, VRRP-A reduces the device priority (1x configured port prior-
ity). If two ports are down, VRRP-A reduces the device priority by twice the pri-
ority assigned to the ports within the trunk (2x configured port priority).
Lost data route. If an IPv4 or IPv6 route matching the specified options is not in the data route
table, VRRP-A reduces the device’s priority for the VRID.
Lost link on an Ethernet If the link goes down on an Ethernet data port, VRRP-A reduces the device’s pri-
port ority for the VRID. The priority value to subtract can be specified individually for
each Ethernet data port.
If a tracked interface is a member of a trunk, only the lead port in the trunk is
shown in the tracking configuration and in statistics. For example, if a trunk con-
tains ports 1-3 and you configure tracking of port 3, the configuration will show
that tracking is enabled on port 1. Likewise, tracking statistics will show port 1,
not port 3. Similarly, if port 1 goes down but port 3 is still up, statistics still will
show that port 1 is up since it is the lead port for the trunk.
page 60
The following graphic visually represents where tracking can be enabled for an ACOS device:
page 61
Configuring VRRP-A Policy-Based Failovers

This section contains the following topics:
• “Using the GUI to Configure VRRP-A Policy-Based Failovers” on page 62
• “Using the CLI to Create VRRP-A Policy-Based Failovers” on page 63
NOTE: For details on additional template rules, refer to “Template Rules and
Partitions” on page 55.
Using the GUI to Configure VRRP-A Policy-Based Failovers

To configure the policy-based failover feature using the GUI, follow these steps:
1. Go to System > VRRP-A > Failover Policy Template to view the Failover Policy Template
page.
2. Click Create to view the Create Failover Policy Template page.
3. Specify a template name in the Template Name field.
4. Configure the remainder of the page as needed.
For a description of the different events, see “Events Tracked for Weight via the Templates” on
page 60.
page 62
When an event occurs, the specified weight will be subtracted from the weight of the VRID, possi-
bly causing a failover.
For more information about this screen, refer to the online help.
5. Click Create when you are finished.
Your failover template will be listed in the Failover Policy Template page.
Using the CLI to Create VRRP-A Policy-Based Failovers

Failover Policy Templates can be configured using the CLI in either the shared or the private partition.
Configuring Templates in the Shared Partition

To configure the policy-based failover feature in the shared partition using the CLI, follow these steps:
1. Create your failover policy template. For example., create a template with the name template1:
ACOS(config)# vrrp-a fail-over-policy-template template1
ACOS(config-fail-over-policy-template:tem...)#
2. Configure the events you wish to track:

a. For gateway tracking, indicate the gateway IP address and assign a weight for the gateway in
the event of a failure. For example, if gateway 10.10.10.1 fails, 50 will be subtracted from the
weight of the VRID:
page 63
ACOS(config-fail-over-policy-template:tem...)# gateway 10.10.10.1 weight 50
b. For interface tracking, indicate the interface type, interface number, and assign a weight for that
interface in the event of a failure. For example, if Ethernet interface 1 fails, 35 will be subtracted
from the weight of the VRID:
ACOS(config-fail-over-policy-template:tem...)# interface ethernet 1 weight 35
c. For route tracking, indicate the route number and assign a weight for that route in the event of
failure. For example, if route 20.20.20.0 /24 fails, 70 will be subtracted from the weight of the
VRID:
ACOS(config-fail-over-policy-template:tem...)# route 20.20.20.0 /24 weight 70
d. For trunk tracking, indicate the trunk identification number and assign a weight for that trunk in
the event of failure. For example, if trunk 4 fails, 25 will be subtracted from the weight of the
VRID:
ACOS(config-fail-over-policy-template:tem...)# trunk 4 weight 25
e. For VLAN tracking, indicate the VLAN identification number, the timeout value, and assign a
weight for that trunk in the event of failure. For example, if VLAN 6 fails, 40 will be subtracted
from the weight of the VRID:
ACOS(config-fail-over-policy-template:tem...)# vlan 6 timeout 30 weight 40
3. Assign a failover template to a VRID from the Global configuration level. For example, to assign
template1 to VRID 0:
ACOS(config-vrid:0-blade-parameters)# fail-over-policy-template template1
NOTE: Only one template can be assigned to a VRID in any partition.
Configuring Templates in L3V Partition

To configure the policy-based failover feature in an L3V partition, follow these steps:
1. Switch to the active partition (for example, companyA):

ACOS(config)# active-partition companyA id 3
2. Follow the instructions in “Configuring Templates in the Shared Partition” on page 63.
page 64
Verifying the Fail-Over Policy Template Configuration

To view the reason for a failover, the show vrrp-a command on the Active ACOS device will display the
template event that has caused the failover:

vrid 0
2 (Peer) Standby 65534 150 *
vrid 1
Detected local policy based fail over events:
interface ethernet 1 weight 200
If you specify the name of the template, the show vrrp-a fail-over-policy-template command will display
the contents of that template:
ACOS(config)# show vrrp-a fail-over-policy-template template1

vrrp-a fail-over-policy-template template1
gateway 10.10.10.1 weight 50
trunk 4 weight 25
route 20.20.20.0 255.255.255.0 weight 70
Use the show vrrp-a command with the detail option to display comprehensive information on your
current VRRP-A configuration:
ACOS(config)# show vrrp-a detail

vrid 0
...
VRRP-A stats
page 65
Peer: 1, vrid 0
Port 1: received 25685 missed 3
...
Total packets sent for vrid 0: 58524

Sent from port 1: 29262
...
Peer IP[1]: 7.7.7.1
To view information on all the fail-over policy templates, you can use the show vrrp-a fail-over-pol-
icy-template command;
ACOS(config)# show vrrp-a fail-over-policy-template

vrrp-a fail-over-policy-template interface
vrrp-a fail-over-policy-template trunk
trunk 1 weight 1 per-port-weight 20
vrrp-a fail-over-policy-template gateway
vrrp-a fail-over-policy-template route
route 4.4.4.0 255.255.255.0 weight 200
vrrp-a fail-over-policy-template vlan
trunk 4 weight 25
route 20.20.20.0 255.255.255.0 weight 70
page 66
Overview
High Availability
This chapter describes High Availability (HA) and how to configure it.
NOTE: The version of HA described in this chapter is the version that is also
supported in previous releases.
NOTE: The implementation of HA described in this chapter is not supported

with Layer 2/3 virtualization. To use redundancy with Layer 2/3 virtual-
ization, use VRRP-A.
NOTE: If you use source NAT, only half the protocol ports on each NAT IP
address are available at a given time. This is because the ACOS device
allocates half the ports to one of the ACOS devices in the HA pair and the
other half to the other ACOS device. This does not occur with VRRP-A. If
you use VRRP-A, all the protocol ports on NAT addresses are available.
NOTE: Beginning in AX Release 2.7.0, heartbeat messages in Layer 2 Inline

mode deployments are sent in unicast packets with the unicast MAC
address and unicast IP address of the peer ACOS device in the HA pair.
They no longer are sent in IP multicast packets addressed to IP multicast
destination MAC and IP addresses. Like previous releases, they also are
not sent as broadcasts.
NOTE: This applies to all ACOS device models. This change does not require any
configuration changes and should not affect the operation of your HA
deployment.
Overview
High Availability (HA) is an ACOS feature that provides ACOS-level redundancy to ensure continuity of
service to clients. In HA configurations, ACOS devices are deployed in pairs. If one ACOS device in the
HA pair becomes unavailable, the other ACOS device takes over.
You can configure either of the following types of HA:
• Active-Standby – One ACOS device is the primary SLB device for all virtual services on which HA
is enabled. The other ACOS device is a hot Standby for the virtual services.
page 67
Overview
• Active-Active – Each ACOS device is the primary SLB device for some of the configured virtual
services, and is a hot Standby for the other configured virtual services.
Active-Active is supported only on ACOS devices that are deployed in route mode. Active-Standby is
supported on ACOS devices deployed in transparent mode or route mode.
NOTE: In High Availability (HA) deployments, the ACOS devices must be the
same model and must be running the same software version. For exam-
ple, if one of the ACOS devices in an HA deployment is model AX 3200-11
running 2.6.1, the other device also must be model AX 3200-11 running
2.6.1. The other device in this example can not be AX 3200 or any other
model except AX 3200-11.
page 68
Overview
Layer 3 Active-Standby HA
Figure 13 shows an example of an Active-Standby configuration.
FIGURE 13 Active-Standby HA
page 69
Overview
In this example, each ACOS device provides SLB for two virtual servers, VIP1 and VIP2.
Each ACOS device has the following HA configuration elements:
• HA ID – The HA ID of AX1 is 1 and the HA ID of AX2 is 2. Each ACOS device in an HA deployment

must have a unique HA ID. The ID must be different on each ACOS device. The ID can be used as
a tie breaker to select the Active ACOS device. (See “How the Active ACOS Device Is Selected” on
page 86.)
• HA group – HA group 1 is configured on each ACOS device. An ACOS device can have up to 31
HA groups.
Both VIPs on each ACOS device are members of the HA group.
Each HA group must be configured with a priority. The priority can be used as a tie breaker to
select the Active ACOS device for a VIP.
Each HA group has a shared MAC address, 021f.a0000.00xx. The 02 portion of the address indi-
cates this is an HA virtual MAC address, instead of a system MAC address (00). The xx portion of
the address is unique to the HA group. The shared MAC address is used for all IP addresses for
which HA is provided (SLB VIPs, source NAT addresses, floating IP addresses, and so on).
• Session synchronization – Also called connection mirroring, session synchronization sends
information about active client sessions to the Standby ACOS device. If a failover occurs, the cli-
ent sessions are maintained without interruption.
(For a complete list of configurable HA parameters, see “HA Configuration Parameters” on page 90.)
Maximum Number of Supported HA Floating IP Addresses
• For all FPGA models: 256 floating IPs
• For non-FPGA models: 64 floating IPs
• For private partitions enabled for Layer 2/3 virtualization (both FPGA and non-FPGA models): 64
floating IPs
page 70
Overview
Layer 3 Active-Active HA
Figure 14 shows an example of an Active-Active configuration.
FIGURE 14 Active-Active HA
In the Active-Active configuration, as in the Active-standby configuration. only one ACOS device is
active for a given VIP. But unlike the Active-Standby configuration, the same ACOS device does not
need to be the Active ACOS device for all the VIPs. Instead, each of the ACOS devices can be the Active
ACOS device for some VIPs. In this example, AX1 is Active for VIP2 and AX2 is Active for VIP1.
This configuration is similar to the configuration for Active-Standby shown in Figure 13, with the follow-
ing exceptions:
page 71
Overview
• Both HA groups are configured on each of the ACOS devices. In Active-Standby, only a single HA
group is configured.
• The priority values have been set so that each HA group has a higher priority on one ACOS device
than it does on the other ACOS device. In this example, HA group 1 has a higher priority on AX2,
whereas HA group 2 has a higher priority on AX1.
• On each ACOS device, one of the VIPs is assigned to HA group 1 and the other VIP is assigned to
HA group 2.
• On both ACOS devices, HA pre-emption is enabled. HA pre-emption enables the devices to use
the HA group priority values to select the Active and Standby ACOS device for each VIP. Without
HA pre-emption, the device selection is based on which of the ACOS devices comes up first.
page 72
Overview
Layer 2 Active-Standby HA (Inline Deployment)

ACOS devices support Layer 2 hot standby inline deployment. Inline deployment allows you to insert a
pair of ACOS devices into an existing network without the need to reconfigure other devices in the net-
work.
Inline support applies specifically to network topologies where inserting a pair of ACOS switches would
cause a Layer 2 loop, as shown in this example.
FIGURE 15 Topology Supported for Layer 2 Inline HA Deployment
In this example, a pair of routers configured as a redundant pair route traffic between clients and serv-
ers. The redundant router pair can be implemented using Virtual Router Redundancy Protocol (VRRP-
A), Extreme Standby Router Protocol (ESRP), or another equivalent router redundancy protocol.
Each real server is connected to the router pair through a Layer 2 switch. Neither the Layer 2 switches
nor the routers are running Spanning Tree Protocol (STP). The network does not have any Layer 2 loops
page 73
Overview
because the Layer 2 switches are not connected directly together, and the routers do not forward Layer
2 traffic.
If a pair of ACOS switches in transparent mode are added, the ACOS switches can add redundant Layer
2 paths, which cause Layer 2 loops. To prevent loops in this deployment, without making any configu-
ration changes on the other devices in the network, you can enable HA inline mode on the ACOS
devices. Inline mode automatically blocks redundant paths through the Standby ACOS device, without
the need to enable STP on any devices.
FIGURE 16 Layer 2 Inline HA Deployment
Mandatory Connection-mirror IP Requirement for Layer 2 Inline Mode HA
ACOS devices require a connection mirror IP address to be configured in Layer 2 inline mode HA
deployments. A connection mirror interface is a unicast IP address on the peer ACOS device in the HA
pair. This peer IP address is optional in earlier releases but usually is configured anyway for session
synchronization purposes. Beginning in AX Release 2.7.0, specifying a connection mirror IP address is
mandatory for proper operation of ACOS devices in Layer 2 Inline mode HA.
page 74
Overview
The connection mirror IP address is used for session synchronization (also called “connection mirror-
ing”). Until a connection mirror IP address is specified, the ACOS device remains in Standby state.
If a connection mirror IP address is not configured, a log message such as the following is generated
every 5 minutes:
Sep 01 2012 03:01:30 Warning [HA]:HA Peer IP is not configured. Peer IP is required in
Inline Mode.
Restrictions
• Supported for Active-Standby HA deployments only. Not supported for Active-Active HA.
• Inline mode is designed for one HA group in Hot-Standby mode. Do not configure more than one
HA group on a device running in inline mode.
• In order to prevent Layer 2 loops in a Layer 2 host-standby environment, the Standby ACOS
device does not forward traffic. In addition, the Active ACOS device in the HA pair is designed to
not forward packets destined for the Standby ACOS device. Depending on the network topology,
certain traffic to the Standby ACOS device might be dropped if it must first pass through the
Active ACOS device.
Preferred HA Port
When you enable inline mode on an ACOS device, the ACOS device uses a preferred HA port for session
synchronization and for management traffic between the ACOS devices in the HA pair. For example, if
you use the CLI on one ACOS device to ping the other ACOS device, the ping packets are sent only on
the preferred HA port. Likewise, the other ACOS device sends the ping reply only on its preferred HA
port.
Management traffic between ACOS devices includes any of the following types of traffic:
• Telnet
• SSH
• Ping
Optionally, you can designate the preferred HA port when you enable inline mode. In Figure 16 on
page 74, Ethernet interface 5 on each ACOS device has been configured as the preferred HA port.
The ACOS device selects the Active ACOS device’s preferred HA port as follows:
1. Is a preferred port specified with the inline configuration, and is the port up? If so, use the port.
2. If no preferred HA port is specified in the configuration or that port is down, the first HA interface
that comes up on the ACOS device is used as the preferred HA port.
page 75
Overview
3. If the preferred HA port selected by 1. or 2. above goes down, the HA interface with the lowest port
number is used. If that port also goes down, the HA interface with the next-lowest port number is
used, and so on.
HA heartbeat messages are not restricted to the preferred HA port. Heartbeat messages are sent out
all HA interfaces unless you disable the messages on specific interfaces.
NOTE: The preferred port must be added as an HA interface and heartbeat mes-
sages must be enabled on the interface.
Port Restart
When a transition from Standby to Active occurs because the formerly Active ACOS device becomes
unavailable, the other devices that are directly connected to the unavailable ACOS device detect that
their links to the ACOS device have gone down. The devices then flush their cached MAC entries on the
down links.
For example, in Figure 16 on page 74, while AX1 is still Active, the active router (the one on the left)
uses the MAC entries it has learned on its link with AX1 to reach downstream devices. If the link with
AX1 goes down, the router flushes the MAC entries. The router then relearns the MAC addresses on the
link with AX2 when it becomes the Active ACOS device.
This mechanism is applicable when the link with AX1 goes down. However, if the transition from Active
to Standby does not involve failure of the router's link with AX1, the router does not flush its learned
MAC entries on the link. As a result, the router might continue to send traffic for downstream devices
through the router's link with AX1. Since AX1 is now the Standby, it drops the traffic, thereby causing
reachability issues.
For example, if you administratively force a failover by changing the HA configurations of the ACOS
devices and enabling HA pre-emption, the link between the router and AX1 remains up. In this case, the
router continues to have MAC addresses through this link.
To ensure that devices connected to the formerly Active ACOS device flush their learned MAC entries
on their links with AX1, you can enable HA port restart.
HA port restart toggles a specified set of ports on the formerly Active ACOS device by disabling the
ports, waiting for a specified number of milliseconds, then re-enabling the ports. Toggling the ports
causes the links to go down, which in turn causes the devices on the other ends of the links to flush
their learned MAC entries on the links. The devices then can relearn MACs through links with the newly
Active ACOS device.
NOTE: You must omit at least one port connecting the ACOS devices from the
restart port-list. This is so that heartbeat messages between the ACOS
devices are maintained; otherwise, flapping might occur.
page 76
Overview
NOTE: On model AX 2000 or AX 2100, A10 recommends that you do not include
Fiber ports in the restart port list.
Layer 3 Active-Standby HA (Inline Deployment)

Inline mode HA is also supported for ACOS devices deployed in route mode (Layer 3).
Layer 3 HA for inline mode is beneficial in network topologies where the ACOS device interfaces with
the clients and real servers are in the same subnet. Figure 17 shows an example.
FIGURE 17 Inline Mode for Layer 3 HA
In this example, each ACOS device has multiple Ethernet ports connected to the clients, and multiple
Ethernet ports connected to the servers. On each ACOS device, all these Ethernet interfaces are config-
ured as a single Virtual Ethernet (VE) interface with a single IP address. The routers, both ACOS
devices, and the servers are all in the same subnet.
page 77
Overview
Normally, this topology would introduce a traffic loop. However, the HA inline mode prevents loops by
logically blocking through traffic on the standby ACOS device. Spanning Tree Protocol (STP) is not
required in order to prevent loops.
A dedicated link between the ACOS devices is used for HA management traffic. In this example, the
dedicated link is in another subnet.
Comparison to Layer 2 Inline Mode
Layer 3 inline configuration is similar to Layer 2 inline mode configuration, with the following excep-
tions:
• Layer 3 inline mode does not require designation of a preferred port or configuration of port
restart.
• CPU processing must be enabled on the Ethernet interfaces that will receive server replies to cli-
ent requests. CPU processing is required on these interfaces in order to change the source IP
address from the server’s real IP address back into the VIP address.
Restrictions
• Supported for Active-Standby HA deployments only. Not supported for Active-Active HA.
• Inline mode is designed for one HA group in Hot-Standby mode. Do not configure more than one
HA group on an ACOS device running in inline mode.
• In order to prevent Layer 2 loops in a Layer 2 host-standby environment, the Standby ACOS
device does not forward traffic. In addition, the Active ACOS device in the HA pair is designed to
not forward packets destined for the Standby ACOS device. Depending on the network topology,
certain traffic to the Standby ACOS device might be dropped if it must first pass through the
Active ACOS device.
HA Messages
The ACOS devices in an HA pair communicate their HA status with the following types of messages:
• HA heartbeat messages
• Gratuitous ARP requests and replies
HA Heartbeat Messages
Each of the ACOS devices regularly sends HA heartbeat messages out its HA interfaces. The Standby
ACOS device listens for the heartbeat messages. If the Standby ACOS device stops receiving heartbeat
messages from the Active ACOS device, the Standby ACOS device transitions to Active and takes over
networking and SLB operations from the other ACOS device.
page 78
Overview
By default, heartbeat messages are sent every 200 milliseconds. If the Standby ACOS device does not
receive a heartbeat message for 1 second (5 times the heartbeat interval), the Standby ACOS device
transitions to Active.
The heartbeat interval and retry count are configurable. (See “HA Configuration Parameters” on
page 90.)
If the heartbeat messages from one ACOS device to the other will pass through a Layer 2 switch, the
switch must be able to pass UDP IP multicast packets. (This requirement does not apply to Layer 2
inline HA because it uses unicast to transmit the heartbeat.)
Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6)

For IPv4, when an ACOS device transitions from Standby to Active, the newly Active ACOS device sends
gratuitous ARP requests and replies (ARPs) for the IPv4 address under HA control.
Similarly, for IPv6, when an ACOS device transitions from Standby to Active, the newly Active ACOS
device sends ICMPv6 neighbor advertisement for the IPv6 address under HA control.
Gratuitous ARPs or ICMPv6 neighbor advertisements are sent for the following types of addresses:
• Virtual server IP addresses, for the VIPs that are assigned to an HA group.
• Floating IP address, if configured
• NAT pool IP addresses, for NAT pools assigned to an HA group
Devices that receive the ARPs or ICMPv6 neighbor advertisements learn that the MAC address for the
HA pair has moved, and update their forwarding tables accordingly.
The Active ACOS device sends the gratuitous ARPs or ICMPv6 neighbor advertisements immediately
upon becoming the Active ACOS device. To make sure ARPs or ICMPv6 neighbor advertisements are
being received by the target addresses, the ACOS device re-sends them 4 additional times, at 500-milli-
second intervals.
After this, the ACOS device sends gratuitous ARPs or ICMPv6 neighbor advertisements every 30 sec-
onds to keep its IP information current.
The retry count is configurable. (See “HA Configuration Parameters” on page 90.)
HA Interfaces
When configuring HA, you specify each of the interfaces that are HA interfaces. An HA interface is an
interface that is connected to an upstream router, a real server, or the other ACOS device in the HA pair.
HA heartbeat messages can be sent only on HA interfaces. Optionally, you can disable the messages
on individual interfaces. When you configure an HA interface that is a tagged member of one or more
VLANs, you must specify the VLAN on which to send the heartbeat messages.
page 79
Overview
Changes to the state of an HA interface can trigger a failover. By default, the HA state of an interface
can be Up or Down. Optionally, you can specify the HA interface type as one of the following:
• Server interface – A real server can be reached through the interface.
• Router interface – An upstream router (and ultimately, clients) can be reached through the inter-
face.
• Both – Both a server and upstream router can be reached through the interface.
If you specify the HA interface type, the HA status of the ACOS device is based on the status of the link
with the real server and/or upstream router. The HA status can be one of the following:
• Up – All configured HA router and server interfaces are up.
• Partially Up – Some HA router or server interfaces are down but at least one server link and one
router link are up.
• Down – All router interfaces, or all server interfaces, or both are down. The status also is Down if
both router interfaces and server interfaces are not configured and an HA interface goes down.
If both types of interfaces (router interfaces and server interfaces) are configured, the HA interfaces for
which a type has not been configured are not included in the HA interface status determination.
During selection of the active ACOS device, the ACOS device with the highest state becomes the active
ACOS device and all HA interfaces on that ACOS device become active. For example, if one ACOS
device is UP and the other ACOS device is only Partially Up, the ACOS device that is UP becomes the
active ACOS device.
If each ACOS device has the same state, the active ACOS device is selected as follows:
• If HA pre-emption is disabled (the default), the first ACOS device to come up is the active ACOS
device.
• If HA pre-emption is enabled, the ACOS device with the higher HA group priority becomes active
for that group. If the group priorities on the two ACOS devices are also the same, the ACOS device
that has the lowest HA ID (1 or 2) becomes active.
NOTE: You can configure up to 31 HA groups on an ACOS device, and assign a

separate HA priority to each. For Active-Standby configurations, use only
one group ID. For Active-Active configurations, use multiple groups IDs
and assign VIPs to different groups.
Notes
• The maximum number of HA interfaces you can configure is the same as the number of Ethernet
data ports on the ACOS device.
page 80
Overview
• If the heartbeat messages from one ACOS device to the other will pass through a Layer 2 switch,
the switch must be able to pass UDP IP multicast packets. (This requirement does not apply to
Layer 2 inline HA because it uses unicast to transmit the heartbeat.)
• If a tracked interface is a member of a trunk, only the lead port in the trunk is shown in the track-
ing configuration and in statistics. For example, if a trunk contains ports 1-3 and you configure
tracking of port 3, the configuration will show that tracking is enabled on port 1. Likewise, track-
ing statistics will show port 1, not port 3. Similarly, if port 1 goes down but port 3 is still up, statis-
tics still will show that port 1 is up since it is the lead port for the trunk.
• In non-Layer 2 inline deployments, if the heartbeat messages from one ACOS device to the other
will pass though a Layer 2 switch, the switch must be able to pass UDP IP multicast packets.
Layer 2 inline mode does not have this requirement.
VLAN ID Requirement
Beginning in AX Release 2.7.0, in deployments that use the older implementation of High Availability
(HA), if an HA interface is a tagged member of one or more VLANs, it is required to specify one of the
member VLAN IDs when configuring the interface to be an HA interface.
If the VLAN ID is not specified, the ACOS device does not transmit any heartbeat packets on the inter-
face. This is an invalid configuration. Previous releases incorrectly allowed the invalid configuration but
current releases do not.
For example, the following command is valid, if Ethernet port 5 is a tagged interface:
ha interface ethernet 5 vlan 2
The following command is invalid:
ha interface ethernet 5
If you are upgrading a device whose configuration has an invalid command such as the one shown
above, you will need to re-enter the command with valid syntax after the upgrade.
NOTE: If you do not want heartbeat messages to be sent on a tagged interface,

you still can use the no-heartbeat option. For example:
ha interface ethernet 5 no-heartbeat
Session Synchronization
HA session synchronization sends information about active client sessions to the Standby ACOS
device. If a failover occurs, the client sessions are maintained without interruption. Session synchroni-
zation is optional. Without it, a failover causes client sessions to be terminated. Session synchroniza-
tion can be enabled on individual virtual ports.
page 81
Overview
Session synchronization applies primarily to Layer 4 sessions. Session synchronization does not apply
to DNS sessions. Since these sessions are typically very short lived, there is no benefit to synchronizing
them. Likewise, session synchronization does not apply to NATted ICMP sessions or to any static NAT
sessions. Synchronization of these sessions is not needed since the newly Active ACOS device will cre-
ate a new flow for the session following failover.
To enable session synchronization, see “Enabling Session Synchronization” on page 128.
Session synchronization is required for config sync. Config sync uses the session synchronization link.
(For more information, “Manually Synchronizing Configuration Information” on page 131.)
NOTE: Session synchronization is also called “connection mirroring”.
Optional Failover Triggers

In addition to HA interface-based failover, you can configure failover based one any of the following:
• Inactive VLAN (VLAN-based failover)
• Unresponsive gateway router (gateway-based failover)
• Unresponsive real servers (VIP-based failover)
VLAN-based Failover
You can enable HA checking for individual VLANs. When HA checking is enabled for a VLAN, the active
ACOS device in the HA pair monitors traffic activity on the VLAN. If there is no traffic on the VLAN for
half the duration of a configurable timeout, the ACOS device attempts to generate traffic by issuing
ping requests to servers if configured, or broadcast ARP requests through the VLAN.
If the ACOS device does not receive any traffic on the VLAN before the timeout expires, a failover
occurs. The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default,
A10 recommends trying 30 seconds.
This HA checking method provides a passive means to detect network health, whereas heartbeat mes-
sages are an active mechanism. You can use either or both methods to check VLAN health. If you use
both methods on a VLAN, A10 recommends that you specify an HA checking interval (timeout) that is
much longer than the heartbeat interval.
For a configuration example, see “VLAN-Based Failover Example” on page 122.
Gateway-based Failover
Gateway-based failover uses ICMP health monitors to check the availability of the gateways. If any of
the active ACOS device’s gateways fails a health check, the ACOS device changes its HA status to
Down. If the HA status of the other ACOS device is higher than Down, a failover occurs.
page 82
Overview
Likewise, if the gateway becomes available again and all gateways pass their health checks, the ACOS
device recalculates its HA status according to the HA interface counts. If the new HA status of the
ACOS device is higher than the other ACOS device’s HA status, a failover occurs.
Configuration of gateway-based failover requires the following steps:
1. Configure a health monitor that uses the ICMP method.

2. Configure the gateway as an SLB real server and apply the ICMP health monitor to the server.
3. Enable HA checking for the gateway.
For a configuration example, see “Gateway-Based Failover Example” on page 123.
Route-based Failover
Route-based failover reduces the HA priority of all HA groups on the ACOS device, if a specific route is
missing from the IPv4 or IPv6 route table.
You can configure this feature for individual IP routes. When you configure this feature for a route, you
also specify the value to subtract from the HA priority of all HA groups, if the route is missing from the
route table.
You can configure this option for up to 100 IPv4 routes and up to 100 IPv6 routes. This option is valid
for all types of IP routes supported in this release (static and OSPF).
If the priority of an HA group falls below the priority for the same group on the other ACOS device in an
HA pair, a failover can be triggered.
Notes
• This feature applies only to routes in the data route table. The feature does not apply to routes in
the management route table.
• For failover to occur due to HA priority changes, the HA pre-emption option must be enabled.
For a configuration example, see “Route-Based Failover Example” on page 124.
Real Server or Port Health-based Failover

You can configure the ACOS device to decrease the HA priority of an HA group, if a real server or port’s
health status changes to Down.
You can configure this feature on individual real servers and ports. The feature is disabled by default.
To enable the feature, assign an HA weight to the server or port. If the server or port’s health status
changes to Down, the weight value is subtracted from the priority value of the HA group. You can spec-
ify a single HA group or allow the priority change to apply to all HA groups.
If the server or port’s status changes back to Up, the weight value is added back to the HA group’s pri-
ority value.
page 83
Overview
If the HA priority of a group falls below the priority of the same group on the other ACOS device, HA
failover can be triggered.
Notes
• The lowest HA priority value a server or port can have is 1.
• If HA weights for an HA group are assigned to both the server and an individual port, and both
health checks are unsuccessful, only the server weight is subtracted from the HA group’s priority.
• For failover to occur due to HA priority changes, the HA pre-emption option must be enabled.
VIP-based Failover
VIP-based failover allows service for a VIP to be transferred from one ACOS device in an HA pair to the
other ACOS device based on HA status changes of the real servers.
When you configure an HA group ID, you also specify its priority. If HA pre-emption is enabled, the HA
group’s priority can be used to determine which ACOS device in the HA pair becomes the Active ACOS
device for the HA group. In this case, the ACOS device that has a higher value for the group’s priority
becomes the Active ACOS device for the group.
page 84
Overview
If you enable the dynamic HA option on a virtual server, the ACOS device reduces the HA priority of the
group assigned to the virtual server, if a real server becomes unavailable. (A real server is unavailable if
it is marked Down by the ACOS device because the server failed its health check.) If the priority value is
reduced to a value that is lower than the group’s priority value on the other ACOS device in the HA pair,
and HA pre-emption is enabled, service of the virtual serve is failed over to the other ACOS device.
When a real server becomes available again, the weight value that was subtracted from the HA group’s
priority is re-added. If this results in the priority value being higher than on the other ACOS device, the
virtual server is failed over again to the ACOS device with the higher priority value for the group.
NOTE: Configure the same HA group ID on any floating IP addresses or Source

IP NAT pools used by the virtual server. For example, if you assign a vir-
tual server to HA group 31, also assign any floating IP addresses and IP
Source NAT pools used by the virtual server to HA group 31.
For a configuration example, see “VIP-Based Failover Example” on page 126.
page 85
Overview
How the Active ACOS Device Is Selected

In Active-Standby configurations, only one ACOS device is Active and the other is the Standby. After
you configure HA, the Active ACOS device is selected using the process shown in Figure 18.
FIGURE 18 Initial Selection of Active ACOS Device
After initial selection of the Active ACOS device, that device remains the Active ACOS device unless one
of the following events occurs:
• The Standby ACOS device stops receiving HA heartbeat messages from the Active ACOS device.
• The HA interface status of the Active ACOS device becomes lower than the HA interface status of
the Standby ACOS device.
• VLAN-based failover is configured and the VLAN becomes inactive.
• Gateway-based failover is configured and the gateway becomes unavailable.
page 86
Overview
• HA pre-emption is enabled, and the configured HA priority is changed to be higher on the Standby
ACOS device.
Figure 19 shows the events that can cause an HA failover.
FIGURE 19 HA Failover
page 87
Overview
HA Pre-Emption
By default, a failover occurs only in the following cases:
• The Standby ACOS device stops receiving HA heartbeat messages form the other ACOS device in
the HA pair.
• HA interface state changes give the Standby ACOS device a better HA state than the Active ACOS
device. (See “HA Interfaces” on page 79.)
• VLAN-based failover is configured and the VLAN becomes inactive. (See “VLAN-based Failover”
on page 82.)
• Gateway-based failover is configured and the gateway becomes unavailable. (See “Gateway-
based Failover” on page 82.)
• VIP-based failover is configured and the unavailability of real servers causes the Standby ACOS
device to have the greater HA priority for the VIP’s HA group. (See “VIP-based Failover” on
page 84.)
By default, failover does not occur due to HA configuration changes to the HA priority.
To enable the ACOS devices to failover in response to changes in priority, enable HA pre-emption. When
pre-emption is enabled, the ACOS device with the higher HA priority becomes the Active ACOS device. If
the HA priority is equal on both ACOS devices, then the ACOS device with the lower HA ID (1) becomes
the Active ACOS device.
NOTE: To force Active groups to change to Standby status, without changing

HA group priorities and enabling pre-emption, see “Forcing Active Groups
to Change to Standby Status” on page 128.
page 88
Overview
HA Sets
Optionally, you can provide even more redundancy by configuring multiple sets of HA pairs.
FIGURE 20 Multiple HA Pairs
In this example, two HA pairs are configured. Each pair is distinguished by an HA set ID. Each HA pair
can be used to handle a different set of real servers.
You can configure up to 7 HA sets. This feature is supported for Layer 2 and Layer 3 HA configurations.
The set ID can be specified along with the HA ID. (For syntax information, see Table 3 on page 90.)
page 89
Overview
HA Configuration Parameters
Table 3 lists the HA parameters.
TABLE 3 HA Parameters
Parameter Description and Syntax Supported Values
Global HA Parameters
HA ID HA ID of the ACOS device, and HA set to which HA ID: 1 or 2
the ACOS device belongs.
and HA set ID: 1-7
The HA ID uniquely identifies the ACOS device
HA set ID within the HA pair. Default: Neither parameter is set
The HA set ID specifies the HA set to which the

ACOS device belongs. This parameter is appli-
cable to configurations that use multiple ACOS
device pairs.
[no] ha id {1 | 2} [set-id num]
Config Mode > System > HA > HA Global - Gen-

eral
HA group ID Uniquely identifies the HA group on an individ- HA group ID: 1-31
ual ACOS device.
Priority: 1 (low priority) to 255 (high
The priority value can be used during selection priority
of the Active ACOS device. (See“How the Active
ACOS Device Is Selected” on page 86.) Default: not set
[no] ha group group-id priority num
Config Mode > System > HA > HA Global -

Group
page 90
Overview
TABLE 3 HA Parameters (Continued)

Floating IP IP address that downstream devices should Default: not set
address use as their default gateway. The same address
is shared by both ACOS devices in the HA pair.
Regardless of which device is Active, down-
stream devices can reach their default gateway
at this IP address.
Note: A floating IP address can not be the same

as an address that already belongs to a device.
For example, the IP address of an interface can
not be a floating IP address.
[no] floating-ip ipaddr

ha-group group-id
Config Mode > System > HA > HA Global - Float-

ing IP Address
HA interfaces Interfaces used for HA management. Ethernet interfaces
HA heartbeat messages are sent on HA inter- Default: not set

faces, unless you use the option to disable the
messages.
At least one HA interface must be specified. If

the interface is tagged, then a VLAN ID must be
specified if heartbeat messages are enabled on
the interface.
If you specify the interface type (server, router,

or both), changes to the interface state can con-
trol failover. (See “HA Interfaces” on page 79
and “How the Active ACOS Device Is Selected”
on page 86.)
[no] ha interface ethernet port-num

[router-interface |
server-interface | both]
[no-heartbeat | vlan vlan-id]
Config Mode > Network > Interface > LAN -

Select the interface and then click HA.
page 91
Overview

VLAN-based Enables the ACOS device to change its HA sta- Valid VLAN ID
HA tus based on the health of a VLAN.
Default: not set
When HA checking is enabled for a VLAN, the
active ACOS device in the HA pair monitors traf- The timeout can be 2-600 seconds.
fic activity on the VLAN. If there is no traffic on
the VLAN for half the duration of a configurable Although there is no default time-
timeout, the ACOS device attempts to generate out, A10 recommends trying 30
traffic by issuing ping requests to servers if seconds.
configured, or broadcast ARP requests through
the VLAN.
If the ACOS device does not receive any traffic

on the VLAN before the timeout expires, a
failover occurs.
[no] ha check vlan vlan-id timeout

seconds
Config Mode > System > HA > HA Global - Sta-

tus Check
Gateway-based Enables the ACOS device to change its HA sta- IP address of the gateway
HA tus based on the health of a gateway router.
Default: not set
If the gateway fails a Layer 3 (ICMP) health
check, the ACOS device changes its HA status Additional configuration is required.
to Down. If the HA status of the other ACOS (See “Gateway-based Failover” on
device is higher than Down, a failover occurs. page 82.)
[no] ha check gateway ipaddr
Config Mode > System > HA > HA Global - Sta-

tus Check
page 92
Overview

Session syn- Enables the ACOS devices to share information IP address of the other ACOS
chronization about active client sessions. If a failover occurs, device
client sessions continue uninterrupted. The
(Also called Standby ACOS device, when it becomes Active, Default: not set
“connection uses the session information it received from
mirroring”) the Active ACOS device before the failover to
continue the sessions without terminating
them.
To enable session synchronization, specify the

IP address of the other ACOS device in the HA
pair.
Session synchronization does not apply to DNS

sessions. Since these sessions are typically
very short lived, there is no benefit to synchro-
nizing them.
Note: This option also requires session syn-

chronization to be enabled on the individual vir-
tual service ports. (See “HA Parameters for
Virtual Service Ports” below.)
[no] ha conn-mirror ip ipaddr

eral
Pre-emption Controls whether failovers can be caused by Enabled or disabled
configuration changes to HA priority or HA ID.
Default: disabled
[no] ha preemption-enable
Config Mode > System> HA > HA Global - Gen-

eral
HA heartbeat Interval at which the ACOS device sends HA 1-255 units of 100 milliseconds
interval heartbeat messages on its HA interfaces. (ms) each
[no] ha time-interval Default: 200 ms

100-msec-units

eral
page 93
Overview

Retry count Number of HA heartbeat intervals the Standby 2-255
device will wait for a heartbeat message from
the Active ACOS device before failing over to Default: 5
become the Active ACOS device.
[no] ha timeout-retry-count num

eral
ARP repeat Number of additional gratuitous ARPs, in addi- 1-255
count tion to the first ones, an ACOS device sends
after transitioning from Standby to Active in an Default: 4 additional gratuitous
HA configuration. ARPs, for a total of 5
[no] ha arp-retry num

eral
Forced failover Forces HA groups to change from Active to Valid HA group ID.
Standby status.
If you do not specify a group ID, all
[no] ha force-self-standby Active groups are forced to change
[group-id] from Active to Standby status.
Note: This option provides a simple method to

force a failover, without the need to change HA
group priorities and enable pre-emption. The
option is not added to the configuration and
does not persist across reboots.
Note: The current release does not support con-

figuration of this parameter using the GUI.
Layer 2/3 Enables Layer 2/3 forwarding of Layer 4 traffic Enabled or disabled
forwarding of on the Standby ACOS device.
Layer 4 traffic Default: Disabled. Layer 4 traffic is
on the Standby [no] ha forward-l4-packet-on-standby dropped by the Standby ACOS
ACOS device device.
figuration of this parameter using the GUI.
Global HA Parameters for Layer 2 Inline Mode
page 94
Overview

Inline mode Enables Layer 2 inline mode and, optionally, Enabled or disabled
state specifies the HA interface to use for session
synchronization and for management traffic Default: disabled
between the ACOS devices.
When inline mode is enabled, the
[no] ha inline-mode preferred port is selected as
[preferred-port port-num] described in “Preferred HA Port” on
page 75.
Config Mode > System> HA > HA Inline Mode
Restart port list List of Ethernet interfaces on the previously Ethernet interfaces
Active ACOS device to toggle (shut down and
restart) following HA failover. Default: not set
[no] ha restart-port-list ethernet

port-list

Port restart Amount of time interfaces in the restart port list 1-100 units of 100 milliseconds
time remain disabled following a failover. (ms)
[no] ha restart-time 100-msec-units Default: 20 units of 100 ms (2 sec-

onds)
Global HA Parameters for Layer 3 Inline Mode
Inline mode Enables Layer 3 inline mode. Enabled or disabled
state
[no] ha l3-inline-mode Default: disabled

OSPF on Leaves OSPF enabled on the Standby ACOS Enabled or disabled
Standby ACOS device.
device Default for all HA modes except
[no] ha ospf-inline vlan vlan-id Layer 3 inline: disabled. OSPF is dis-
abled on the Standby ACOS device.
Note: This option is not configurable using the
GUI. Default for Layer 3 inline mode:
enabled. OSPF is allowed to run on
all VLANs by default.
Link event delay Change the delay waited by the ACOS device 100 milliseconds (ms) to 10000
before changing the HA state (Up, Partially Up, ms, in increments of 100 ms
or Down) in response to link-state changes on
HA interfaces. Default: 3000 ms (3 seconds)
[no] ha link-event-delay
100-ms-unit
page 95
Overview

HA Parameters for Virtual Servers
HA group ID HA group ID for a virtual server. 1-31
This is required to enable HA for the VIP. Default: not set
[no] ha-group group-id
Config Mode > SLB > Service > Virtual Server

Server weight Weight value assigned to real servers bound to 1-255
the virtual server.
Not set
The weight is used for VIP-based failover. (See
“VIP-based Failover” on page 84.)
[no] ha-dynamic server-weight
Config Mode > SLB > Service > Virtual Server -

Select the HA group, then select the Dynamic
Server Weight.
Link event delay Change the delay waited by the ACOS device 100 milliseconds (ms) to 10000
before changing the HA state (Up, Partially Up, ms, in increments of 100 ms
or Down) in response to link-state changes on
HA interfaces. Default: 3000 ms (3 seconds)
[no] ha link-event-delay
100-ms-unit
Config Mode > HA > Setting - HA Inline Mode

HA Parameters for Virtual Service Ports
Session Enables active client sessions on this virtual Enabled or disabled
synchroniza- port to continue uninterrupted following a
tion failover. Default: disabled
(Also called Note: This option also requires session syn-

“connection chronization to be enabled globally. (See “Global
mirroring”) HA Parameters” above.)
[no] ha-conn-mirror
Config Mode > SLB > Service > Virtual Server -

Port
HA Parameters for Real Servers
page 96
Overview

Priority cost Decreases the HA priority of an HA group, if the Weight: 1-255
real server’s health status changes to Down.
HA group: 1-31. If no group is speci-
[no] ha-priority-cost weight fied, the weight applies to all HA
[ha-group group-id] groups.
Note: The current release does not support con- Default: not set
figuration of this option using the GUI.
HA Parameters for Real Ports
Priority cost Decreases the HA priority of an HA group, if the Weight: 1-255
real port’s health status changes to Down.
HA group: 1-31. If no group is speci-
[no] ha-priority-cost weight fied, the weight applies to all HA
[ha-group group-id] groups.
Note: The current release does not support con- Default: not set
HA Parameters for Firewall Load Balancing (FWLB)
HA group ID When using the HA group ID with a DNS fire- 1-31
wall.
Default: not set
Config Mode > Security> Template > DNS Fire-

wall
Session Enables active client sessions on this port to Enabled or disabled

synchroniza- continue uninterrupted following a failover.
tion Default: disabled
Note: This option also requires session syn-
chronization to be enabled globally. (See “Global
HA Parameters” above.)
[no] ha-conn-mirror
HA Parameters for IP Network Address Translation (NAT) Pools
page 97
Overview

HA group ID HA group ID for IP NAT. 1-31
Option with ip nat pool, ipv6 nat pool, or ip nat Default: not set
inside command: ha-group group-id
Config Mode > IP Source NAT > IPv4 Pool
Config Mode > IP Source NAT > IPv6 Pool
Config Mode > IP Source NAT > NAT Range

HA Parameters for IP Routes
Priority cost Reduces the HA priority of all HA groups on the Default: not set
ACOS device, if the specified route is missing
from the IPv4 or IPv6 route table.
For IPv4 routes:
[no] ha check route

destination-ipaddr /mask-length
priority-cost weight
[gateway ipaddr]
[protocol {static | dynamic}]
[distance num]
For IPv6 routes:
[no] ha check route

destination-ipv6addr/mask-length
[gateway ipv6addr]
[distance num]

page 98
HA Status Indicators
The HA status of an ACOS device is displayed in the GUI and CLI. The HA status indicators provide the
following information:
• Current HA status of the ACOS device: Active or Standby
• Configuration status:
• Most recent configuration update – The system time and date when the most recent configura-
tion change was made.
• Most recent configuration save – The system time and date when the configuration was saved
to the startup-config.
• Most recent config-sync – The system time and date when the most recent configuration
change was made.
If the ACOS device is configured with multiple Role-Based Administration (RBA) partitions, sepa-
rate configuration status information is shown for each partition.
In the GUI
The current HA status is shown as one of the following:
• Active
• Standby
• Not Configured
The config-sync status is shown as one of the following:
• Sync
• Not-Sync
The GUI does not indicate when the most recent configuration update or save occurred. This informa-
tion is available in the CLI. (See below.)
NOTE: In the current release, the configuration synchronization status is not

updated from Not-Sync to Sync if the synchronization target is the run-
ning-config.
ACOS 2.7.1 provides the user with the ability to configure the prompt. It allows you to add or remove
the device hostname, the aVCS chassis device ID, the aVCS status, the VRRP-A status, or the HA sta-
tus. Configuring a prompt is optional. If all the five options are configured, an example of a prompt may
say AX1030-vMaster[7/1](config)#.
page 99
Use the following command to change your terminal prompt:
[no] terminal prompt {ha-status | hostname | chassis-device-id | vcs-status}
To display the HA or VRRP-A status in the prompt, specify the ha-status keyword. For example, this can
be Active, Standby, or ForcedStandby. When you configure ha-status, the VRRP-A or HA states of a
device will be displayed in the prompt. ForcedStandby will be displayed when you issue the terminal
prompt ha-status command and the device is in a forced standby state.
Using the GUI
This feature is not supported in the GUI.
Using the CLI
To configure the terminal prompt, issue the following command:
ACOS(config)#terminal prompt hostname ha-status vcs-status chassis-device-id
If your device is running aVCS and HA, you can configure the following commands. With each configu-
ration entry, see how the terminal prompt changes. The prompt additions appear in bold font:
ACOS(config)#terminal prompt hostname vcs-status

AX1030-vMaster(config)#show run | sec prompt
terminal prompt hostname vcs-status
If the device is in a forced standby state, you will see the following prompt:
AX1030(config)#terminal prompt ha-status

ForcedStandby(config)#
Use the show terminal command to view the terminal prompt format. By default, all prompts are dis-
played. So, if you revert from a configured prompt to a default prompt, you will see the following results:
AX1030-vMaster(config)#no terminal prompt

AX1030-Active-vMaster[1/1](config)#show terminal
Terminal prompt format: hostname ha-status vcs-status chassis-device-id
page 100
Configuring Layer 3 HA
To configure Layer 3 HA:
1. Configure the following global HA parameters:

• HA ID
• HA group ID and priority. For an Active-Standby configuration, configure one group ID. For
Active-Active, configure multiple HA group IDs.
• Floating IP address (optional)
• Session synchronization (optional)
• HA pre-emption (optional)
2. Configure the HA interfaces.
3. Add each virtual server to an HA group.
4. If session synchronization is globally enabled, enable it on the individual virtual ports whose client
sessions you want to synchronize.
5. If IP NAT pools are configured, add each pool to an HA group.
Using the GUI
Configuring Global HA Parameters
1. Select Config Mode > System> HA.

a. In the Identifier drop-down list, select the HA ID for the ACOS device.
b. Select Enabled next to HA Status.
c. To enable pre-emption, select Enabled next to Preempt Status.
d. To enable connection mirroring, enter the IP address of the other ACOS device in the HA Mirror-
ing IP Address field.
NOTE: Enter the real IP address of the ACOS device, not the floating IP address
that downstream devices will use as their default gateway address.
2. In the Group section, configure HA group parameters:

a. Select HA group 1 from the Group Name drop-down list.
b. In the Priority field, enter the priority for HA group 1 and click Add.
c. If you are configuring Active-Active, select the next HA group from the Group Name drop-down
list, enter its priority in the Priority field, and click Add.
page 101
Repeat for each additional group used in the configuration.

3. In the Floating IP Address section, configure the floating IP addresses for the HA groups.
a. Select an HA group from the Group Name drop-down list.
b. Select the address type (IPv4 or IPv6).
c. Enter the floating IP address for the group.
d. Click Add.
e. If you are configuring Active-Active, select the next HA group from the Group Name drop-down
list, and repeat the previous steps.
4. Click OK.
Configuring HA Interfaces
1. Select Config Mode > Network > Interface.

2. On the menu bar, select LAN. The list of the ACOS device’s physical Ethernet data interfaces
appears.
3. Perform the following steps for each HA interface. (For information, see “HA Interfaces” on
page 79.)
a. Click on the interface number.
b. In the HA section, select Enabled next to HA Enabled.
c. To specify the interface type, select one of the following or leave the setting None:
• Router-Interface
• Server-Interface
• Both
d. To enable HA heartbeat messages, select Enabled next to Heartbeat.
e. To restrict the HA heartbeat messages to a specific VLAN, enter the VLAN ID in the VLAN field.
f. Click OK.
Configuring HA Parameters on a Virtual Server
1. Select Config Mode > SLB > Service > Virtual Server.
2. Click on the virtual server name or click Add to add a new one.
3. In the General section, select the HA group ID from the HA Group drop-down list.
NOTE: The Dynamic Server Weight option is used for VIP-based failover. For
information, see “VIP-based Failover” on page 84.
page 102
4. Configure other general settings, not related to HA, if needed.

5. If you plan to use session synchronization (connection mirroring) for a service port:
a. In the Port section, click Add to add a new virtual service port or select an existing port and click
Edit. The Virtual Server Port section appears.
b. Select enabled next to HA Connection Mirror.
c. Click OK. The service port list re-appears.
NOTE: The GUI does not support enabling connection mirroring on some types
of service ports. However, you can enable connection mirroring for these
service types using the CLI.
6. Click OK to complete configuration of the virtual server.
HA Configuration of AX1
FIGURE 21 Config Mode > HA > Setting > HA Global
page 103
FIGURE 22 Config Mode > Network > Interface> LAN (Ethernet interface 1)
NOTE: This example shows HA configuration of a single interface. Make sure to

configure HA settings on the other HA interfaces too.
FIGURE 23 Config Mode > SLB > Service > Virtual Server (VIP1)
page 104
HA Configuration of AX2
FIGURE 25 Config Mode > HA > HA Global
page 105
Using the CLI

1. To configure the global HA parameters, use the following commands at the global configuration
level of the CLI:
ha id {1 | 2} [set-id num]
ha group group-id priority num
floating-ip ipaddr ha-group group-id
page 106
ha interface ethernet port-num

[router-interface | server-interface | both]
[no-heartbeat | vlan vlan-id]
ha conn-mirror ip ipaddr
ha preemption-enable
2. To add a virtual server to an HA group, use the following command at the configuration level for
the virtual server:
ha-group group-id
Use the same HA group ID for the same virtual server, on both ACOS devices.
3. If session synchronization is globally enabled, use the following command at the configuration
level for the virtual port to enable session synchronization for the port:
ha-conn-mirror
4. If IP NAT will be used, use the following option with the ip nat pool or ipv6 nat pool command when
configuring the pool.
ha-group group-id
(For the complete command syntax, see Table 3 on page 90.)
Commands on AX1
This examples shows the CLI commands to implement the Active-Active configuration shown in
Figure 14 on page 71.
The following commands configure the HA ID and HA groups. Since this is an Active-Active configura-
tion, both HA groups are configured. The priority for group 1 is set to a low value. The same group will
be set to a higher priority value on the other ACOS device. Likewise, the priority of group 2 is set to a
high value on this ACOS device but will be set to a lower value on the other ACOS device.
Later in the configuration, each virtual server will need to be added to one or the other of the HA groups.
AX1(config)#ha id 1
AX1(config)#ha group 1 priority 1
The following commands configure the floating IP addresses for each HA group. The real servers and
the Layer 2 switches connected to them will need to be configured to use the floating IP addresses as
their default gateways.
AX1(config)#floating-ip 10.10.10.1 ha-group 1

The following commands configure the HA interfaces. The interface types are specified, so that the HA
state of the ACOS device can be more precisely calculated based on HA interface state. (See “HA Inter-
faces” on page 79.)
page 107
Heartbeat messages are disabled on all HA interfaces except the dedicated HA link between the ACOS
devices.
AX1(config)#ha interface ethernet 1 router-interface no-heartbeat

AX1(config)#ha interface ethernet 3 server-interface no-heartbeat
AX1(config)#ha interface ethernet 5
The following command enables session synchronization (connection mirroring). The feature also will
need to be enabled on individual virtual ports, later in the configuration. The IP address is the real
address of the other ACOS device.
AX1(config)#ha conn-mirror ip 10.10.30.2
The following command enables HA pre-emption, to ensure that the Active and Standby for each virtual
server are chosen based on the configuration. By default, when HA is first configured, Active and
Standby are selected based on which ACOS device comes up first.
AX1(config)#ha preemption-enable
The following commands add each of the virtual servers to an HA group, and enables session synchro-
nization on the virtual ports. (For brevity, this example does not show the complete SLB configuration,
only the HA part of the SLB configuration.)
AX1(config)#slb virtual-server VIP1

AX1(config-slb virtual server)#ha-group 1
AX1(config-slb virtual server)#port 80 tcp
AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror
AX1(config-slb virtual server-slb virtua...)#exit
AX1(config-slb virtual server)#exit
Commands on AX2
Here are the commands for AX2. The priority values for the groups are different from the values set on
AX1, so that group 1 has higher priority on this ACOS device than on AX1. Likewise, the priority of group
2 is set so that its priority is higher on AX1.
AX2(config)#ha id 2
page 108
Configuring Layer 2 HA (Inline Mode)
The floating IP addresses must be the same as the ones set on AX1.

The IP address for session synchronization is the address of AX1.

The HA configuration for virtual servers and virtual ports is identical to the configuration on AX1.



• HA ID
• HA group ID and priority. Configure only one group ID. Configure the same ID on both ACOS
devices.
• Inline mode and optional preferred port
• Restart port list and time (optional)
• HA interfaces
page 109

2. Add each virtual server to the HA group.
4. If IP NAT pools are configured, add each pool to the HA group.
NOTE: If source NAT is not configured for the VIP, but real servers send
responses to a gateway IP address other than the floating IP address,
CPU processing must be enabled on the interfaces connected to the real
servers. This applies to the following ACOS device models: AX 2200,
AX 2200-11, AX 3100, AX 3200, AX 3200-11, AX 3200-12, AX 3400, AX
5100,
AX 5200, and AX 5200-11. On other models, the option for CPU process-
ing is not valid and is not required.
Layer 2 Inline HA Configuration Example

The following configuration examples implement the deployment shown in Figure 16 on page 74. In
addition to the inline features described in this section, the sample configuration also uses the follow-
ing HA features:
• Identification of HA interface type: server or router – The interface types affect the ACOS device’s
summary link state for HA. (See “HA Interfaces” on page 79.)
• Session synchronization (also called “connection mirroring”) – Existing client sessions remain up
during a failover.
• Floating IP – The default gateway IP address used by the real servers is a floating IP address
shared by the ACOS devices, rather than the IP address of the Active ACOS device. Servers can
still reach clients through their default gateway after an HA failover, without the need for the gate-
way address to be changed to the Standby ACOS device’s address.
Using the GUI
Configuring Global HA Parameters
1. Select Config Mode > System > HA.

a. In the General section, select the HA ID for the ACOS device from the Identifier drop-down list.
b. Select Yes next to HA Status.
c. To enable pre-emption, select Yes next to Preempt Status.
page 110
d. To enable connection mirroring, enter the IP address of the other ACOS device in the HA Mirror-
ing IP Address field.
NOTE: Enter the real IP address of the ACOS device, not the floating IP address
that downstream devices will use as their default gateway address.
2. In the Group section, configure HA group parameters:

a. Select HA group 1 from the Group Name drop-down list.
b. In the Priority field, enter the priority for HA group 1 and click Add.
3. In the Floating IP Address section, configure the floating IP address for the HA group.
a. Select an HA group 1 from the Group Name drop-down list.
b. Select the address type (IPv4 or IPv6).
c. Enter the floating IP address for the group.
d. Click Add.
4. Click OK.
Configuring HA Interface Parameters
1. Select Config Mode > Network > Interface.

2. On the menu bar, select LAN. The list of the ACOS device’s physical Ethernet data interfaces
appears.
3. Perform the following steps for each HA interface. (For information, see “HA Interfaces” on
page 79.)
a. Click on the interface number.
b. In the HA section, select Enabled next to HA Enabled.
c. To specify the interface type, select one of the following or leave the setting None:
• Router-Interface
• Server-Interface
• Both
d. To enable HA heartbeat messages, select Enabled next to Heartbeat.
e. To restrict the HA heartbeat messages to a specific VLAN, enter the VLAN ID in the VLAN field.
f. If source NAT is not configured for the VIP, but real servers send responses to a gateway IP
address other than the floating IP address, select CPU Process in the General section.
page 111
This requirement applies to the following ACOS devices models: AX 2200, AX 2200-11,
AX 3100, AX 3200, AX 3200-11, AX 3200-12, AX 3400, AX 5100, AX 5200, and AX 5200-11. On
other models, the option for CPU processing is not valid and is not required.
g. Click OK.
Configuring Inline Parameters
1. Select Config Mode > System > HA > HA Inline Mode

2. Select Enabled next to Inline Mode Status.
3. Select the preferred port.
4. In Restart Port List section, select the HA interfaces.
5. Click >> to move them to the Selected list.
6. Click OK.
The following GUI screens configure HA on AX1 in Figure 16 on page 74.
FIGURE 28 Config Mode > System > HA
page 112
FIGURE 29 Config Mode > Network > Interface > LAN (Ethernet interface 1)
NOTE: This example shows HA configuration of a single interface. Make sure to

configure HA settings on the other HA interfaces too.
FIGURE 30 Config Mode > System > HA > HA Inline Mode
page 113
Using the CLI
Commands on AX1
The following commands configure the HA ID and set the HA priority. HA priority is associated with an
HA group. Since inline mode is supported only in Active-Standby configurations, only one HA group is
used. Later in the configuration, the VIP is assigned to this HA group.
AX1(config)#ha id 1
The following command enables inline HA mode and specifies the preferred HA port.
AX1(config)#ha inline-mode preferred-port 5
The following commands configure the HA interfaces. Each interface that is connected to a server, a
router, or the other ACOS device can be configured as an HA interface. Make sure to add the preferred
HA port as one of the HA interfaces.

AX1(config)#ha interface ethernet 3 server-interface
The following command enables restart of the HA ports connected to the routers, to occur if the ACOS
device transitions to Standby.
AX1(config)#ha restart-port-list ethernet 1 to 2
NOTE: If source NAT is not configured for the VIP, but real servers send
responses to a gateway IP address other than the floating IP address,
enter the cpu-process command at the configuration level for each inter-
face connected to the real servers. This requirement applies to the fol-
lowing AX models: AX 2200, AX 2200-11, AX 3100, AX 3200, AX 3200-11,
AX 3200-12, AX 3400, AX 5100, AX 5200, and AX 5200-11. On other mod-
els, the option for CPU processing is not valid and is not required.
The following command enables HA pre-emption mode, which causes failover to occur in response to
administrative changes to the HA configuration. (For example, if you change the HA priority so that the
other ACOS device has higher priority, this will trigger a failover, but only if pre-emption mode is
enabled.)
The following command specifies the IP address of the other ACOS device, to use for session synchro-
nization.
page 114
The following command configures the floating IP address for the real servers to use as their default
gateway address.
The following commands configure a health method, real servers, a server group, and a VIP for an
HTTP service.
AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3

AX1(config-health:monitor)#method http url HEAD /index.html
AX1(config-health:monitor)#exit
AX1(config)#slb server s1 172.168.10.30
AX1(config-real server)#port 80 tcp
AX1(config-real server-node port)#health-check myHttp
AX1(config-real server-node port)#exit
AX1(config-real server)#exit
AX1(config)#slb service-group g80 tcp
AX1(config-slb service group)#member s1:80
AX1(config-slb service group)#exit
AX1(config)#slb virtual-server v1 172.168.10.80
AX1(config-slb virtual server-slb virtua...)#service-group g80
Commands on AX2
Here are the commands for implementing HA on the standby ACOS device, AX2. Most of the com-
mands are the same as those on AX1, with the following exceptions:
• The HA ID is 2.
• The HA priority is 1.
• The session synchronization (conn-mirror) IP address is the address of the Active ACOS device.
(On the Active ACOS device, the session synchronization IP address is the address of the
Standby ACOS device.)
AX2(config)#ha id 2
page 115

AX2(config)#ha inline-mode preferred-port 5
page 116


• HA ID
• HA group ID and priority. Configure only one group ID. Configure the same ID on both ACOS
devices.
• Inline mode
• HA interfaces
2. Enable CPU processing on the Ethernet interfaces that will receive server replies to client requests.
3. Add each virtual server to the HA group.
5. If IP NAT pools are configured, add each pool to the HA group.
Layer 3 Inline HA Configuration Example

The following configuration example implements the deployment shown in Figure 17 on page 77.
NOTE: The GUI does not support configuration of Layer 3 inline mode in the cur-
rent release.
Using the CLI

1. To enable Layer 3 inline mode, use the following command at the global configuration level of the
CLI:
ha l3-inline-mode
2. To enable CPU processing on an interface, use the following command at the configuration level
for the interface:
cpu-process
If the interface is part of a trunk, use the command at the interface configuration level for the trunk.
page 117
Commands on AX1
The following commands configure the interfaces. Since Ethernet interfaces 3 and 4 will receive server
replies to client requests, CPU processing is enabled on those interfaces.
AX1(config)#interface ethernet 1
AX1(config-if:ethernet1)#enable
AX1(config-if:ethernet1)#interface ethernet 2
AX1(config-if:ethernet3)#cpu-process
AX1(config-if:ethernet5)#exit
AX1(config)#vlan 100
AX1(config-vlan:100)#untagged ethernet 1 to 4
AX1(config-vlan:100)#router-interface ve 100
AX1(config-vlan:100)#exit
AX1(config)#vlan 5
AX1(config-vlan:5)#untagged ethernet 5
AX1(config)#interface ve 100
AX1(config-if:ve100)#ip address 172.168.10.2 /24
AX1(config-if:ve100)#interface ve 5
AX1(config-if:ve5)#exit
The following commands configure the HA ID and set the HA priority. HA priority is associated with an
HA group. Later in the configuration, the VIP is assigned to this HA group.
AX1(config)#ha id 1
The following command enables Layer 3 inline HA mode.
AX1(config)#ha l3-inline-mode
page 118
The following commands configure the HA interfaces. Each interface that is connected to a server, a
router, or the other ACOS device can be configured as an HA interface. (Make sure to add the dedicated
HA link between the ACOS devices as one of the HA interfaces.)

The following command enables restart of the HA ports connected to the routers, to occur if the ACOS
device transitions to Standby.
The following command enables HA pre-emption mode, which causes failover to occur in response to
administrative changes to the HA configuration. (For example, if you change the HA priority so that the
other ACOS device has higher priority, this will trigger a failover, but only if pre-emption mode is
enabled.)
The following command specifies the IP address of the other ACOS device, to use for session synchro-
nization.
The following command configures the floating IP address for the real servers to use as their default
gateway address.
The following commands configure a health method, real servers, a server group, and a VIP for an
HTTP service.

page 119

Commands on AX2
Here are the commands for implementing HA on AX2. Most of the commands are the same as those
on AX1, with the following exceptions:
• The IP interfaces are different.
• The HA ID is 2.
• The HA priority is 1.
The session synchronization (conn-mirror) IP address is the address of AX1. (On AX1, the session syn-
chronization IP address is the address of AX2.)
AX2(config)#interface ethernet 1
AX2(config-if:ethernet5)#exit
AX2(config)#vlan 100
AX2(config-vlan:100)#untagged ethernet 1 to 4
AX2(config)#vlan 5
AX2(config-vlan:5)#untagged ethernet 5
AX2(config)#interface ve 100
AX2(config-if:ve100)#interface ve 5
AX2(config-if:ve5)#exit
AX2(config)#ha id 2
page 120

AX2(config)#ha l3-inline-mode
page 121
Configuring Optional Failover Triggers

The following sections show how to configure the following optional failover triggers:
• VLAN-based failover
• Gateway-based failover
• VIP-based failover
Only the configuration relevant to the triggers is shown. A complete HA configuration also includes the
configuration items described in the previous sections.
NOTE: Failover based on HA interface state is also optional, and is described in

other sections in this chapter.
VLAN-Based Failover Example

To configure VLAN-based failover, use either of the following methods.
(For a description of the feature, see “VLAN-based Failover” on page 82.)
Using the GUI

1. Select Config Mode > System > HA > HA Global.
2. In the Status Check section, enter the VLAN ID in the VLAN ID field.
3. Enter the timeout in the Timeout field.
The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default,
A10 recommends trying 30 seconds.
4. Click Add.
5. Repeat step 2 through step 4 for each VLAN to be monitored for HA.
6. Click OK.
Using the CLI
To enable HA checking for a VLAN, use the following command at the global configuration level of the
CLI:
[no] ha check vlan vlan-id timeout seconds
The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default, A10
recommends trying 30 seconds.
page 122
The following command enables VLAN-based failover for VLAN 10 and sets the timeout to 30 seconds:
ACOS(config)#ha check vlan 10 timeout 30
Gateway-Based Failover Example

To configure gateway-based failover, use either of the following methods.
(For a description of the feature, see “Gateway-based Failover” on page 82.)
Using the GUI

1. Configure a health monitor that uses the ICMP method:
a. Select Config Mode > SLB > Health Monitor.
b. Click Add.
c. In the Health Monitor section, enter a name for the monitor.
d. In the Method section, select ICMP from the Type drop-down list.
e. Click OK.
2. Configure the gateway as an SLB real server and apply the ICMP health monitor to the server:
a. Select Config Mode > SLB > Service > Server on the menu bar.
b. Click Add. The General section appears.
c. In the General section, enter a name for the gateway in the Name field.
d. In the IP Address field, enter the IP address of the gateway.
e. In the Health Monitor drop-down list, select the ICMP health monitor you configured in step 1.
f. Click OK.
3. Enable gateway-based failover:
a. Select Config Mode > System > HA > HA Global.
b. In the Status Check section, enter the IP address of the gateway in the IP Address field.
c. Click Add.
d. Repeat step b and step c for each gateway to be monitored for HA.
e. Click OK.
Using the CLI

1. To configure a health monitor for a gateway, use the following commands.
page 123
[no] health monitor monitor-name

Enter this command at the global Config level.
[no] method icmp
Enter this command at the configuration level for the health monitor.
2. To configure the gateway as an SLB real server and apply the health monitor to the server, use the
following command.
[no] slb server server-name ipaddr
[no] health-check monitor-name
3. To enable HA health checking for the gateway, use the following command at the global configura-
tion level.
[no] ha check gateway ipaddr
CLI Example
The following commands configure an ICMP health method:
ACOS(config)#health monitor gatewayhm1

ACOS(config-health:monitor)#method icmp
ACOS(config-health:monitor)#exit
The following commands configure a real server for the gateway and apply the health monitor to it:
ACOS(config)#slb server gateway1 10.10.10.1

ACOS(config-real server)#health-check gatewayhm1
ACOS(config-real server)#exit
The following command enables HA health checking for the gateway:
ACOS(config)#ha check gateway 10.10.10.1
Route-Based Failover Example

You can configure HA route awareness for IPv4 routes and IPv6 routes.
NOTE: The current release does not support this feature in the GUI.
HA Route Awareness for IPv4 Routes
To configure HA route awareness for an IPv4 route, use the following command at the global configu-
ration level of the CLI:
page 124
[no] ha check route destination-ipaddr /mask-length

[gateway ipaddr]
[distance num]
The destination-ipaddr /mask-length option specifies the destination IPv4 subnet of the route.
The priority-cost weight option specifies the value to subtract from the HA priority of each HA group, if
the IP route table does not have a route to the destination subnet.
The gateway addr option specifies the next-hop gateway for the route.
The protocol option specifies the source of the route:
• static – The route was added by an administrator.
• dynamic – The route was added by a routing protocol. (This includes redistributed routes.)
The distance num option specifies the metric value (cost) of the route.
Omitting an optional parameter matches on all routes. For example, if you do not specify the next-hop
gateway, routes that match based on the other parameters can have any next-hop gateway.
HA Route Awareness for IPv6 Routes
To configure HA route awareness for an IPv6 route, use the following command at the global configu-
ration level of the CLI:
[no] ha check route

destination-ipv6addr/mask-length
[gateway ipv6addr]
[distance num]
The destination-ipv6addr/mask-length option specifies the destination IPv6 address. The other options
are the same as those for IPv4 routes. (See above.)
CLI Examples
The following command configures HA route awareness for a default IPv4 route. If this route is not in
the IP route table, 255 is subtracted from the HA priority of all HA groups.
ACOS(config)#ha check route 0.0.0.0 /0 priority-cost 255
NOTE: The lowest possible HA priority value is 1. Deleting 255 sets the HA prior-
ity value to 1, regardless of the original priority value.
page 125
The following command configures HA route awareness for a dynamic route to subnet 10.10.10.x with
route cost 10. If the IP route table does not have a dynamic route to this destination with the specified
cost, 10 is subtracted from the HA priority value for each HA group.
ACOS(config)#ha check route 10.10.10.0 /24 priority-cost 10 protocol dynamic distance

10
The following commands configure HA route awareness for an IPv6 route to 3000::/64. Based on the
combination of these commands, if the IPv6 route table does not contain any routes to the destination,
105 is subtracted from the HA priority of each HA group.
If the IPv6 route table does contain a static route to the destination, but the next-hop gateway is not
2001::1, the ACOS device subtracts only 5 from the HA priority of each HA group.
ACOS(config)#ha check route 3000::/64 priority-cost 100

ACOS(config)#ha check route 3000::/64 priority-cost 5 protocol static gateway 2001::1
VIP-Based Failover Example

To configure VIP-based failover, use either of the following methods.
These procedures apply specifically to the VIP-based failover parameters. You also need to configure
HA global and interface parameters. See “Configuring Global HA Parameters” on page 101 and “Config-
uring HA Interfaces” on page 102.
(For a description of the feature, see “VIP-based Failover” on page 84.)
Using the GUI
To configure VIP-based failover on a virtual server:
1. Configure HA global and interface parameters, if you have not already done so.
2. Select Config Mode > SLB > Service > Virtual Server.
3. Click on the virtual server name or click Add to create a new one.
4. Select the HA group from the HA Group drop-down list.
The Dynamic Server Weight field appears.
NOTE: If the HA Group drop-down list does not have any group IDs, you still
need to configure global HA parameters. See “Configuring Global HA
Parameters” on page 101.
5. Enter other parameters if needed (for example, the name, IP address, and virtual service ports).
6. Click OK.
page 126
Using the CLI
To configure VIP-based failover, use the following commands:
Enter this command at the configuration level for a virtual server, to assign the virtual server to the HA
group. The group-id can be 1-31.
[no] ha-dynamic server-weight
Enter this command at the configuration level for the virtual server to enable VIP-based failover. The
server-weight specifies the amount to subtract from the HA group's priority value for each real server
that becomes unavailable. The weight can be 1-255. The default is 1.
CLI Example
The following command configures HA group 6 on ACOS-1 and assigns priority 100 to the group:
ACOS-1(config)#ha group 6 priority 100
The following command enables HA pre-emption. HA pre-emption must be enabled in order for failover
to occur based on HA group priority changes.
ACOS-1(config)#ha preemption-enable
The following command configures a floating IP address and assigns it to HA group 6:
ACOS-1(config)#floating-ip 192.168.10.1 ha-group 6
The following commands assign virtual server VIP2 to HA group 6 and enable VIP-based failover for the
virtual server. (For simplicity, this example does not show configuration of the real servers or non-HA
virtual server options.)
ACOS-1(config)#slb virtual VIP2 192.168.10.22

ACOS-1(config-slb virtual server)#ha-group 6
ACOS-1(config-slb virtual server)#ha-dynamic 10
The following commands configure the HA settings on ACOS-2. The priority for HA group 6 is set to 80.
The server weight for HA group 6 on VIP2 is set to 10, the same weight value set on ACOS-1. Up to 2
real servers bound to VIP2 can become unavailable on ACOS-1 without triggering a failover. However, if
page 127
Forcing Active Groups to Change to Standby Status
a third real server becomes unavailable, the priority of HA group 6 is reduced to 70, which is lower than
the priority value set on ACOS-2 for the group. In this case, a failover does occur for VIP2.
ACOS-2(config)#ha group 6 priority 80

ACOS-2(config)#ha preemption-enable
ACOS-2(config)#floating-ip 192.168.10.1 ha-group 6
ACOS-2(config)#slb virtual VIP2 192.168.10.22
ACOS-2(config-slb virtual server)#ha-group 6
ACOS-2(config-slb virtual server)#ha-dynamic 10
Forcing Active Groups to Change to Standby Status

To force HA groups to change from Active to Standby status, use the following command at the global
configuration level of the CLI:
[no] ha force-self-standby [group-id]
If you specify a group ID, only the specified group is forced to change from Active to Standby. If you do
not specify a group ID, all Active groups are forced to change to Standby status.
CLI Example
The following command forces HA group 1 to change from Active to Standby status:
ACOS(config)#ha force-self-standby 1
Enabling Session Synchronization

Session synchronization backs up live client sessions on the Backup ACOS device.
To enable session synchronization:
• Globally enable the feature, specifying the IP address of the other ACOS device in the HA pair.
• Enable the feature on individual virtual ports. Session synchronization is supported for Layer 4
sessions.
NOTE: HA session synchronization is required for persistent sessions (source-

IP persistence, and so on), and is therefore automatically enabled for
these sessions by the ACOS device. Persistent sessions are synchro-
nized even if session synchronization is disabled in the configuration.
page 128
Enabling Session Synchronization
Using the GUI
To globally enable the feature:
1. Select Config Mode > System > HA> HA Global.

2. In the Mirror IP Address field, enter the IP address of a data interface on the other ACOS device in
the HA pair.
3. Click OK or Apply.
To enable the feature on individual virtual ports:
1. Select Config Mode > SLB > Service > Server.

2. On the menu bar, select Virtual Server.
3. Click on the virtual server name.
4. On the Port tab, select the port and click Edit.
5. Select Enabled next to HA Connection Mirror.
NOTE: If the HA Connection Mirror option is not displayed, session synchroniza-

tion is not supported for this service type.
6. Click OK to redisplay the Port tab.

7. Click OK again.
Using the CLI
To globally enable session synchronization, use the following command at the global configuration
level of the CLI:
[no] ha conn-mirror ip ipaddr
The ipaddr must be an IP address of a data interface on the other ACOS device.
To enable session synchronization on a virtual port, use the following command at the configuration
level for the port:
[no] ha-conn-mirror
CLI Example
The following command sets the session synchronization address to 10.10.10.66, the IP address of the
other ACOS device in this HA pair:
ACOS(config)#ha conn-mirror ip 10.10.10.66
page 129
Configuring OSPF-Related HA Parameters
The following commands access the configuration level for a virtual port and enable connection mirror-
ing on the port:
ACOS(config)#slb virtual-server vip1 10.10.10.100

ACOS(config-slb virtual server)#port 80 tcp
ACOS(config-slb virtual server-slb virtua...)#ha-conn-mirror
Configuring OSPF-Related HA Parameters

The following sections describe how to configure OSPF-related HA parameters.
OSPF Awareness of HA
The ACOS device uses HA-aware VIPs, floating IPs, IP NAT pools, and IP range lists with route redistri-
bution to achieve HA-aware dynamic routing. However, by default, the OSPF protocol on the ACOS
device is not aware of the HA state (Active or Standby) of the ACOS device. Consequently, following HA
failover of an ACOS device, other OSPF routers might continue forwarding traffic to the Standby ACOS
device (the former Active ACOS device), instead of the new Active ACOS device.
NOTE: In Layer 3 inline mode, all VLANs on the ACOS device participate in OSPF
routing by default. (See “OSPF Support on Standby ACOS Device in Layer
3 Inline Mode” on page 131.)
You can assign an additional cost to an ACOS device’s OSPF interfaces when the HA status for any
group on the device is Standby. If failover of one or more HA groups from Active to Standby occurs, the
ACOS device does the following:
• Updates the cost of all its OSPF interfaces
• Sends Link-State Advertisement (LSA) updates to its OSPF neighbors advertising the interface
cost change
After an OSPF neighbor receives the LSA update, the neighbor updates its OSPF link-state database
with the increased cost of the links. The increased cost biases route selection away from paths that
use the Standby ACOS device.
Similarly, if a failover results in HA status Active for all HA groups on an ACOS device, the device
removes the additional cost added for Standby status from all its OSPF interfaces and sends LSA
updates to advertise the change. The reduced cost biases route selection toward paths that use the
Active ACOS device and away from paths that use the Standby ACOS device.
page 130
NOTE: The additional cost for Standby status is removed only if the HA status
for all HA groups on the device is Active. Otherwise, if the status of any of
the groups is Standby, the additional cost remains in effect for all OSPF
interfaces on the device.
Enabling OSPF Awareness of HA
To enable OSPF awareness of HA, use the following command at the OSPF configuration level.
[no] ha-standby-extra-cost num
The num option specifies the extra cost to add to the ACOS device’s OSPF interfaces, if the HA status of
one or more of the device’s HA groups is Standby. You can specify 1-65535. If the resulting cost value
is more than 65535, the cost is set to 65535.
Enter the command on each of the ACOS devices in the HA pair.
OSPF Support on Standby ACOS Device in Layer 3 Inline Mode

In HA Layer 3 inline mode deployments, OSPF adjacencies are automatically formed between the
Active and Standby ACOS devices and all OSPF routers on all VLANs.
To limit OSPF adjacency formation to a specific VLAN only, explicitly configure adjacency formation for
that VLAN. In this case, OSPF adjacency formation does not occur for any other VLANs. Use the follow-
ing command at the global configuration level of the CLI:
ha ospf-inline vlan vlan-id

NOTE: This section describes how to manually synchronize the configuration.
You can use the ACOS Virtual Chassis System (aVCS) to automate con-
figuration synchronization.
You can use config-sync options to manually synchronize some or all of the following:
• Startup-config, to the other ACOS device’s startup-config or running-config
• Running-config, to the other ACOS device’s running-config or startup-config)
page 131
• Data files:
• SSL certificates and private-key files

• aFleX files
• External health check files
NOTE: Manual config-sync is not required if the ACOS device is running aVCS.
Requirements
Session synchronization (connection mirroring) is required for manual config sync. Config sync uses
the session synchronization link. To enable session synchronization, see “Enabling Session Synchroni-
zation” on page 128.
SSH management access must be enabled on both ends of the link, and the link must be on a data
interface, not on the management interface.
Configuration Items That Are Backed Up

The following configuration items are backed up during HA configuration synchronization:
• Admin accounts and settings
• AAA settings
• DDoS protection settings
• ICMP rate limiting
• Floating IP addresses
• IP NAT configuration, including LSN and DS-Lite
• ACLs
• Health monitors
• IP limiting settings
• PBSLB settings
• SLB
• RAM caching
• DNS security and caching
• FWLB
page 132
• GSLB
• Data Files:
• aFleX files
• External health check files
• SSL certificates, private-key files, and CRLs
• Class-list files
NOTE: For IP NAT configuration items to be backed up, you must specify an HA
group ID as part of the NAT configuration.
Configuration Items That Are Not Backed Up

The following configuration items are not backed up during HA configuration synchronization:
• Interface-specific management access settings
• Hostname
• MAC addresses
• Management IP addresses
• Static Trunks or VLANs
• LACP settings
• Interface settings
• OSPF or IS-IS settings
• ARP entries or settings
Reload of the Target ACOS Device
In certain cases, the target ACOS device is automatically reloaded, but in other cases, reload is either
optional or is not allowed.
Table 4 lists the cases in which reload is automatic, optional, or not allowed.
page 133
TABLE 4 Reload of Target ACOS Device After Config-Sync

Status of Target ACOS
Admin Role Device* Target Config Reload?
Root or Super User Standby startup-config Automatic
(Read-Write) running-config Automatic
Active startup-config Optional†
Not reloaded by default

running-config Automatic
Partition Write Standby startup-config Not Allowed
running-config Not Allowed
Active startup-config Not Allowed
running-config Not Allowed
*. “Active” means the ACOS device is currently the active device for at least one HA group.
†. If the target ACOS device is not reloaded, the GUI Save button on the Standby ACOS device does not blink to
indicate unsaved changes. It is recommended to save the configuration if required to keep the running-config
before the next reboot.
An admin who is logged on with Root or Read-Write (Super Admin) privileges can synchronize for all
Role-Based Administration (RBA) partitions or for a specific partition.
An admin who is logged on with Partition Write privileges can synchronize only for the partition to
which the admin is assigned, and can only synchronize to the startup-config on the other device. The
with-reload and to-running-config options are not available to Partition Write admins.
Caveats
Before synchronizing the Active and Standby ACOS devices, verify that both are running the same soft-
ware version. HA configuration synchronization between two different software versions is not recom-
mended, since some configuration commands in the newer version might not be supported in the older
version.
The HA configuration synchronization process does not check user privileges on the Standby ACOS
device and will synchronize to it using read-only privileges. However, you must be logged onto the
Active ACOS device with configuration (read-write) access.
If the configuration includes Policy-based SLB (black/white lists), the time it takes for synchronization
depends on the size of the black/white-list file. This is because the synchronization process is blocked
until the files are transferred from active to standby.
Do not make other configuration changes to the Active or Standby ACOS device during synchroniza-
tion.
Data that is synchronized from a Standby ACOS device to an Active ACOS device is not available on the
Active ACOS device until that device is rebooted or the software is reloaded.
page 134
Performing HA Synchronization
To synchronize the ACOS devices in an HA configuration, use the CLI commands described below.
Using the GUI

1. Select Config Mode > System > HA.
2. Click on the Config Sync tab.
3. In the User and Password fields, enter the admin username and password for logging onto the
other ACOS device.
4. If partitions are configured on the ACOS device, select whether to synchronize all partitions or only
the currently selected partition.
5. Next to Operation, select the information to be copied to the other ACOS device:
• All – Copies all the following to the other ACOS device:
• Floating IP addresses
• IP NAT configuration
• Access control lists (ACLs)
• Health monitors
• Policy-based SLB (black/white lists)
• SLB
• FWLB
• GSLB
• Data files (see below)
The items listed above that appear in the configuration file are copied to the other ACOS
device’s running-config.
• Data Files – Copies only the SSL certificates and private-key files, aFleX files, External health
check files, and black/white-list files to the other ACOS device
• Running-config – Copies everything listed for the All option, except the data files, from this
ACOS device’s running-config
• Startup-config – Copies everything listed for the All option, except the data files, from this ACOS
device’s startup-config
6. Next to Peer Option, select the target for the synchronization:
• To Running-config – Copies the items selected in step 5 to the other ACOS device’s running-
config
• To Startup-config – Copies the items selected in step 5 to the other ACOS device’s startup-con-
fig
7. To reload the other ACOS device after synchronization, select With Reload. Otherwise, the other
ACOS device is not reloaded following the synchronization.
page 135
NOTE: In some cases, reload of the other ACOS device either is automatic or is
not allowed. See Table 4 on page 134.
8. In the Destination IP field, enter the IP address of the other ACOS device.
9. Click OK.
Using the CLI
The ha sync commands are available at the global configuration level of the CLI.
NOTE: The all-partitions and partition partition-name options are applicable on

ACOS devices that are configured for Role-Based Administration (RBA). .
To synchronize data files and the running-config, use the following command:
ha sync all
{to-startup-config [with-reload] |
to-running-config}
[all-partitions | partition partition-name]
ipaddr
NOTE: The ipaddr option specifies the IP address of the other ACOS device.
In some cases, reload of the other ACOS device either is automatic or is not allowed. See
Table 4 on page 134.
To synchronize the Active ACOS device’s startup-config to the Standby ACOS device’s startup-config or
running-config, without also synchronizing the data files, use the following command:
ha sync startup-config
to-running-config}
ipaddr
To synchronize the Active ACOS device’s running-config to the Standby ACOS device’s running-config
or startup-config, without also synchronizing the data files, use the following command:
ha sync running-config
to-running-config}
ipaddr
To synchronize the data files by copying the Active ACOS device’s data files to the Standby ACOS
device, use the following command:
page 136
Tip for Ensuring Fast HA Failover
ha sync data-files
ipaddr

You can use health checking of the upstream and downstream routers to help ensure rapid HA failover.
The time it takes for traffic to reconverge following HA failover can vary based on the network environ-
ment, and depends on the following:
• How fast the ARPs (typically, ARPs of the default gateways) are learned on the newly active
ACOS device
• How fast the MAC tables in the devices along the traffic paths are updated
To help reconvergence occur faster, you can create a real server configuration for each router, and use
an ICMP health monitor for checking the health of the gateways. The health checks keep the ARP
entries for the gateway routers active, which can help to reduce reconvergence time considerably.
In a typical SLB configuration that includes a client-side router and a server-side router, configure a real
server for each router.
To configure health checking of the gateway routers:
1. (Optional) Configure an ICMP health monitor.

For Layer 3 inline deployments, it is recommended to use very short values (1 second) for the inter-
val and timeout. (For examples of Layer 3 inline HA deployments for TCS, see the “Transparent
Cache Switching” chapter in the AX Series Application Delivery and Server Load Balancing Guide.)
2. Create an SLB real server configuration for each gateway. If you plan to use a custom ICMP health
monitor (previous step), apply the health monitor to the server.
Perform these steps on both ACOS devices in the HA pair.
NOTE: The ACOS device also has an HA gateway health checking feature. This
feature also uses ICMP health monitors. However, if you use the HA
gateway health checking feature, HA failover is triggered if a gateway
fails a health check. If you use real server configurations instead, as
shown in the following examples, HA failover is not triggered by a failed
health check.
page 137
CLI Example – IPv4

ACOS(config-health:monitor)#method icmp interval 1 timeout 1
ACOS(config)#slb server gateway-upstream 192.168.10.1
ACOS(config)#slb server gateway-downstream 10.10.10.1
To use the default ICMP health monitor instead, the configuration is even simpler:
ACOS(config)#slb server gateway-upstream 192.168.10.1

ACOS(config)#slb server gateway-downstream 10.10.10.1
CLI Example – IPv6

ACOS(config-health:monitor)#method icmp interval 1 timeout 1
ACOS(config)#slb server up-router 2309:e90::1
ACOS(config)#slb server down-router 2309:e90::3
To use the default ICMP health monitor:
ACOS(config)#slb server up-router 2309:e90::1

ACOS(config)#slb server down-router 2309:e90::3
page 138
HA To VRRP-A Migration
The current software allows you to automatically migrate your existing High Availability (HA) configura-
tion to Virtual Router Redundancy Protocol (VRRP-A) configuration.
VRRP-A is the A10 Thunder Series and the AX Series implementation of the High Availability protocol
that is completely different from the industry-standard implementation of Virtual Router Redundancy
Protocol (VRRP). For purposes of operational familiarity, it borrows concepts from VRRP, but is signifi-
cantly different from VRRP. VRRP-A will not inter-operate with VRRP.
In this release, VRRP-A, a High Availability (HA) implementation, is mutually exclusive of the HA feature
and is configured separately and not as part of the HA functionality.
Manual configurations can be time consuming and tedious. This automated migration script saves you
time and effort.
In the HA scenario, one ACOS device serves as an “Active” device, while a second ACOS device serves
as a “Standby” device. Issue the vrrp-a ha-migration command on the Active and the Standby ACOS
device to automatically convert the existing HA configuration into a VRRP-A configuration. Once your
conversion is complete, VRRP-A will be operational after you reload both devices.
NOTE: The vrrp-a ha-migration command must be run independently on both

the Active and the Standby devices.
Follow these steps before you launch the migration script.
• Back up your current configuration. Though the script creates its own backup of the existing con-
figuration, it is prudent that you create a copy of the existing configuration. Store this file in case
you need to revert to your original configuration.
• Before you run the vrrp-a ha-migration command on the ACOS devices, review your existing HA
configuration file to address any exceptions that will cause the automatic migration script to fail.
Address these exceptions by manually upgrading your HA configuration or by deleting these con-
figuration statements from your configuration file before migrating your configuration. For a list
of conversion exceptions, review, “Migration Exceptions” on page 140. For high-level details on
HA and VRRP-A, refer to Table 5 on page 140. For details on commands migrated from HA to
VRRP-A, refer to Table 6 on page 142.
Once the conversion process from HA to VRRP-A is complete, if you wish to revert to your HA configu-
ration, use the vrrp-a ha-migration-restore command.
page 139
Migration Exceptions
During the migration process, some conditions will cause the migration command to fail. An HA config-
uration that does not contain any of the following HA configuration exceptions will result in a success-
ful conversion to VRRP-A. Issue the migration command only after you have removed or manually
upgraded the following HA configuration statements.
NOTE: When you launch the migration script, it will pre-check your HA configu-
ration to ensure that no HA configuration exceptions exist. If it encoun-
ters exceptions, the script will quit automatically without conversion to
VRRP-A.
Assuming no Virtual Chassis (VCS) has been configured, the following exceptions will apply that will
cause the HA migration command to fail:
• RBA partitions are encountered.
• Forward-L4-Packet-on-Standby is detected.
• L2 Inline Mode is detected. This includes support for HA Inline Mode (preferred port), HA restart-
time, and HA restart-port-list.
• L3 Inline Mode is detected. This includes support for HA L3 Inline Mode and HA OSPF Inline
mode.
• HA Parameters for Real Servers are detected. This includes support for HA priority cost.
• HA Parameters for Real Ports are detected.
• Firewall Load Balancing (FWLB) is detected.
NOTE: If one of the seven exceptions defined above occur, a warning message
will be displayed on your screen and you will be asked to manually
migrate your configuration.
Differences between HA and VRRP-A

To understand the configuration differences between HA and VRRP-A at a high-level, refer to the follow-
ing table.
TABLE 5 Implementation Differences between HA and VRRP-A

Configuration High Availability VRRP-A
HA Connection Mirror You must indicate an IP address The peer IP address is automati-
for an HA Connection Mirror (ha cally learned.
conn-mirror ip 1.1.1.1).
page 140
TABLE 5 Implementation Differences between HA and VRRP-A

Configuration High Availability VRRP-A
Port Tracking Provides server and router inter- Tracking is based on priority.
face tracking.
Command Support HA supports the following com- VRRP-A does not support these
mands: commands.
ha inline-mode
ha l3-inline-mode
ha restart-port-list port-type
(available only for HA inline mode)
ha restart-time milliseconds
(available only for HA inline mode)
ospf-inline vlan vlan-id

(available only for HA L3-inline
mode)
During the process of migration, your HA commands will be converted in the following manner:
NOTE: HA commands that do not have an equivalent command in VRRP-A will

cause the migration script to exit. These commands are shown as “Not
supported” under VRRP-A in the following table.
page 141
TABLE 6 Actual HA to VRRP-A Conversion

HA VRRP-A Migration Example
Global Parameters
ha id {1|2} [set-id num] vrrp-a set-id num ha id 1 set-id 1
vrrp-a set-id 1
vrrp-a device-id 1
ha group id num priority num vrrp-a vrid num ha group 1 priority 100
priority num vrrp-a vrid 1
priority 100
floating-ip ip-add ha-group num vrrp-a vrid num floating-ip 1.1.1.10 ha-group 1
floating-ip num vrrp-a vrid 1
floating-ip 1.1.1.10
ha interface ethernet port-num vrrp-a interface ethernet port-num ha interface
[router-interface | server-interface | [router-interface | server interface |
both] [no-heartbeat | vlan vlan-id] both] [no-heartbeat | vlan vlan-id] ha interface ethernet 1 vlan 2
The VRRP-A tracking options are ha interface ethernet 1 no-heart-

created per VRID. The migration beat
script will place the configuration
under each VRID. If an interface is ha interface ethernet 1 server-inter-
under a trunk, only the trunk will be face
tracked.
ha interface ethernet 1 router-inter-
face
vrrp-a interface ethernet 1 vlan 2
vrrp-a interface ethernet 1 no-heart-

beat
vrrp-a interface ethernet 1 server-

interface
vrrp-a interface ethernet 1 router-

interface
page 142

ha check vlan vlan-id timeout sec- track options ha check vlan 2 timeout 20
onds
vlan vlan-id timeout seconds prior- vrrp-a vrid 1
ity-cost default
tracking-options
vlan 2 timeout 20 priority 5

ha check gateway ipaddr gateway ipaddr priority-cost default ha check gateway 1.1.1.1
vrrp-a vrid 1
tracking-options
gateway 1.1.1.1 priority 5

ha conn-mirror ip ipaddr IP address is learned automatically None
ha preemption enable preempt-mode disable ha preemption-enable
vrrp-a vrid 1
preempt-mode disable
ha time-interval 100-ms-units vrrp-a hello-interval 100-ms-units ha time-interval 5
vrrp-a hello-interval 5
ha timeout-retry-count num vrrp-a dead-timer num ha timeout-retry-count 10
vrrp-a dead-timer 10
ha arp-retry num vrrp-a arp-retry num ha arp-retry 5
vrrp-a arp-retry 5
ha forward-l4-packet-on-standby Not supported None
Global Parameters for L2 Inline Mode
ha inline-mode [preferred-port] Not supported None
ha restart-time 100-msec-units Not supported None
ha restart-port-list Not supported None
Global Parameters for L3 Inline Mode
ha l3-inline-mode Not supported None
ha ospf-inline vlan vlan-id Not supported None
ha link-event-delay Not supported ha link-event-delay 20
vrrp-a track-event-delay 20
Parameters for Virtual Servers (appear under slb virtual-server)
page 143

ha-group group-id vrid group-id slb virtual-server v1 1.1.1.3
ha-group 1
vrid 1
ha-dynamic server-weight It will not be changed Configure a server and configure
the server weight.
Parameters for Virtual Service
ha-conn-mirror It will not be changed ha-conn-mirror
Parameters for Real Servers
ha-priority-cost weight ha-group Not supported None
group-id
Parameters for Real Ports
ha-group group-id Not supported None
Parameters for FWLB
ha-priority-cost weight ha-group Not supported None
group-id
Parameters for IP NAT
Options with ip nat pool, ipv6 nat ip nat pool pool-name starting- ip nat pool abc 1.1.1.20 1.1.1.30
pool, or ip nat ip-nat pool-address ending- netmask /24 ha-group-id 1
ip-nat pool-address netmask
pool-mask vrid vrid-num ip nat pool abc 1.1.1.20 1.1.1.30
netmask /24 vrid 1
Parameters for IP Routes
ha check route des/mask priority- This appears under track options: ha check route 1.1.1.1 /24 gateway
cost weight [gateway ip addr | ipv6 2.2.2.2 priority-cost 10
addr] [protocol route dest/mask priority-cost
weight [gateway ipaddr | ipv6addr] vrrp-a vrid 1
{static|dynamic}][distance num]
[protocol {static | dynamic}][dis-
tance num] tracking-options
route 1.1.1.0 255.255.255.0

gateway 2.2.2.2 priority-cost
10
Migrating from HA to VRRP-A

Using the CLI
To migrate your existing HA configuration into VRRP-A, follow these steps. Begin with migrating your
Standby ACOS device first before your Active ACOS device:
page 144
3. From the configuration mode, execute the vrrp-a ha-migration command on the ACOS device designated
as the Standby device:
vrrp-a ha-migration
In case the migration script encounters any configuration scenarios that it cannot handle, it will
quit.
NOTE: Your current configuration will be changed.
Refer to “Migration Exceptions” on page 140 or Table 6 on page 142. You must remove the excep-
tions (HA configuration statements) before reissuing the vrrp-a ha-migration command.
4. From the privileged exec mode, “ACOS-Active#, reload the standby ACOS device. Issue the reload com-
mand. You cannot issue this command in configuration mode.
NOTE: Make sure that you do not issue the write-memory command. Before the
ACOS device commences the reload, be sure to say no to the question:
System configuration has been modified. Save? [yes/no]:
When it reboots successfully, this device will automatically be placed in standby state. For it to
become the active device, from the global configuration mode, issue the no vrrp-a force-self-
standby command.
Your HA configuration on the Standby device is now complete. Repeat the same steps on the
Active device.
Once both the Active and the Standby ACOS devices are reloaded, verify that you are successfully
able to use VRRP-A as opposed to HA and that everything is working as expected.
5. To check your VRRP-A configuration, issue the show vrrp-a command or the show vrrp-a config com-
mand. See if you can successfully access other VIPs.
page 145
Configuration Example
The following example shows successful completion of the migration command on an Active ACOS
device:
ACOS-Active(config)#vrrp-a ha-migration
ACOS boots from hard disk primary. VRRP-A migration only effects on hard disk primary.
Migrate from HA to VRRP-A therein? (y/n) y
HA Migration Starts...
89 lines of configuration are processed
Replacing old config file with new config file.
Configure file has been replaced!
HA configuration has been replaced by VRRP-A configuration! Please reload the system to
finalize the migration!
Warning: After reloading, all vrids in all partitions will be forced standby!
Please manually remove forced-standby setting with command: no vrrp-a force-self-standby
all-partitions
Before you reload the ACOS device, check your running configuration to see that no VRRP-
A configuration exists:
ACOS-Active(config)#show running | sec vrrp-a
ACOS-Active(config)#
From the privileged EXEC level, reload your ACOS device:
ACOS#reload
System configuration has been modified. Save? [yes/no]:no
Do you wish to proceed with reload? [yes/no]:yes
AX is reloading now. Please wait....

AX has reloaded successfully.
ACOS(LOADING)#
After you reload, view your running configuration to see that VRRP-A has been configured on your
ACOS device
ACOS#show running | sec vrrp-a

vrrp-a device-id 2
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid default
tracking-options
interface ethernet 3 priority-cost 15
page 146
vrrp-a vrid 1
priority 100
tracking-options
vrrp-a interface ethernet 1 router-interface
vrrp-a interface ethernet 2 server-interface no-heartbeat
vrrp-a interface ethernet 3 vlan 100
Reverting to HA from VRRP-A

To restore an existing HA configuration, you can revert from VRRP-A configuration using the vrrp-a ha-
migration-restore command. This command will only work if you have previously migrated your HA
configuration to VRRP-A using the migration script.
Using the CLI
To replace the VRRP-A configuration with an HA configuration, use the following command:
vrrp-a ha-migration-restore
This command reboots your system to restore your HA configuration. For example:
ACOS-Active(config)# vrrp-a ha-migration-restore

ACOS boots from hard disk primary. Migration restore only effects on hard disk primary.
Trying to find backup config file to replace current config file.
The backup files is found.
Proceed to replace current config file? (y/n) y
System has been successfully restored! Please reload system!
page 147
page 148
VRRP-A CLI Commands
This chapter describes the commands used to configure VRRP-A high availability.
• “VRRP-A Global Configuration Mode Commands” on page 150
• “VRRP-A Common Configuration Mode Commands” on page 160
• “VRRP-A VRID Configuration Commands” on page 167
• “VRRP-A Blade Parameter Configuration Commands” on page 169
• “VRRP-A Show Commands” on page 172
page 149
VRRP-A Global Configuration Mode Commands

This section describes the VRRP-A commands that are available from Global Configuration mode.
• vrrp-a common
• vrrp-a fail-over-policy-template
• vrrp-a force-self-standby
• vrrp-a force-self-standby-persistent
• vrrp-a interface
• vrrp-a l2-inline-peer-ip
• vrrp-a l3-inline-mode
• vrrp-a ospf-inline
• vrrp-a peer-group
• vrrp-a preferred-session-sync-port ethernet
• vrrp-a restart-port-list
• vrrp-a vrid
• vrrp-a vrid-lead
vrrp-a common
Description Enter VRRP-A configuration mode, where additional VRRP-A commands are available.
For more information about these additional commands, see “VRRP-A Common
Configuration Mode Commands” on page 160.
Syntax vrrp-a common
Mode Global configuration mode
vrrp-a fail-over-policy-template
Description Create a failover policy template for VRRP-A. The template provides a mechanism for event
tracking and can enable a policy-based failover to occur. Using a template, assign weight-
related values per event that will be reduced from the fixed total weight of an ACOS device
of 65534. The weight of a device can determine whether the device will serve as an Active or
page 150
Standby device. This command allows you to specify the weight value per event that may
cause a device to failover when the event occurs.
Syntax [no] vrrp-a fail-over-policy-template template-name
Replace template-name with the name that you are assigning for the VRRP-A failover
policy template. This template must be associated to a particular VRID to take effect.
page 151
This command changes the CLI to the configuration level for the specified failover-policy template,
where the following commands are available::
Command Description
[no] Specify the IP Address of an IPv4 or IPv6 default gateway that has also
gateway gateway-IP-address been configured as a real server, such as ACOS(config)#slb server GW1
weight value or ACOS(config)#cgnv6 server GW1. VRRP-A periodically tests the sta-
tus of the IP. If a gateway stops responding, VRRP-A reduces the weight
for the VRID. The weight value to subtract can be specified individually for
each gateway’s IP address that you configure in the tracking events list.
[no] interface Specify a weight for each interface that you are planning to track. If the link
interface-type goes down on an Ethernet data port, VRRP-A reduces the weight for the
interface-number VRID. The weight value to subtract can be specified individually for each
weight value Ethernet data port.
[no] route Indicate the IPv4 or IPv6 route that you wish to track. If the route matching
route-number subnet the specified options is not in the data route table, VRRP-A reduces the
weight value weight for the VRID.
[distance num]
[gateway ip]
The distance parameter specifies the route’s administrative distance; if
[protocol
not specified, any distance is matched.
{any | static | dynamic}]
The gateway parameter matches the route’s next-hop gateway.
The protocol parameter matches the route protocol:
• any - match any routing protocol (default)

• static - match only user-specified static routes
• dynamic - match only routes added by dynamic routing protocols (for
example, OSPF)
[no] trunk trunk-id Indicate the trunk you wish to track. If the trunk or individual ports in the
weight value trunk go down, VRRP-A reduces the weight for the VRID. The weight value
per-port-weight value to subtract can be specified for the trunk and for individual ports within the
trunk.
[no] vlan vlan-id Indicate the VLAN you wish to track. If VRRP-A stops detecting traffic on a
timeout timeout-value VLAN, VRRP-A reduces the weight for the VRID. The weight value to sub-
weight value tract can be specified individually for each VLAN.
Default None
Usage Use this command on any ACOS device to indicate weight values per tracked event via a
failover policy template.
Example The following commands help you to create a template called “template1” and specify
events that will reduce the weight of the VRID:
ACOS(config)# vrrp-a fail-over-policy-template template1

ACOS(config-fail-over-policy-template:tem...)# interface ethernet 1
page 152
weight 200
ACOS(config-fail-over-policy-template:tem...)# gateway 20.20.20.20
weight 200
ACOS(config-fail-over-policy-template:tem...)# vlan 10 timeout 2
weight 200
ACOS(config-fail-over-policy-template:tem...)# route 20.20.20.0 /24
weight 200
ACOS(config-fail-over-policy-template:tem...)# trunk 1 weight 200
vrrp-a force-self-standby
Description Force the ACOS device to change from active to standby or backup.
Syntax [no] vrrp-a force-self-standby [all-partitions | vrid num]

{enable | disable}
Parameter Description
all-partitions Causes all partitions to change to standby state.
vrid num Causes only the specified VRID to change to standby state.
enable Enable the forced standby.
disable Disable the forced standby.
Default N/A
Usage This command provides a simple method to force a failover, without the need to change
VRRP-A configuration settings.
Example Enable the forced standby of VRID 3:
ACOS(config)# vrrp-a force-self-standby vrid 3 enable

Doing so may cause some of the VRID(s) to become inactive in the
whole vrrp-a set.
whole vrrp-a set; make sure you verify that an active device will be
available after performing this operation. [yes/no]:
page 153
vrrp-a force-self-standby-persistent
Description Force a specific VRID to change from active to standby or backup, and remain in backup state
even after the device is reloaded.
Syntax [no] vrrp-a force-self-standby-persistent [vrid num]
Replace num with the VRID number whose state you want to change.
Default N/A
Usage This command provides a simple method to force a failover, without the need to change
VRRP-A configuration settings.
Example Enable the persistent forced standby of VRID 3:
ACOS(config)# vrrp-a force-self-standby-persistent vrid 3

whole vrrp-a set.
whole vrrp-a set; make sure you verify that an active device will be
available after performing this operation. [yes/no]:
page 154
vrrp-a interface
Description Configure a VRRP-A interface.
Syntax [no] vrrp-a interface {ethernet port-num | trunk trunk-num}
port-num Configures the specified interface as the VRRP-A inter-
face.
trunk-num Configures the specified trunk interface as the VRRP-A
interface.
This command places you in a configuration sub-mode where you can configure the type
and state of the interface using the following commands:
Command Description
both Configures the interface so that both real servers and
upstream routers can be reached through this interface.
Note: This is an inherited attribute for legacy High Avail-

ability (HA) configuration. Do not use this for new VRRP-A
configuration.
no-heartbeat Prevents heartbeat packets from being sent out on this
interface.
router-interface Configures the interface so that upstream routers (and
ultimately, clients) can be reached through the interface.
server-interface Configure the interface so that real servers can be
reached through the interface.
vlan vlan-id Configures the interface to be part of the specified VLAN.
Mode All up data interfaces within a partition are VRRP-A interfaces for that partition. If an interface
is a tagged member of multiple VLANs, only the VLAN that has the lowest-numbered IP
address for the interface is used as an VRRP-A interface.
Usage This command is valid only in the shared partition. However, the interface(s) specified by the
command are used by all partitions.
Example Configure ethernet interface 3 as the VRRP-A interface, and configure the interface so that
real servers can be reached:
ACOS(config)# vrrp-a interface ethernet 3

ACOS(config-ethernet:3)# server-interface
page 155
vrrp-a l2-inline-peer-ip
Description Configure a peer IP address in Layer 2 inline mode HA deployments.
ACOS devices require a connection mirror IP address to be configured in Layer 2 inline mode
VRRP-A deployments. A connection mirror interface is a unicast IP address on the peer ACOS
device in the VRRP-A set. This peer IP address is optional in earlier releases but usually is
configured anyway for session synchronization purposes. Specifying a connection mirror IP
address is mandatory for proper operation of ACOS devices in Layer 2 Inline mode VRRP-A.
The connection mirror IP address is used for session synchronization (also called “connection
mirroring”). Until a connection mirror IP address is specified, the ACOS device remains in
Standby state.
If a connection mirror IP address is not configured, a log message such as the following is
generated every 5 minutes:
Sep 01 2012 03:01:30 Warning [HA]:HA Peer IP is not configured. Peer

IP is required in Inline Mode.
Syntax [no] vrrp-a l2-inline-peer-ip ip-address ipaddr
Default Not configured
Example Configure 192.168.1.1 as the peer IP address.
ACOS(config)# vrrp-a l2-inline-peer-ip ip-address 192.168.1.1
vrrp-a l3-inline-mode
Description Enable Layer 3 Inline mode.
Syntax [no] vrrp-a l3-inline-mode
Default Not configured
Example Enable Layer 3 inline mode.
ACOS(config)# vrrp-a l3-inline-mode
page 156
vrrp-a ospf-inline
Description Enable OSPF inline mode.
Syntax [no] vrrp-a ospf-inline vlan vlan-id
Replace vlan-id (1-4094) with the VLAN for which you do not want to filter OSPF packets.
Default Not enabled
Example Enable OSPF inline mode and do not filter packets on VLAN 13.
ACOS(config)# vrrp-a ospf-inline vlan 13
vrrp-a peer-group
Description Configure a VRRP-A peer group. This allows you to configure unicast IP/IPv6 addresses
through a layer 3 link (Layer 3 inline mode). Heartbeat messages are routed to the destina-
tion.
Syntax [no] vrrp-a peer-group
This command places you in a sub-configuration mode, where you can configure the peer
address with the peer command:
[no] peer {ipv4-address | ipv6-address}
Replace ipv4-address or ipv6-address with the appropriate IP address of the peer.
Example The following example shows how to configure a peer group:
ACOS(config)# vrrp-a peer-group

ACOS(config-peer-group)# peer 192.168.10.10
ACOS(config-peer-group)# peer 30.20.10.6
ACOS(config-peer-group)# peer 2607:f0d0:1002:51::4
vrrp-a preferred-session-sync-port ethernet

Description Specify the Ethernet interfaces on which to receive synchronized sessions.
Syntax [no] vrrp-a preferred-session-sync-port {

ethernet port-num [vlan vlan-id]
page 157
trunk trunk-num [vlan vlan-id]

}
port-num Configure the specified ethernet port to receive sync sessions.
trunk-num Configure the specified trunk port to receive sync sessions.
vlan-id If your interface is part of a VLAN, specify the VLAN ID.
Default The default behavior is for VRRP-A (on the backup device) to automatically select the Ether-
net interface on which to receive sync sessions.
Introduced in Release 2.7.0
Example Configure trunk 3 to receive sync sessions.
ACOS(config)# vrrp-a preferred-session-sync-port trunk 3
vrrp-a restart-port-list
Description Causes the ports on the standby system to be restarted after the transition from the standby
mode to active mode.
Beginning with release 4.0.1, you can configure the restart time using “restart-time” on
page 166.
Syntax [no] vrrp-a restart-port-list
This command places you in a sub-configuration mode where the following commands are
available:
Command Description
ethernet {port | Configure one or many VRRP-A interface ports to restart.
range_of_ports}
vrid num Enters a VRID sub-configuration mode where the ethernet
port or range is also available:
ACOS(config-restart-port-list)# vrid 1
ACOS(config-restart-port-list-vrid:1)#
NOTE: You must omit at least one port connecting the ACOS devices from the restart port-
list, and heartbeat messages must be enabled on the port. This is so that heartbeat
page 158
messages between the ACOS devices are maintained; otherwise, flapping might
occur.
Default Disabled. VRRP-A interfaces are not restarted after a failover.
Usage Use this command in inline mode configurations to cause the router connected to the ACOS
device to relearn MACs, including MACs for the real servers. Without this command, the
router might continue to try to reach the real servers through the ACOS device that becomes
the Standby ACOS device after a failover.
VRRP-A port restart toggles a specified set of ports on the formerly Active ACOS device by
disabling the ports, waiting for a specified number of milliseconds, then re-enabling the
ports. Toggling the ports causes the links to go down, which in turn causes the devices on
the other ends of the links to flush their learned MAC entries on the links. The devices then
can relearn MACs through links with the newly Active ACOS device.
vrrp-a vrid
Description Access the configuration level for a VRID.
Syntax [no] vrrp-a vrid num
Specify the VRID ID number. The number of VRIDs available for configuration differs in shared
versus L3V partitions.
This command changes the CLI to the configuration level for the specified VRID.
The commands available at this level are summarized in “VRRP-A VRID Configuration
Commands” on page 167.
vrrp-a vrid-lead
Description Configure a VRID as the “leader” VRID, with other VRIDs to operate as followers.
Syntax [no] vrrp-a vrid-lead name
Replace name with the name of the VRID.
This command changes the CLI to the configuration level for the specified VRID leader,
where the following command is available:
[no] partition [shared | name] vrid ID-num
page 159
VRRP-A Common Configuration Mode Commands
This command designates this VRID as the leader for a specific partition.
Default Not set
Usage For the leader VRID only, you can configure all capabilities, such as configuring the failover
policy template, the preempt mode, priority, and tracking options. For follower VRIDs, you
can only configure Floating IP Addresses.
If you try to remove a VRID that is configured as a lead VRID and that has other VRIDs that
follow it, you will not be allowed to remove it. You must remove the VRIDs that are
configured as followers before you remove the lead VRID.
Example The following command configures a VRID lead in the shared partition:
ACOS(config)# vrrp-a vrid-lead lead1

ACOS(config-vrid-lead)# partition shared vrid 1

This section describes the commands available in VRRP-A common configuration mode.
• arp-retry
• dead-timer
• device-id
• disable-default-vrid
• enable
• forward-l4-packet-on-standby
• get-ready-time
• hello-interval
• hostid-append-to-vrid
• inline-mode
• preemption-delay
• restart-time
• set-id
• track-event-delay
page 160
VRRP-A common configuration mode is accessed by entering the vrrp-a common command:
ACOS(config)#vrrp-a common
arp-retry
Description Change the number of additional gratuitous ARPs, in addition to the first one, an ACOS
device sends after transitioning from Standby to Active. These ARPs are sent at intervals of
500 milliseconds.
Syntax [no] arp-retry num
Replace num with the number of additional gratuitous ARPs to send, after sending the first
one.
Default VRRP-A sends 4 additional gratuitous ARPs by default, for a total of 5.
Mode VRRP-A common configuration mode
Example Send 3 additional gratuitous ARPs when the system becomes active.

ACOS(config-common)# arp-retry 3
dead-timer
Description Change the number of hello intervals during which a standby device will wait for a hello
message from the Active VRRP-A device, before declaring the device to be down and begin-
ning failover.
Syntax [no] dead-timer num
Replace num with the maximum number of hello intervals to wait for a hello message.
Usage For information about the hello interval, see “hello-interval” on page 164.
Example Set the number of hello intervals to 25.

ACOS(config-common)# dead-timer 25
page 161
device-id
Description Specify the VRRP-A device ID of the device.
Syntax [no] device-id num

Replace num with the device ID.
Usage If aVCS is configured, use the same number as the aVCS device ID.
Example Set the device ID to 7.

ACOS(config-common)#device-id 7
disable
Description Disable VRRP-A on the device.
This command replaces the no enable command in release 4.0.
Syntax disable
Default By default, VRRP-A is disabled on any ACOS device.
Introduced in Release Release 4.0.1
Example Disable VRRP-A on the device.

ACOS(config-common)# disable
ACOS(config-common)#
disable-default-vrid
Description Disable the default VRID on the shared partition.
Syntax [no] disable-default-vrid
Default The default VRID is enabled by default.
Usage This command applies only to the shared partition.
Example Disable the default VRID on the shared partition.
page 162

ACOS(config-common)# disable-default-vrid
enable
Description Enable VRRP-A on the device.
Syntax enable
Default By default, VRRP-A is disabled on any ACOS device.
Example Enable VRRP-A on the device.

ACOS(config-common)# enable
ACOS-Active(config-common)#
forward-l4-packet-on-standby
Description Enable Layer 2/3 forwarding of Layer 4 traffic on the Standby ACOS device.
Syntax forward-l4-packet-on-standby
Default Disabled
Example Enable Layer 4 traffic forwarding on the device.

ACOS(config-common)# forward-l4-packet-on-standby
get-ready-time
Description Configure a delay time interval in 100 millisecond intervals for VRRP-A starting to run after
system start-up.
Syntax [no] get-ready-time 100-ms-units
Example Set the delay interval to 20 seconds (200 100-millisecond units).
page 163
ACOS(config-common)# get-ready-time 200
hello-interval
Description Change the interval at which the active device sends VRRP-A hello messages out its VRRP-A
interfaces.
Syntax [no] hello-interval 100-ms-units
Replace 100-ms-units with the number of 100 ms (milliseconds) intervals between each
hello message.
Example Set the hello interval to 4 (400 milliseconds).

ACOS(config-common)# hello-interval 4
hostid-append-to-vrid
Description This command enables you to identify the members of the VRRP-A set by serial number.
The show vrrp-a hostid command can be used to view the serial number of each device in
the VRRP-A set. By default, these serial numbers, which act as unique identifiers for all devices
in the VRRP-A set, are included in the VRRP-A hello packets for all VRIDs.
This command causes the device serial numbers to be sent in the VRRP-A hello packets for
the specified VRID only.
Syntax [no] hostid-append-to-vrid {default | vrid-num}
default VRID 0.
vrid-num A non-0 VRID.
Example Example configuration; device serial numbers should be included in the hello packets for
VRID 3 only:

ACOS(config-common)# hostid-append-to-vrid 3
Related Commands show vrrp-a hostid
page 164
inline-mode
Description Enable a specified ethernet port or trunk to be in Layer 2 inline hot standby mode.
Inline deployment allows you to insert a pair of ACOS devices into an existing network
without the need to reconfigure other devices in the network.
Inline support applies specifically to network topologies where inserting a pair of ACOS
switches would cause a Layer 2 loop.
Syntax [no] inline-mode {preferred-port port | preferred-trunk trunk}
port Ethernet port number.
trunk Trunk number.
Default Not configured.
Example Configure ethernet port 2 as the port to be used in the inline deployment:
ACOS(config)# vrrpa-a common

ACOS(config-common)# inline-mode preferred-port 2
preemption-delay
Description Configure a delay between VRRP-A configuration changes and the time that preemption will
take effect.
For more information about preemption delay, see “Preemption Delay” on page 17.
Syntax [no] preemption-delay 100-ms
Replace 100-ms with the number of 100-millisecond units to wait before having
preemption take effect.
Example Configure a preemption delay of 20 seconds (200 100-millisecond units).

ACOS(config-common)# preemption-delay 200
page 165
restart-time
Description The amount of time for ports on the standby system to be restarted after the transition from
the standby mode to active mode.
Syntax [no] restart-time seconds
Replace seconds with the number of seconds.
Usage This command applies only to VRRP-A interfaces in a restart port list configured by the vrrp-a
restart-port-list command.
set-id
Description Specify the VRRP-A set ID. When the set-id is “0”, the set-id is not configured. To return to the
default setting, use the no command.
Syntax [no] set-id num
Replace num with the set ID.
Default This is not set by default, by using the value 0.
Example Configure a set ID of 4.

ACOS(config-common)# set-id 4
track-event-delay
Description Change the delay waited by the ACOS device before beginning failover in response to prior-
ity changes.
Syntax [no] track-event-delay 100-ms-units
Replace 100-ms-units with the number of milliseconds (ms) to wait before beginning
failover.
Example Configure a delay of 2 seconds (20 100-millisecond units).

ACOS(config-common)# track-event-delay 20
page 166
VRRP-A VRID Configuration Commands

This section describes the VRRP-A VRID configuration commands.
• blade-parameters
• floating-ip
• follow
• preempt-mode
VRRP-A VRID configuration mode is accessed by entering the vrrp-a vrid command. For example:

ACOS(config-vrid:0)#
blade-parameters
Description Enter vBlade configuration mode.
Commands available for configuring blade parameters are described in “VRRP-A Blade
Parameter Configuration Commands” on page 169.
Syntax [no] blade-parameters
Mode VRRP-A VRID configuration mode
Example Enter Vblade configuration mode:

ACOS(config-vrid:0-blade-parameters)#
page 167
floating-ip
Description Specifies the IP addresses that downstream devices should use as their default IPv4 or IPv6
gateways. Regardless of which device is active for the VRID, downstream devices can reach
their default IPv4 or IPv6 gateway at the floating IP address.
Syntax [no] floating-ip {ipaddr | ipv6addr [ethernet id | trunk id | ve id]}
ipaddr The IPv4 address of the floating IP.
ipv6addr The IPv6 address of the floating IP.
• ethernet id - Ethernet interface. Visible in the shared parti-

tion.
• trunk id - Trunk interface. Visible in the shared partition.
• ve id - Virtual Ethernet interface. Visible in the shared par-
tition.
Default N/A
Example The following example configures 10.10.10.8 as the floating IP address for the VRID:

ACOS(config-vrid:0)# floating-ip 10.10.10.8
follow
Description Configure a follower VRID.
Before you can use this command, you must have configured a leader VRID using the vrrp-a
vrid-lead command.
See “Configuring a Leader and Follower VRID” on page 49 for more information about leader
and follower VRIDs.
NOTE: This command only appears in an L3V partition; it does not appear in the shared
partition.
Syntax [no] follow vrid-lead name
Replace name with the name of the leader VRID.
page 168
VRRP-A Blade Parameter Configuration Commands
Example This example shows how to follow the lead VRID called “lead1” from the shared partition “p1”
on VRID 1:
ACOS(config)# active-partition p1
Current active partition: p1
ACOS[p1](config-vrid:1)# follow vrid-lead lead1
preempt-mode
Description Disables ability for failovers to be caused by priority value changes, including manually
changed priority values, or any VRID tracking-option events.
Syntax [no] preempt-mode {disable | threshold num}
disable Disable preempt mode.
threshold num Controls whether failovers can be caused by priority value
changes.
The threshold specifies the maximum difference in priority

value that can exist between the active and standby devices
without failover occurring.
The default is 0.
Default Preemption is enabled by default.
Example The following example disables preemption:

ACOS(config-vrid:0)# preempt-mode disable

This section describes the VRRP-A blade parameter configuration commands.
• fail-over-policy-template
page 169
• priority
• tracking-options
VRRP-A Blade parameter configuration mode is accessed by entering the blade-parameters command.
For example:
ACOS(config)#vrrp-a vrid 0
ACOS(config-vrid:0)#blade-parameters
ACOS(config-vrid:0-blade-parameters)#
fail-over-policy-template
Description Apply the specified failover policy template to the VRID.
Syntax [no] fail-over-policy-template template-name
Replace template-name with the name of the template you want to apply to this VRID.
Failover policy templates are created with the vrrp-a fail-over-policy-template command.
Default N/A
Mode VRRP-A Blade parameter configuration mode
Usage This command is changed from release 4.0, where it was available under VRRP-A VRID config-
uration mode.
Example The following example applies the policy template named “template1” to VRID 0:
ACOS(config-vrid:0-blade-parameters)#fail-over-policy-template template1
priority
Description Specifies the preference of the device to become the active device for the VRID. The device
that has the highest priority value for the VRID becomes the active device for the VRID.
Syntax [no] priority num
Replace num with the desired priority.
Default 150
uration mode.
Example The following example sets the priority on VRID 0 to 200:
page 170
ACOS(config-vrid:0-blade-parameters)#priority 200
tracking-options
Description Accesses the configuration level for tracking options. Tracking options can dynamically
reduce the priority value used in dynamic failover.
For detailed information about event tracking, see “Events Tracked for Weight via the
Templates” on page 60.
Syntax [no] tracking-options
The supported tracking options are summarized in the table below.
Option Syntax Description

Gateway [no] gateway {ipaddr | ipv6addr} Configure tracking for the IPv4 or IPv6 default gate-
priority-cost num ways.
If a gateway fails, the specific num will be subtracted

from the priority on the VRID.
Interface [no] interface ethernet num Configure tracking for a specified interface.
priority-cost num
If the interface fails, the specific num will be subtracted
from the priority on the VRID.
Route [no] route {ipaddr | ipv6addr} Configure tracking for the specified route.
{/mask-length | subnet-mask}
[priority-cost num] If the specified route is missing, the specific num will
[distance num] be subtracted from the priority on the VRID.
[gateway ip]
[protocol
The distance parameter specifies the route’s admin-
{any | static | dynamic}]
istrative distance; if not specified, any distance is
matched.
The gateway parameter matches the route’s next-hop

gateway.
The protocol parameter matches the route protocol:
• any - match any routing protocol (default)

• static - match only user-specified static routes
• dynamic - match only routes added by dynamic
routing protocols (for example, OSPF)
page 171
VRRP-A Show Commands
Option Syntax Description

Trunk [no] trunk num priority-cost num Configure tracking for a specified trunk.
[per-port-pri num]
If the trunk or individual ports on the trunk fail, the
specified priority cost num will be subtracted from the
priority on the VRID.
The per-port-pri option tracks individual ports in

the trunk. The VRID’s priority is reduced by the per-
port-pri amount for each port that fails.
VLAN [no] vlan vlan-id Configure tracking for the specified VLAN.
timeout seconds
priority-cost num If traffic is no longer detected on the specified VLAN,
the specific num will be subtracted from the priority on
the VRID.
The timeout option configures the number of sec-

onds a VLAN can remain idle without triggering a
failover and priority cost reduction.
Default N/A
uration mode.
See “Configuration of Tracking Options” on page 45.
Example

This section describes the VRRP-A show commands. These commands are available at any level in the
CLI.
• show vrrp-a
• show vrrp-a all-partitions
• show vrrp-a fail-over-policy-template
• show vrrp-a hostid
page 172
• show vrrp-a mac
• show vrrp-a partition
• show vrrp-a setid-monitor
• show vrrp-a statistics
• show vrrp-a vrid-lead
show vrrp-a
Description Display VRRP-A information.
Syntax show vrrp-a [detail]
Mode All
Example The following example shows sample output for the show vrrp-a command.
ACOS# show vrrp-a

vrid 0
*
vrid 1
*
Example The following example shows sample output for the show vrrp-a detail command.
ACOS[corpa](config)# show vrrp-a detail

vrid 0
2 (Peer) Standby 65534 199 *
page 173
vrid 1
VRRP-A stats
Peer: 2, vrid 0
Heartbeat missed: 0
Peer: 2, vrid 1
Heartbeat missed: 0
Total packets received from peer: 468672
Conn Sync Pkts: Sent 0 Received 0

Conn Query Pkts: Sent 0 Received 0
Conn Sync Create Session Pkts: Sent 0 Received 0

Conn Sync Update Age Pkts: Sent 0 Received 0
Conn Sync Delete Session Pkts: Sent 0 Received 0
Conn Sync Create Persist Session Pkts: Sent 0 Received 0

Conn Sync Update Persist Age Pkts: Sent 0 Received 0
Conn Sync Delete Persist Session Pkts: Sent 0 Received 0
Conn Sync Update LSN RADIUS: Sent 0 Received 0
Conn Sync Update LSN Fullcone: Sent 0 Received 0


Dup device id: 0 Set id mismatch: 0

Version mismatch: 0 Error partition id: 0
Error port: 0 Error device id: 0
page 174
Peer IP[2]: 192.168.110.2

Vrid default tracking:
The following table describes the fields in the preceding command outputs:
Field Description
vrid Virtual router ID
Unit VRRP-A device ID.
“Local” indicates this ACOS device. “Peer” indicates another ACOS device in
the same VRRP-A set.
State VRRP-A state:
• Active
• Standby
Weight Current VRRP-A weight of this device.
Priority Current VRRP-A priority of this device.
vrid that is running VRID that is currently running on the partition.
VRRP-A Stats
The following information is listed for each VRRP-A peer device.

Peer Device ID of the peer device, and the VRID.
Port Data port that connects this device (the Local device) to the peer device.
The received counter indicates the number of Hello packets received for
the VRID from the peer on this port.
The missed counter indicates the number of Hello packets that were
expected for the VRID but did not arrive from the peer on this port.
Heartbeat missed Number of Hello packets that were expected for the VRID from the peer but
did not arrive on any port.
Total packets received from Total number of Hello packets received from the peer.
peer
Detail Fields
NOTE: The following fields appear only if you use the detail option.
Conn Sync Pkts Number of connection (session) synchronization packets sent by this parti-
tion for the VRID.
Conn Query Pkts Number of session synchronization query packets sent by this partition for
the VRID. Query packets are sent by the standby device to request session
information.
Conn Sync Create Session Pkts Number of creation packets for synchronized connections sent by this par-
tition for the VRID.
page 175
Field Description
Conn Sync Update Age Pkts Number of update packets for synchronized connections sent by this parti-
tion for the VRID.
Conn Sync Delete Session Pkts Number of delete packets for synchronized connections sent by this parti-
tion for the VRID.
Total packets sent for vrid N Total number of Hello packets sent by this partition for the VRID. Separate
counters are listed for each data port used by this partition to send the
packets.
Dup device ID Number of incoming hello packets that had the same device ID as this
device (the local device).
Set ID mismatch Number of incoming hello packets in which the VRRP-A set ID was differ-
ent from this device’s set ID.
Version mismatch Number of incoming hello packets that had a different VRRP-A software
version that the one running on this device.
Error port Number of hello messages received from a non-existent port.
Error device ID Number of hello messages received from an invalid device ID (any device
ID higher than 8).
Switch to active, switch to Number of times the partition transitioned to Active or Standby for the
standby VRID.
Peer IP IP address of the active peer for the VRID. The active peer is the device to
which this device (the local device) sends sessions for synchronization.
show vrrp-a all-partitions

Description View VRRP-A information for all partitions.
Syntax show vrrp-a all-partitions [active]
active Show only active VRIDs in the output.
Mode All
Usage This command is only valid in the shared partition.
Example Example output for this command:
ACOS# show vrrp-a all-partitions

Local device ID: 1
Partition vrid Active(P,W) Standby(P,W)
shared 0 2 (150,65534) 1 (11,65534)
a 0 1 (150,65534) 2 (150,65534)
page 176
The fields in this output are described in the following table:
Field Description
Local device ID Device ID of the device on which this command was executed.
Partition Name of the partition.
vrid VRID configured in the partition.
Active(P,W) Device number, priority (P), and weight (W) of the active device
in the VRID. For example:
2 (150,65534)
means the active device is device 2, the priority is 150, and the
weight is 65534.
Standby(P,W) Device number, priority (P), and weight (W) of the standby
device in the VRID.
show vrrp-a fail-over-policy-template

Description Display the VRRP-A fail-over policy template details.
Syntax show vrrp-a fail-over-policy-template [template_name]
Mode All
Example The following command shows VRRP-A information for all the fail-over policy templates:
ACOS(config)# show vrrp-a fail-over-policy-template

vrrp-a fail-over-policy-template interface
vrrp-a fail-over-policy-template trunk
trunk 1 priority-weight 200
vrrp-a fail-over-policy-template gateway
vrrp-a fail-over-policy-template route
route 4.4.4.0 255.255.255.0 weight 200
vrrp-a fail-over-policy-template vlan
trunk 1 priority-weight 200
route 20.20.20.0 255.255.255.0 weight 200
page 177
If you specify the name of the template, the show vrrp-a fail-over-policy
template command displays the contents of that template only.
show vrrp-a hostid

Description View the serial number or SoftAX UUID of all devices in the VRRP-A set.
Syntax show vrrp-a hostid
Mode All
Example Below is an example output for this command:
ACOS# show vrrp-a hostid

Vrrp-a Set id is 6
device 2 AX10A43012050032
device 3 AX10A83012060148
ACOS#
Related Commands hostid-append-to-vrid
show vrrp-a mac

Description Display the virtual MAC addresses of the VRIDs.
Syntax show vrrp-a mac
Mode All
Example The following command shows the virtual MAC addresses for the default VRID (0) and VRIDs
1 and 2:
ACOS# show vrrp-a mac

VRRP-A vrid MACs
0 021f.a000.0020
1 021f.a000.0021
2 021f.a000.0022
page 178
show vrrp-a partition

Description View VRRP-A information for all partitions.
Syntax show vrrp-a partition partition-name
partition- Show a specific partition’s VRID status.
name
Mode All
Usage This command is only valid in the shared partition.
Example Example output for this command:
ACOS# show vrrp-a partition shared

Local device ID: 1
Partition vrid Active(P,W) Standby(P,W)
shared 0 2 (150,65534) 1 (11,65534)
shared 13 2 (150,65534) 1 (11,65534)
The fields in this output are described in the following table:
Field Description
Local device ID Device ID of the device on which this command was executed.
Partition Name of the partition.
vrid VRID configured in the partition.
Active(P,W) Device number, priority (P), and weight (W) of the active device
in the VRID. For example:
2 (150,65534)
means the active device is device 2, the priority is 150, and the
weight is 65534.
Standby(P,W) Device number, priority (P), and weight (W) of the standby
device in the VRID.
show vrrp-a setid-monitor

Description Display the VRRP-A set information.
page 179
Syntax show vrrp-a setid-monitor
Mode All
Introduced in Release 2.7.0
show vrrp-a statistics

Description View VRRP-A statistics.
Syntax show vrrp-a statistics
Mode All
show vrrp-a vrid-lead

Description View the lead VRID configuration on the system.
Syntax show vrrp-a vrid-lead
Mode All
Example Below is an example output for this command:
ACOS# show vrrp-a vrid-lead

vrrp-a vrid-lead lead1
ACOS(NOLICENSE)#
This example shows that two lead VRIDs are configured; the “default-vrid-lead” on the shared
partition, and also “lead1” on the shared partition.
page 180
page 181
CONTACT US
1 a10networks.com/contact
ACOS 4.1.1-P11 CONFIGURING VRRP-A HIGH AVAILABILITY 29 MAY 2019

ACOS 4.1.1-P11 Configuring VRRP-A High Availability: For A10 Thunder Series and AX™ Series 29 May 2019

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACOS 4.1.1-P11 Configuring VRRP-A High Availability: For A10 Thunder Series and AX™ Series 29 May 2019

Uploaded by

Copyright:

Available Formats

ACOS 4.1.

A10 NETWORKS INC. SOFTWARE LICENSE AND END USER AGREEMENT

Overview of VRRP-A ..................................................................................................................... 9

Displaying the Configure Sync State ..................................................................................................... 31

Deploying VRRP-A ...................................................................................................................... 35

VRRP-A Policy-Based Failover Template ................................................................................... 55

Verifying the Fail-Over Policy Template Configuration ............................................................... 65

High Availability ......................................................................................................................... 67

Configuration Items That Are Not Backed Up .............................................................................133

HA To VRRP-A Migration .......................................................................................................... 139

VRRP-A CLI Commands ........................................................................................................... 149

VRRP-A Blade Parameter Configuration Commands ...................................................... 169

This chapter provides an overview of VRRP-A high availability.

The following topics are covered:

• VRRP-A Active / Standby Device Selection

• VRRP-A and Floating IP Addresses

• VRRP-A and Configuration Synchronization

• VRRP-A and Session Synchronization

VRRP-A can provide redundancy for the following IP resources:

• Virtual server IP addresses (VIPs)

• Floating IP addresses used as default gateways by downstream devices

• IPv6 NAT pools

• IPv4 NAT pools

• Basic VRRP-A Configuration

• VRRP-A and Virtual Router IDs

• VRRP-A, Virtual Router IDs, and Partitions

Basic VRRP-A Configuration

FIGURE 1 Basic VRRP-A Configuration

The elements in this illustration are described in table below.

TABLE 1 VRRP-A Basic Configuration Elements

TABLE 1 VRRP-A Basic Configuration Elements

For more information, see:

• “Multicast Heartbeat Destination Addresses” on page 11

Multicast Heartbeat Destination Addresses

• IPv4 multicast address 224.0.0.210, MAC address 01:00:5e:00:00:D2

• IPv6 link-local multicast address FF02::D2, MAC address 33:33:00:00:00:D2

To configure multicast heartbeats, use the hello-interval command.

Unicast Hearbeat Destination Addresses

VRRP-A and Virtual Router IDs

FIGURE 2 VRRP-A Configuration with VRIDs

Leader and Follower VRIDs

VRID Virtual MAC Addresses

VRRP-A, Virtual Router IDs, and Partitions

FIGURE 3 VRRP-A Configuration with Partitions

VRRP-A Active / Standby Device Selection

• VRRP-A Active Device Selection Overview

• Event Tracking for Weight and Priority

• Track Event Delay

• Preemption and VRRP-A Failover Behavior with Preemption Disabled

• Active Device Selection Examples

VRRP-A Active Device Selection Overview

FIGURE 4 VRRP-A Device Selection Flowchart

• The weight assigned to an event.

• Priority value assigned as part of the VRRP-A deployment.

Event Tracking for Weight and Priority

Track Event Delay

Preemption and VRRP-A Failover Behavior with Preemption Disabled

NOTE: CLI configuration for disabling preemption mode is preempt-mode dis-

NOTE: Preemption delay is only valid when VRRP-A is configured in multi-active

Active Device Selection Examples

FIGURE 5 Selection of Active Device

FIGURE 6 Selection of Standby Device

FIGURE 7 Selection of New Standby Device