Vcs

CONFIGURING ACOS VIRTUAL CHASSIS SYSTEMS
A10 Thunder Series and AX Series

ACOS 4.1.0
16 February 2016
© 2016 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
The A10 logo, A10 Harmony, A10 Lightning, A10 Networks, A10 Thunder, aCloud, ACOS, Affinity, aFleX, aFlow, aGalaxy, aGAPI, aVCS, AX,
aXAPI, IDsentrie, IP-to-ID, SSL Insight, SSLi, Thunder, Thunder TPS, UASG, and vThunder are trademarks or registered trademarks of A10
Networks, Inc. in the United States and other countries. All other trademarks are property of their respective owners.
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 Networks, 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. sublicense, 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 aVCS ..................................................................................................................................................... 7

aVCS Prerequisites...............................................................................................................................................................7
Layer 2 Connectivity ............................................................................................................................................................................... 7
aVCS Image Location ............................................................................................................................................................................. 8
Memory Requirements for aVCS with Layer 3 Virtualization ......................................................................................... 8
aVCS Overview .....................................................................................................................................................................8
Virtual Chassis Management Interface (Floating IP Address) ......................................................................................10
aVCS Configuration Management ...............................................................................................................................................10
aVCS Software Version Management ........................................................................................................................................10
vMaster Election................................................................................................................................................................ 10
Understanding vMaster Election ..................................................................................................................................................11
aVCS Initial Deployment ................................................................................................................................................................................ 11
VRRP-A Active/Standby Device Selection ........................................................................................................................................... 11
aVCS and VRRP-A vMaster Selection ...................................................................................................................................................... 11
vMaster Election During Initial (First-Time) Deployment ...............................................................................................12
vMaster Election for Initial Deployment - Same Priority and Boot Time ......................................................................... 13
vMaster Election for Initial Deployment - Different Priorities, Same Boot Time .......................................................... 14
vMaster Election Using Dynamic Priority .................................................................................................................................14
vMaster Election and Heartbeat Messages ............................................................................................................................16
vMaster Election and Split Chassis ...............................................................................................................................................17
Forced vMaster Takeover ...................................................................................................................................................................18
aVCS Configuration Management and Synchronization ................................................................................... 18
aVCS Configuration Management ...............................................................................................................................................19
Automated Configuration Synchronization ...........................................................................................................................20
Manual Configuration Synchronization ....................................................................................................................................22
aVCS Software Image Synchronization .................................................................................................................... 23
Customizing the Virtual Chassis .................................................................................................................................. 24
Changing the System Time in a Virtual Chassis ...................................................................................................................24
Configurable aVCS Prompts .............................................................................................................................................................24
Deploying a Virtual Chassis .................................................................................................................................25

Initial aVCS Deployment ................................................................................................................................................ 25
Initial aVCS Deployment Overview .............................................................................................................................................26
Initial vMaster Configuration ...........................................................................................................................................................26
Initial vBlade Configuration ..............................................................................................................................................................27
First-Time Deployment Example ...................................................................................................................................................28
vMaster Initial Configuration Example .................................................................................................................................................. 28
vBlade Initial Configuration Example ..................................................................................................................................................... 32
page 3 | Document No.: 410-VCS-001 - 2/16/2016

A10 Thunder Series and AX Series—Configuring ACOS Virtual Chassis Systems
Contents
Forcing vMaster Takeover.............................................................................................................................................. 33

Forced vMaster Takeover Procedure ...........................................................................................................................................33
Temp-Priority Value ...............................................................................................................................................................................33
Determining a Device’s aVCS ID .................................................................................................................................. 34
Viewing aVCS Information............................................................................................................................................. 35
aVCS CLI-Session Management................................................................................................................................... 35
CLI Message for Commands That Affect Only the Local Device ...............................................................................36
Option To Configure aVCS Master Affinity to VRRP-A Active .......................................................................................37
Overview of aVCS Master Affinity to VRRP-A Active ..................................................................................................................... 37
aVCS Master Affinity to VRRP-A Active Configuration Example ............................................................................................ 38
aVCS Master Affinity to VRRP-A Active and vMaster Takeover ............................................................................................... 39
Option to Disable Syncing of SNMP sysContact OID .......................................................................................................39
vMaster Maintenance Mode ............................................................................................................................................................39
Adding a Device to a Virtual Chassis ................................................................................................................41

Overview of Adding a Device to a Virtual Chassis ................................................................................................ 41
Procedure for Adding a Device to a Virtual Chassis ............................................................................................. 42
Replacing a Device in a Virtual Chassis ...........................................................................................................45
Configuration Synchronization without Reload ..........................................................................................47

VRRP-A with aVCS Deployment Example ................................................................................................................................47
aVCS CLI Commands .............................................................................................................................................51

aVCS Operational Commands...................................................................................................................................... 52
device-context ........................................................................................................................................................................................... 52
vcs admin-session-connect ............................................................................................................................................................... 53
vcs disable .................................................................................................................................................................................................... 54
vcs enable ..................................................................................................................................................................................................... 54
vcs vMaster-maintenance .................................................................................................................................................................. 55
vcs vmaster-take-over ........................................................................................................................................................................... 56
aVCS Configuration Commands.................................................................................................................................. 57
vcs dead-interval ...................................................................................................................................................................................... 57
vcs debug ..................................................................................................................................................................................................... 58
vcs device ..................................................................................................................................................................................................... 58
vcs failure-retry-count ........................................................................................................................................................................... 60
vcs floating-ip ............................................................................................................................................................................................. 60
vcs floating-ipv6 ....................................................................................................................................................................................... 60
vcs force-wait-interval ........................................................................................................................................................................... 61
vcs multicast-ip ......................................................................................................................................................................................... 61
vcs multicast-ipv6 .................................................................................................................................................................................... 62
vcs multicast-port .................................................................................................................................................................................... 62
vcs reload ...................................................................................................................................................................................................... 62
vcs ssl-enable ............................................................................................................................................................................................. 63
vcs time-interval ....................................................................................................................................................................................... 63
vcs vmaster-maintenance .................................................................................................................................................................. 63
aVCS Show Commands .................................................................................................................................................. 64
Document No.: 410-VCS-001 - 2/16/2016 | page 4

Contents
show vcs debug ....................................................................................................................................................................................... 64

show vcs images ...................................................................................................................................................................................... 64
show vcs stat .............................................................................................................................................................................................. 65
show vcs summary ................................................................................................................................................................................. 78

Contents

Overview of aVCS
This chapter provides an overview of the ACOS Virtual Chassis System (aVCS).
The following topics are covered:
• aVCS Prerequisites
• aVCS Overview
• vMaster Election
• aVCS Configuration Management and Synchronization
• aVCS Software Image Synchronization
• Customizing the Virtual Chassis
aVCS Prerequisites
aVCS has the following prerequisite requirements:
• Layer 2 Connectivity
• aVCS Image Location
• Memory Requirements for aVCS with Layer 3 Virtualization
Layer 2 Connectivity
aVCS uses IP multicast. All ACOS devices in an aVCS virtual chassis must be in the same Layer 2 broadcast domain.
aVCS can operate across different geographic regions provided latency is low. VRRP-A session synchronization will be the
gating factor in terms of latency.
NOTE: When using aVCS with VRRP-A high availability, the aVCS management address (virtual
chassis’ floating IP address) should not be the same as a VRRP-A floating IP address of the
VRID.

aVCS Overview
aVCS Image Location

The aVCS-capable image must be installed in the same image area on each device. For example, install the image in the pri-
mary image area of the hard disk or solid state drive (SSD) on each device.
Memory Requirements for aVCS with Layer 3 Virtualization

Table 1 lists the amount of memory required in aVCS deployments that also use partitions with Layer 3 virtualization enabled.
TABLE 1 Memory Requirements for aVCS with Layer 3 Virtualization

Number of Partitions with Layer 3 Virtualization Memory Required*
32 partitions 6 GB memory
*. This assumes that the default system resource-usage settings are in effect. If you change the system resource-usage settings, the
memory requirements also may differ.
aVCS Overview
ACOS Virtual Chassis System (aVCS) enables you to manage a cluster of ACOS devices like a single, virtual chassis. One ACOS
device in the virtual chassis is the virtual master (vMaster). The other ACOS devices are virtual blades (vBlades) within the vir-
tual chassis, and are managed by the vMaster. As a controller for the vBlades, the vMaster provides centralized storage of the
entire ACOS device configuration. Any configuration changes from the vMaster are automatically propagated to the vBlades
aVCS, as a management tool, provides high availability functionality on the ACOS device with the help of VRRP-A across mul-
tiple ACOS devices.
Depending on the ACOS series model, with the help of VRRP-A, aVCS can support a maximum 7 additional blades. aVCS
requires that all devices in the same virtual switch have the same number of CPUs and are the same ACOS device model.
CAUTION: If you use the system-reset command to restore an ACOS device to its factory default
state, the command affects all ACOS devices in the virtual chassis. The command erases
any saved configuration profiles (including startup-config), as well as system files such
as SSL certificates and keys, aFleX policies, black/white lists, and system logs. The man-
agement IP address and admin-configured admin and enable passwords are also
removed. The only workaround is to reload the system from a saved configuration or
configure the device once again.
Before performing a system-reset, always create a system backup of the ACOS

device to allow you to be able to restore the ACOS device from the backup when neces-
sary.

aVCS Overview
In addition to individual device management and VCS configurations, the vMaster can also take care of the following opera-
tions on vBlades:
• Synchronize configurations
• Synchronize certificates
• Synchronize keys
• Synchronize aFleX policies
• Synchronize black/white lists
• Synchronize code versions
aVCS elects a single device within the virtual chassis as the vMaster for the chassis. The vMaster provides a single point of
control for all devices in the virtual chassis, as shown in Figure 1.
FIGURE 1 vMaster - Control Point for all Devices

vMaster Election
Virtual Chassis Management Interface (Floating IP Address)

The virtual chassis has a floating IP address. The virtual chassis’ floating IP address is the management address for the chassis.
To manage a virtual chassis, establish a management connection (for example, CLI or GUI) to the floating IP address.
When you connect to the virtual chassis’ management IP address, the connection goes to the vMaster You can make config-
uration changes only on the vMaster The vMaster automatically sends the changes to the vBlades.
If necessary, you can change the context of the management session to a specific vBlade. To change the management con-
text to the vBlade, use the vcs admin-session-connect command. The management session will change from the vMaster to
the specified vBlade.
For additional information, refer to “aVCS CLI-Session Management” on page 35.
aVCS Configuration Management

When you make a configuration change on the vMaster, the change is sent to the running-config on each vBlade.
For more information, see “aVCS Configuration Management and Synchronization” on page 18.
aVCS Software Version Management

The vMaster also ensures that each device in the virtual chassis is running the same software version.
For more information, see “aVCS Software Image Synchronization” on page 23.
vMaster Election
This section contains information about vMaster election in a virtual chassis and the factors that help determine which
device becomes the vMaster.
• Understanding vMaster Election
• vMaster Election During Initial (First-Time) Deployment
• vMaster Election Using Dynamic Priority
• vMaster Election and Heartbeat Messages
• vMaster Election and Split Chassis
• Forced vMaster Takeover

vMaster Election
Understanding vMaster Election

The devices in a virtual chassis use a vMaster election process to elect the vMaster for the virtual chassis.
To understand when a vMaster will take over as the Active device, it is necessary to understand different configuration sce-
narios that impact vMaster selection for aVCS, for VRRP-A, and for aVCS with VRRP-A:
• aVCS Initial Deployment
• VRRP-A Active/Standby Device Selection
• aVCS and VRRP-A vMaster Selection
aVCS Initial Deployment

For initial configuration, each ACOS device in the virtual chassis is assigned a VCS device id and VCS priority. An ACOS device
becomes the vMaster if it has the highest configured VCS priority among all the other ACOS devices in the virtual chassis. If
all ACOS devices in the aVCS configuration have the same VCS priority, then the ACOS device with the lowest device ID will
become the vMaster. In this configuration, each ACOS device will be a stand-alone device, without any active or standby
pairs.
To avoid having to configure each individual ACOS device separately, it is recommended that you configure only one ACOS
device that will serve as the vMaster then have the vMaster automatically configure the remaining ACOS devices in the vir-
tual chassis.
VRRP-A Active/Standby Device Selection

When VRRP-A is configured, the Active device selection is based on two factors, weight and priority, before electing an Active
device that will have several Standby devices ready to take over that role. An ACOS device will become an Active or Standby
device depending on the weight or priority of that device. The weight of an ACOS device will always take precedence over
the priority. If we have a higher weight but a lower priority, the ACOS device with the higher weight will be the Active. If the
weight of the devices are equal, the ACOS device with the higher priority will become the Active ACOS device. If the weight
and the priority of the devices are equal, the ACOS device will the lowest VRRP-A device ID will be the Active ACOS device.
As a ACOS device user, configure VRRP-A using VRRP-A failover templates and VRRP-A tracking options to adjust the weight
(using failover templates) or priority (using global tracking options) of an ACOS device and elect an Active device.
For more information, see Configuring VRRP-A High Availability.
aVCS and VRRP-A vMaster Selection

When aVCS and VRRP-A are configured to work in conjunction, all ACOS devices will be able to process traffic as an Active/
Standby pair, but these Active/Standby pairs will be configurable using a single ACOS device. The VRRP-A concept of having
an Active device and a Standby device to process traffic will remain the same. However, with aVCS, you can configure the
Active and Standby devices using a single ACOS device.
In summary, aVCS has its own configured priority and dynamic priority for electing the vMaster not for electing the Active or
Standby device. Use the show vcs statistics command to display the configured and dynamic priority.

vMaster Election
VRRP-A has its own weight and priority algorithm to determine which ACOS device is the Active or the Standby device, how-
ever, it does not elect the vMaster. Use the show vrrp-a command to display the weight and priority for the devices running
VRRP-A. For details on how a failover occurs based on weight or priority using a template, refer to “Event Tracking for Weight
or Priority” in Configuring VRRP-A High Availability. You can force a device to serve as a vMaster without dynamic election
by temporarily assigning it a higher priority.
vMaster Election During Initial (First-Time) Deployment

For initial virtual chassis deployment, the vMaster is elected based on one of the following parameters:
• Priority – The device with the highest configured aVCS priority is elected to be the vMaster. If you boot one of the
devices first and allow it to become the vMaster, the device remains the vMaster when the other devices join the vir-
tual chassis, even if the configured priority is higher on another device. This is due to the dynamic priority value
assigned by aVCS.
For more information, see “vMaster Election Using Dynamic Priority” on page 14.
• Device ID – If all devices have the same configured priority, the device with the lowest aVCS device ID is elected to be
the vMaster
For more information, see “vMaster Election for Initial Deployment - Same Priority and Boot Time” on page 13 and
“vMaster Election for Initial Deployment - Different Priorities, Same Boot Time” on page 14.

vMaster Election
vMaster Election for Initial Deployment - Same Priority and Boot Time
Figure 2 illustrates vMaster selection in a virtual chassis where all devices have the same priority and are booted up at the
same time. In this situation, the device with the lowest device ID (Device 1) is elected as the vMaster.
FIGURE 2 vMaster Election in Initial Deployment - Same Priority Value on each Device

vMaster Election
vMaster Election for Initial Deployment - Different Priorities, Same Boot Time
Figure 3 illustrates vMaster selection in a virtual chassis where each device has a different priority, and all devices are booted
up at the same time. In this situation, the device with the highest priority (Device 4) is elected as the vMaster.
FIGURE 3 vMaster Election in Initial Deployment - Different Priority Values Configured
vMaster Election Using Dynamic Priority

The configurable aVCS priority is a static value in each device’s configuration. After a virtual chassis becomes active, another
priority value, the dynamic priority, becomes the most important parameter when electing the vMaster The device with the
highest dynamic priority always becomes the vMaster
The dynamic priority adds stability to the virtual chassis, by consistently using the same device as vMaster whenever possi-
ble. Once a device becomes vMaster, its dynamic priority ensures that it will remain the vMaster, even if another device has a
higher configured priority. For example, if the vMaster becomes unavailable and a vBlade transitions to vMaster, the new
vMaster remains in control even if the previous vMaster rejoins the virtual chassis.
Figure 4 shows an example of how dynamic priority works. Device 3 was booted first, and even though other devices have
higher priority values, dynamic priority keeps Device 3 as the vMaster.

vMaster Election
FIGURE 4 vMaster Election with Dynamic Priority
Dynamic priority is not configurable. However, you can force a vBlade to become the vMaster. (See “Forced vMaster Take-
over” on page 18.)

vMaster Election
vMaster Election and Heartbeat Messages

At regular intervals (the heartbeat time interval), the vMaster sends heartbeat messages to each of the vBlades, to inform
them that the vMaster is still up, as shown in Figure 5.
FIGURE 5 Heartbeat Messages
If a vBlade does not receive a heartbeat message within a specified amount of time (heartbeat dead interval), the vBlade
changes its state from vBlade to vMaster-candidate, and engages in the vMaster election process with the other devices that
are still up.
The default heartbeat time is 3 seconds. The default heartbeat dead interval is 10 seconds. Both parameters are configurable.

vMaster Election
vMaster Election and Split Chassis

If one or more vBlades lose contact with the vMaster, the vMaster remains in control for the vBlades that can still receive the
vMaster’s heartbeat messages. However, the other vBlades use the vMaster election process to elect a new vMaster This
results in two separate virtual chassis (a “split chassis”), as shown in Figure 6.
FIGURE 6 vMaster Election - Split Chassis
After the links among the disconnected devices are restored, the devices again use the vMaster election process to elect a
vMaster Generally, the vMaster that was in effect before the virtual chassis divided continues to be the vMaster after the vir-
tual chassis is rejoined, based on the device’s dynamic priority value. (See “vMaster Election Using Dynamic Priority” on
page 14.)

aVCS Configuration Management and Synchronization
Forced vMaster Takeover

You can force a vBlade to take over as vMaster, without changing the vMaster-election priority values configured on the
devices. For example, you can force a vBlade to take over the vMaster role, without changing the aVCS profiles of any of the
devices.
FIGURE 7 Forced vMaster Takeover
For a configuration example, see “Forcing vMaster Takeover” on page 33.

This section describes how configuration changes are handled within the virtual chassis.
• aVCS Configuration Management
• Automated Configuration Synchronization
• Manual Configuration Synchronization

aVCS Configuration Management

When you make a configuration change on the vMaster, the change is simultaneously propagated to the running configura-
tion on each vBlade. For example (Figure 8), if you create a new SLB server “RS1” on the vMaster, the vMaster sends the server
to the running configuration on each of the vBlades.
When the configuration on the vMaster is saved, the vMaster writes the contents of its running configuration to its startup
configuration and performs the same action on each vBlade in the virtual chassis.
FIGURE 8 aVCS Configuration Management
Once the virtual chassis is fully operational, all devices in the virtual chassis have exactly the same set of configuration pro-
files. This includes the startup configuration and any custom configuration profiles.

Automated Configuration Synchronization

aVCS automatically synchronizes configuration information within the virtual chassis. Configuration changes are synchro-
nized in real-time as they occur.
All configuration changes are synchronized, even changes to device-specific parameters such as hostnames and IP
addresses. aVCS configuration synchronization ensures that each device in the virtual chassis has a complete set of configu-
ration information for itself and for each of the other devices. For example, configuration synchronization ensures that each
device has the complete aVCS configuration for the virtual chassis (Figure 9).
FIGURE 9 aVCS Device-Specific Parameters
In this example, the device-specific portions of the configuration are shown in bold type for each device.
NOTE: For brevity, some commands are omitted from the illustration. For example, in a working
configuration, the vcs enable command normally would appear in the configuration
for each device, under the vrrp-a commands, and the enable command would
appear among the aVCS commands for each device.

Common parameters, such as SLB parameters, are shared by all devices in the virtual chassis and do not have a device ID
(Figure 10).
FIGURE 10 Common Parameters

Interface parameters are unique to each device and include the aVCS device number (Figure 11).
FIGURE 11 Interface Parameters
This example shows the configuration for each device’s management IP address and an Ethernet interface. VLANs, Virtual
Ethernet (VE) interfaces, and trunks also include the aVCS device ID.
Manual Configuration Synchronization

Optionally, you can manually synchronize the VRRP-A configuration to specific devices. For more information on manual syn-
chronization using VRRP-A, refer to “Manually Synchronizing the Configuration” in Configuring VRRP-A High Availability.

aVCS Software Image Synchronization
aVCS Software Image Synchronization

In addition to the configuration repository, each device in the virtual chassis also has a software image repository. When a
new or rebooted device joins the virtual chassis as a vBlade, the device compares its running software image version with
the version running on the vMaster. If the version on the vMaster is newer, the vBlade downloads the image from the vMas-
ter, then reboots to place the image into effect.
When a vBlade upgrades in this way, the new image replaces the older image, in the same image area. For example, if the
vBlade boots the older image from the primary image area on the hard drive, the upgrade image downloaded from the
vMaster replaces the image in the primary image area.

Customizing the Virtual Chassis
Customizing the Virtual Chassis

This section contains information for customizing items related to aVCS configuration.
• Changing the System Time in a Virtual Chassis
• Configurable aVCS Prompts
Changing the System Time in a Virtual Chassis

If you need to set or change the system time on a vBlade in a virtual chassis, make sure to make the change on the vMaster,
not directly on the vBlade.
This is especially important if you need to set the time ahead on the vBlade. In this case, if you set the time ahead directly on
a vBlade, that device leaves, then rejoins the virtual chassis, and the change does not take effect.
Configurable aVCS Prompts

The CLI prompt can be configured to reflect the aVCS chassis device ID and status.
For more information, see “VRRP-A / aVCS Status in Command Prompt” in the Command Line Interface Reference.

Deploying a Virtual Chassis
This chapter describes how to deploy aVCS.
• Initial aVCS Deployment
• Forcing vMaster Takeover
• Determining a Device’s aVCS ID
• Viewing aVCS Information
• aVCS CLI-Session Management
Initial aVCS Deployment

This section describes how to deploy aVCS for the first time.
• Initial aVCS Deployment Overview
• Initial vBlade Configuration
• First-Time Deployment Example
CAUTION: Use this procedure only for first-time deployment of aVCS. If you are upgrading ACOS
devices on which aVCS is already configured, refer to the upgrade instructions included
with the release notes for your release.

Initial aVCS Deployment Overview

Table 2 summarizes the steps in the procedure for initial aVCS deployment.
TABLE 2 Summary of Steps for Initial aVCS Deployment

Step Description and Documentation
1 Complete aVCS configuration on the device that will be the vMaster.
See “Initial vMaster Configuration” on page 26 for more information.
2 After completing aVCS configuration on the vMaster, enable aVCS on the vBlades, and configure aVCS-related
parameters for the vBlades.
See “Initial vBlade Configuration” on page 27 for more information.
3 Reload aVCS on the vBlades. At this point, the vMaster synchronizes the configuration to the vBlades.
NOTE: This step is not required when deploying aVCS in the GUI; when aVCS is enabled the GUI automatically
performs the system reload to synchronize configurations.
4 View the running-config on the vMaster and on the vBlades to verify that both the vMaster and vBlades config-
urations are synchronized.
The steps above establishes the first-time base aVCS configuration synchronization from vMaster to vBlades.
After this, subsequent configuration changes on the vMaster are automatically be synchronized to the vBlades.
5 If you plan to use Layer 3 virtualization, configure it on the vMaster.
Initial vMaster Configuration

To configure the vMaster for the first time:
1. If you have not already done do, configure basic system settings:
• Management interface and default gateway

• Hostname
• Ethernet interfaces
• VLANs
• Routing
2. Configure the following aVCS settings related to VRPR-A high availability:
• Chassis ID – Assign each device to the same set (this is the VRRP-A set ID).
• Device ID – Assign a unique device ID to each device (this is the VRRP-A device ID).
3. Enable aVCS.
4. Configure the floating IP address that will be used by the virtual chassis.
5. Configure aVCS device settings:

• vMaster-election interface – Ethernet interface(s) to use for vMaster election. Generally, these are the interfaces con-
nected to the other devices in the virtual chassis. The election interfaces for devices in an aVCS virtual chassis must
be in the shared partition. Use of an L3V private partition’s interface as an aVCS election interface is not supported.
• (Optional) vMaster-election priority – If you want a specific device to serve as the vMaster for the virtual chassis, set
that device’s aVCS priority to 255. You can leave the priority set to its default value on the other devices, which will
become vBlades.
To allow aVCS to select the vMaster based on aVCS device ID, leave the vMaster-election priority on all devices
unchanged.
NOTE: It is recommended not to disable any of the vMaster election interfaces. Doing so can
interrupt communication between vMaster and vBlade, and cause the vBlade to reload.
See “vMaster Initial Configuration Example” on page 28 for an example configuration.
Initial vBlade Configuration

This section provides details for initial vBlade configuration. You must perform these steps on each device that you want to
be a vBlade in the virtual chassis.
1. Configure basic system settings:
• Management interface and default gateway

• Hostname
• Ethernet interfaces
• VLANs
• Routing
2. Configure the following aVCS settings related to VRPR-A high availability:
• Chassis ID – Assign each device to the same set (this is the VRRP-A set ID).
• Device ID – Assign a unique device ID to each device (this is the VRRP-A device ID).
3. Enable aVCS.
4. Configure aVCS device settings:
• vMaster-election interface – Ethernet interface(s) to use for vMaster election. Generally, these are the interfaces con-
nected to the other devices in the virtual chassis. The election interfaces for devices in an aVCS virtual chassis must
be in the shared partition. Use of an L3V private partition’s interface as an aVCS election interface is not supported.
• (Optional) vMaster-election priority – If you want a specific device to serve as the vMaster for the virtual chassis, set
that device’s aVCS priority to 255. You can leave the priority set to its default value on the other devices, which will
become vBlades.
To allow aVCS to select the vMaster based on aVCS device ID, leave the vMaster-election priority on all devices
unchanged.

NOTE: It is recommended not to disable any of the vMaster election interfaces. Doing so can
interrupt communication between vMaster and vBlade, and cause the vBlade to reload.
See “vBlade Initial Configuration Example” on page 32 for an example configuration.
First-Time Deployment Example

The following commands deploy a virtual chassis containing two devices.
FIGURE 12 Sample First-Time aVCS Deployment Topology
NOTE: For simplicity, configuration of basic system settings is not shown.
vMaster Initial Configuration Example

This section provides an example of initial configuration for the vMaster.
vMaster Initial Configuration Example Using the CLI

1. Enable VRRP-A and configure the VRRP-A set ID and device ID:
ACOS# configure
ACOS(config)# vrrp-a common
ACOS(config-common)# set-id 1
ACOS(config-common)# device-id 1
ACOS(config-common)# enable
ACOS-Active(config-common)# exit
ACOS-Active(config)#

NOTE: If VRRP-A is not already configured on your system, the prompt will show “Forced-
Standby” until the system is able to determine that it should be the active device. When
this happens, the prompt will show “Active” as illustrated in this example.
2. Enable aVCS:
ACOS-Active(config)# vcs enable
AOCS-Active(config:1)#
Note the “:1” at the end of the prompt, indicating that VCS enabled and you are on local device 1 (the vMaster). The
device ID was set earlier using the device-id command under VRRP-A common configuration mode.
3. Configure the floating IP address for the virtual chassis:

ACOS(config:1)# vcs floating-ip 192.168.209.23 /24
4. Configure the aVCS profile for the device:

ACOS(config:1)# vcs device 1
ACOS(config:1-device:1)# interfaces management
ACOS(config:1-device:1)# priority 125
ACOS(config:1-device:1)# enable
ACOS(config:1-device:1)# exit
ACOS(config:1)# vcs reload
System configuration has been modified. Save? [yes/no]:yes

Building configuration...
Write configuration to primary default startup-config
[OK]
Running configuration is saved
ACOS(config:1)#
vMaster Initial Configuration Example Using the GUI

1. Configure the VRRP-A set ID and device ID.
Hover over System in the menu bar, then select VRRP-A. In the Global settings section, enable VRRP-A and configure
the set ID and device ID.

2. Configure aVCS General Settings:
a. Enable aVCS and configure the floating IP address for the virtual chassis.
Hover over System in the menu bar, then select aVCS and select Enable in the “Enable” field.
b. Configure the management address for the virtual chassis.
In the Floating IP Address field, select “IPv4” as the address type from the drop-down list, then enter
192.168.209.23 as the address and /24 as the subnet mask. Click Add.

3. Configure the aVCS device settings:
a. From the System >> aVCS >> Settings page, select the Device tab.
b. Click New Device.
c. In the “Device” field, specify the device ID.
d. In the “Priority” field, specify the priority.
e. Select Enable in the “Enable” field.
f. Select Enable in the “Management” field.
g. Click Submit.

4. Click OK.
vBlade Initial Configuration Example

This section provides an initial configuration example for the vBlade. If your configuration contains multiple vBlades, this pro-
cedure should be repeated on each device.
ACOS-2# configure
ACOS-2(config)# vrrp-a common
ACOS-2(config-common)# set-id 1
ACOS-2(config-common)# device-id 2
ACOS-2(config-common)# enable
ACOS-2-ForcedStandby(config-common) #exit
ACOS-2-ForcedStandby(config)# vcs enable
ACOS-2-ForcedStandby(config:2)# vcs floating-ip 192.168.209.23 /24
ACOS-2-ForcedStandby(config:2)# vcs device 2
ACOS-2-ForcedStandby(config:2-device:2)# interfaces management
ACOS-2-ForcedStandby(config:2-device:2)# priority 120
ACOS-2-ForcedStandby(config:2-device:2)# enable
ACOS-2-ForcedStandby(config:2-device:2)# exit
ACOS-2-ForcedStandby(config:2)# vcs reload

Forcing vMaster Takeover

[OK]
ACOS-2(config:2)#
Forcing vMaster Takeover

This section describes how to force a vBlade to take over as the vMaster.
• Forced vMaster Takeover Procedure
• Temp-Priority Value
Forced vMaster Takeover Procedure

If you need to force a vBlade to take over the vMaster role:
1. Either change the management context to the vBlade or log directly onto the vBlade.
To change the management context to the vBlade, use the vcs admin-session-connect command. For example, to
change management context to the vBlade device 2:
vcs admin-session-connect device 2
2. After you have changed the management context to the vBlade, or logged on directly to the vBlade, use the vcs vmas-
ter-take-over command. For example:
vcs vmaster-take-over 215
You are required to specify a temp-priority value (215 in this example). Unless you use this command on more than one
vBlade, it does not matter which value within the range 1-255 you specify. (See “Temp-Priority Value” on page 33.)
Temp-Priority Value
This command does not change the configured aVCS priority on the vBlade. The command only temporarily overrides the
configured priority.
If you enter this command on only one vBlade, you can specify any value within the valid range (1-255). The takeover occurs
regardless of priority settings on the current vMaster

Determining a Device’s aVCS ID
If you enter the vcs vmaster-take-over command on more than one vBlade, the device on which you enter the highest temp-
priority value becomes the vMaster
If you enter the same temp-priority value on more than one vBlade, the same parameters used for initial vMaster election are
used to select the new vMaster:
• The device with the highest configured aVCS priority is selected. (This is the priority configured by the priority
command at the configuration level for the aVCS device.)
• If there is a tie (more than one of the devices has the same highest configured aVCS priority), then the device with the
lowest device ID is selected.
In either case, the new vMaster is selected from among only the vBlades on which you enter the vcs vmaster-take-over com-
mand.
Determining a Device’s aVCS ID

When you log onto the virtual chassis or onto an individual device in the chassis, the device’s aVCS ID is not apparent, unless
you modified the device’s hostname to indicate the device ID.
To determine a device’s aVCS ID, use the show vcs summary command. The device you are logged onto is indicated with an
asterisk in the State column of the Members section.
• If you are logged directly onto a device through its management interface or a data interface, the asterisk indicates
the device.
• If you are logged onto the floating IP address of the virtual chassis, the asterisk indicates the vMaster
(This is true unless you changed the device context of the management session. In this case, you are logged onto the
vBlade to which you changed the device context. See “Virtual Chassis Management Interface (Floating IP Address)” on
page 10.)
You also can determine the device ID by using the show vcs summary command; the following example indicates that the
device you are logged onto is aVCS device 1, indicated by the asterisk for device ID 1 in the “Members” section of the output:
ACOS-Active-vMaster[1/1]# show vcs summary
VCS Chassis:
VCS Enabled: Yes
Chassis ID: 1
Multicast IP: 224.0.0.210
Multicast Port: 41217
Version: 4.0.1.b159
Members(* means local device):

ID State Priority IP:Port Location
-------------------------------------------------------------------------------
1 vMaster(*) 0 192.168.216.201:41216 Local

Viewing aVCS Information
2 vBlade 0 192.168.216.202:41216 Remote

Total: 2
In the GUI, you can view this information in the main header. Look for this section in the header:
The Device Context field shows that you are currently working on device 1 in the chassis. In addition, the field on the left indi-
cates that this device (the local device, indicated by the asterisk) is the vMaster.
Viewing aVCS Information

Use the show vcs summary command to view global virtual chassis parameters and the current role (vMaster or vBlade) of
each device in the virtual chassis:
Use the show vcs images command to view the installed aVCS-capable ACOS software image:
ACOS# show vcs images

Image Name Type
aximage_4_0_0_500.tar.gz hd_pri
aximage_2_7_0-P2_53.tar.gz hd_sec
-------- ext
From the GUI, navigate to System >> aVCS >> Settings. Click on the Statistics tab, then select aVCS Summary from the
drop-down list. The resulting page shows general VCS statistics and available aVCS-capable images on the device.
Also from the GUI, navigate to System >> aVCS >> Settings, then click on the aVCS Deployment Summary tab to view
information about your virtual chassis deployment.
aVCS CLI-Session Management

This section contains the following topics:
• CLI Message for Commands That Affect Only the Local Device
• Option To Configure aVCS Master Affinity to VRRP-A Active
• Option to Disable Syncing of SNMP sysContact OID
• vMaster Maintenance Mode

CLI Message for Commands That Affect Only the Local Device
This release provides an option that displays a message when you enter a configuration command that applies to only the
local device. When this option is enabled, a message is displayed if you enter a configuration command that affects only the
local device, and the command does not explicitly indicate the device.
This enhancement is enabled by default and can not be disabled.
Local Device
The “local device” is the device your CLI session is on.
• If you log directly onto one of the devices in the virtual chassis, that device is the local device. For example, if you log
on through the management IP address of a vBlade, that vBlade is the local device.
• If you change the device context to another ACOS device, that device becomes the local device.
• If you log onto the virtual chassis’ floating IP address, the vMaster is the local device.
Message Example
The following command configures a static MAC address on the local device:
ACOS(config)# mac-age-time 444
This type of configuration change is device-specific. However, the command does not specify the device ID to which to
apply the configuration change. Therefore, the change is applied to the local device. In this example, the local device is
device 1 in the aVCS virtual chassis.
The message is not necessary if you explicitly specify the device, and therefore is not displayed:
ACOS(config)# mac-age-time 444 device 2
Notes
• For commands that access the configuration level for a specific configuration item, the message is displayed only for
the command that accesses the configuration level. For example:
ACOS(config)# interface ethernet 2
This operation applied to device 1
ACOS(config-if:ethernet2/1)# ip address 1.1.1.1 /24
ACOS(config-if:ethernet2/1)#
The message is not displayed after the ip address command is entered, because the message is already displayed
after the interface ethernet 2 command is entered.
The same is true for commands at the configuration level for a routing protocol. The message is displayed only for the
command that accesses the configuration level for the protocol.

• In most cases, the message also is displayed following clear commands for device-specific items. An exception is
clear commands for routing information. The message is not displayed following these commands.
• The message is not displayed after show commands.
Option To Configure aVCS Master Affinity to VRRP-A Active

This section contains the following:
• Overview of aVCS Master Affinity to VRRP-A Active
• aVCS Master Affinity to VRRP-A Active Configuration Example
• aVCS Master Affinity to VRRP-A Active and vMaster Takeover
Overview of aVCS Master Affinity to VRRP-A Active

Master affinity to VRRP-A Active enables the vMaster device in a virtual chassis to failover when the Active device in a VRRP-A
VRID fails over to a Standby device. When the Standby device becomes Active, it will also act as the vMaster device in the vir-
tual chassis (Figure 13).
FIGURE 13 aVCS Master Affinity to VRRP-A Active
In this topology, device 1 is the Active device in the VRID. When it fails over, device 2 will become the Active device, as it has
the next highest priority. Device 4, which is currently the vMaster in the virtual chassis and is configured with VRID affinity,
will follow the update in VRRP-A and switch to device 2 as the vMaster.

This ensures that the device assuming the master configuration also serves as the active data path. Configuring the VRID
affinity causes the vMaster to stay with a selected VRID. This capability provides deterministic behavior on the location of the
aVCS master and the unit processing traffic for a particular VRRP-A VRID. It also provides better control to effectively utilize
available bandwidth and facilitates troubleshooting efforts.
aVCS Master Affinity to VRRP-A Active Configuration Example

To enable a vMaster failover to the Active device, the shared partition is configured to follow the Active device on a specified
VRID (device running VRRP-A). On each device that is part of the aVCS cluster, including the Active device, issue the affin-
ity-vrrp-a-vrid command. See vcs device for more information.
The following example snippets configure VRID affinity for four devices in a virtual chassis, based on the example topology in
Figure 13:
NOTE: The affinity-vrrp-a-vrid must be explicitly configured on all devices for which
you want to enable this feature, and the VRID must also be the same for all devices.
!
...
vcs device 1
priority 225
enable
affinity-vrrp-a-vrid 0
!
vcs device 2
priority 200
enable
!
vcs device 3
priority 150
enable
vcs device 4
priority 175
enable
!
vcs local-device 1
...

aVCS Master Affinity to VRRP-A Active and vMaster Takeover

VRID affinity and forced vMaster takeover (“Forced vMaster Takeover” on page 18) cannot be used together; you will see the
following message if you try to configure vMaster takeover with VRID affinity configured:
Take over vMastership: VCS: vmaster take over is not allowed in affinity vrid state
Once VRID affinity is configured, the vMaster will continue to follow the active device in the VRID using the existing device
priorities. To change the priorities, you must issue the vcs reload command for the new priorities to take effect.
vMaster takeover can be used to assign a new vMaster without regard to existing priorities; hence it is not allowed in con-
junction with VRID affinity.
Option to Disable Syncing of SNMP sysContact OID

By default, the SNMP sysContact OID value is synchronized among all member ACOS devices of an aVCS virtual chassis. The
current release provides an option to disable this synchronization, on an individual device basis.
NOTE: After configuring this option for an ACOS device, if you disable aVCS on that device, the
running-config is automatically updated to continue using the same sysContact value
you specified for the device. You do not need to reconfigure the sysContact on the
device after disabling aVCS.
The following example shows an example; to disable syncing of SNMP contact snmp-admin on aVCS device 2:
ACOS(config)# no snmp-server contact snmp-admin on-device 2
vMaster Maintenance Mode

In maintenance mode, the vMaster can briefly be placed into maintenance without triggering a failover of the vMaster role
to a vBlade. During the maintenance window, the vBlades continue to operate, without attempting to failover to the vMaster
role.
For more information, see the vcs vMaster-maintenance command.


Adding a Device to a Virtual Chassis
This chapter describes how to add a configured ACOS device to a running virtual chassis.
CAUTION: By default, when you add a configured ACOS device to a running virtual chassis, the
device-specific configuration is retained but the common configuration (SLB and so on)
is replaced by the vMaster.
To allow the vMaster to also replace the new device’s device-specific configuration, use
the disable-merge option when you reload aVCS.
NOTE: If a device has already been a member of a virtual chassis, the device can not be added
to a new virtual chassis.
The following topics are covered in this chapter:
• Overview of Adding a Device to a Virtual Chassis
• Procedure for Adding a Device to a Virtual Chassis
Overview of Adding a Device to a Virtual Chassis

Figure 14 shows the process that occurs when you add an ACOS device that is already configured to a virtual chassis.
NOTE: The configuration merge behavior described in this section is the default behavior. If
you want the vMaster to also remove the device-specific configuration information from
the new device, use the disable-merge option when you reload aVCS.

Procedure for Adding a Device to a Virtual Chassis
FIGURE 14 Previously Configured Device Added to Virtual Chassis and Merged with Virtual Chassis
The following process occurs when you add a previously configured ACOS device to a virtual chassis:
1. The previously configured ACOS device (labeled “Configured Device” in the figure) is connected to the virtual chassis
network at Layer 2.
An admin then configures aVCS settings on the previously configured device and reloads aVCS.
The aVCS reload causes the device to send its aVCS configuration and its device-specific configuration to the vMaster.
2. The vMaster applies the aVCS configuration and device-specific configuration to its virtual chassis configuration.
The vMaster then synchronizes the device’s configuration to the other vBlades as part of the normal configuration syn-
chronization process.
3. The vMaster sends its running-config to the device.
4. On the device, the vMaster running-config is saved as the device’s startup-config. To complete its aVCS reload, the
device loads its new startup-config. The device is now another vBlade in the virtual chassis.

To add an ACOS device that already has a configuration to an aVCS chassis:
1. Make sure the virtual chassis is running:

a. Log onto the floating IP address (management address) of the virtual chassis.
b. View the virtual chassis status using the show vcs summary command
2. Connect the configured ACOS device to the Layer 2 network that contains the other virtual chassis members.
3. Configure aVCS settings on the new device and reload aVCS.
The following commands show how to configure aVCS settings on a configured ACOS device to be added to a virtual
chassis, and reload aVCS to activate the aVCS configuration:
ACOS# configure
ACOS(config-common_# enable
ACOS-Active(config:3)# vcs floating-ip 192.168.100.169 /24
ACOS-Active(config:3)# vcs device 3
ACOS-Active(config:3-device:3)# interface management
ACOS-Active(config:3-device:3)# priority 197
ACOS-Active(config:3-device:3)# enable
ACOS-Active(config:3-device:3)# exit
ACOS-Active(config:3)# vcs reload
Following the reload of aVCS, the ACOS device joins the virtual chassis as a vBlade, and its configuration information is
migrated to the virtual chassis’ vMaster.
4. Verify that the device is now a member of the virtual chassis using the show vcs summary command.
NOTE: Do not use the disable-merge option when you reload aVCS; this option is used only
when replacing an existing virtual chassis member with a new device.


Replacing a Device in a Virtual Chassis
By default, when you add an ACOS device to a virtual chassis that is already running, the device’s configuration information is
migrated to the vMaster.
However, if you are replacing a member of the virtual chassis by removing the ACOS device from the network and inserting
another ACOS device of the same model, you may want the vMaster to migrate the removed device’s configuration informa-
tion to the new device. In this case, when you reload aVCS on the new device, make sure to use the disable-merge option:
The following commands configure aVCS settings on a replacement ACOS device to be inserted into a virtual chassis, and
reload aVCS to activate the aVCS configuration:
ACOS# configure
ACOS(config-common)# enable
ACOS-Active(config:3)# vcs floating-ip 192.168.100.169 /24
ACOS-Active(config:3)# vcs device 3
ACOS-Active(config:3-device:#)# interface management
ACOS-Active(config:3-device:3)# priority 197
ACOS-Active(config:3-device:3)# enable
ACOS(Active(config:3-device:3)# exit
ACOS-Active(config:3)# vcs reload disable-merge
Following the reload of aVCS, the ACOS device joins the virtual chassis as a vBlade, and receives its configuration information
from the virtual chassis’ vMaster.


Configuration Synchronization without Reload
You can use the ACOS Virtual Chassis System (aVCS) feature to provide automated configuration synchronization in VRRP-A
deployments, even if you do not plan to use any other aVCS features. Use of aVCS for configuration synchronization provides
the following benefits:
• aVCS configuration synchronization is automatic and occurs in real time. Each configuration change is synchronized
to the other ACOS device(s) as soon as the change occurs.
• Reload is not required.
Figure 15 shows an example VRRP-A deployment that uses aVCS for automated configuration synchronization.
FIGURE 15 aVCS Used for Automated Configuration Synchronization
VRRP-A with aVCS Deployment Example

The following commands deploy the VRRP-A configuration shown in Figure 15.
Commands on Device 1
The following commands configure the VRRP-A set ID and device ID, and enable VRRP-A on device 1:
ACOS-1# configure

ACOS-1-Active(config-common)# exit
ACOS-1-Active(config)#
The following command enables VCS and configures the floating IP address, which is the management address for the vir-
tual chassis. The floating IP address must be in the same subnet as the ACOS device’s management IP address or one of the
device’s data interface IP addresses.
ACOS-1-Active(config)# vcs enable

ACOS-1-Active(config:1)# vcs floating-ip 192.168.209.23 /24
The following commands configure the aVCS profile for the device.
ACOS-1-Active(config:1)# vcs device 1

ACOS-1-Active(config:1-device:1)# priority 110
ACOS-1-Active(config:1-device:1)# interface management
ACOS-1-Active(config:1-device:1)# interfaces ethernet 1
ACOS-1-Active(config:1-device:1)# enable
ACOS-1-Active(config:1-device:1)# exit
The priority command helps identify this ACOS device as the preferred vMaster. Use a higher priority value on this device
than on the second device.
The interfaces commands identify interfaces that can be used by aVCS. It is recommended to specify more than one
interface, to help ensure continued communication in case a link goes down.
The following commands save the changes and activate the aVCS configuration.
ACOS-1-Active(config:1)# write memory

ACOS-1-Active(config:1)# vcs reload
Commands on Device 2
The following commands configure the VRRP-A set ID and device ID, and enable VRRP-A on device 2:
ACOS-2# configure
ACOS-2(config-common)# exit
ACOS-2-Active(config)# vcs enable
ACOS-2-Active(config:2)# vcs floating-ip 192.168.209.23 /24
ACOS-2-Active(config:2)# vcs device 2
ACOS-2-Active(config:2-device:2)# priority 100
ACOS-2-Active(config:2-device:2)# interface management
ACOS-2-Active(config:2-device:2)# interface ethernet 1

ACOS-2-Active(config:2-device:2)# enable
ACOS-2-Active(config:2-device:2)# exit
ACOS-2-Active(config:2)# vcs reload

[OK]
ACOS-2-Active(config:2)#
NOTE: When you enter the vcs reload command on the second device, it receives non-
device-specific configuration information from the first device. This occurs if the first
device already has become the vMaster for the aVCS virtual chassis.


aVCS CLI Commands
This chapter describes the commands used to configure ACOS Virtual Chassis System (aVCS).
• aVCS Operational Commands
• aVCS Configuration Commands
• aVCS Show Commands
NOTE: aVCS reload is required to place any aVCS-related configuration changes into effect.

aVCS Operational Commands

This section describes the aVCS operational commands.
These commands are used to operate aVCS, but do not change any aVCS configuration settings. To configure aVCS, refer to
“aVCS Configuration Commands” on page 57.
The following operational commands are covered in this section:
• device-context
• vcs admin-session-connect
• vcs disable
• vcs enable
• vcs vMaster-maintenance
• vcs vmaster-take-over
device-context
Description Change the context of the CLI session from the vMaster to a vBlade, in order to configure the
vBlade.
This command is used to configure device-specific and routing settings for an ACOS device
in an aVCS environment. To configure aVCS-related settings for a device in an aVCS
environment, use the vcs device command.
This command can also be applied to certain non-routing configuration commands (for
example, LACP).
NOTE: This command replaces the router device-context command in previous

releases.
Syntax device-context DeviceID
Replace DeviceID with the ID of the target device. The target device is the device you plan
to access. The acceptable values for this parameter will vary depending on your specific
hardware platform.
Default By default, the vMaster for the virtual chassis is the context of the management session.
Mode Configuration mode
Example The following example changes the configuration context to device 3 in a virtual chassis, and
changes the hostname of that device to “ACOS3:”
ACOS(config)# device-context 3

All the following configuration will go to device 3

ACOS(config)# hostname ACOS3
ACOS3(config)#
vcs admin-session-connect
Description Open an SSH admin session with a device in an aVCS virtual chassis.
Syntax vcs admin-session-connect device DeviceID
Replace DeviceID with the ID of the target device. The target device is the device you plan
to access. The acceptable values for this parameter will vary depending on your specific
hardware platform.
Default By default, the CLI session is on the device you logged onto.
Mode Privileged EXEC or Global Config (on vMaster only)
Usage This command does not apply to device-specific configuration commands. To enter device-
specific configuration commands on another device, use the device-context command
instead.
Entering this command on the vMaster creates an SSH connection to the vBlade, without a
password prompt. After the connection is established, you can enter configuration
commands to take effect on the vBlade.
While the connection to the vBlade is in effect, configuration commands can not be entered
directly on the vBlade through any other management connections.
If an SSH security warning about the RSA fingerprint is displayed:
• If the RSA fingerprint is correct, enter yes.

• If the RSA fingerprint does not match, enter no. Someone may be attempting to spoof
the device in order to gain information about the system or network access.
Example The following command changes the CLI session to aVCS device 2. In this example, this is the
first time the command has been used to access device 2.
ACOS-device1(config)# vcs admin-session-connect device 2

spawn ssh -l admin 192.168.100.126
The authenticity of host '192.168.100.126 (192.168.100.126)' can't be established.
RSA key fingerprint is ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.100.126' (RSA) to the list of known hosts.
Password:***
Last login: Thu Jul 22 21:06:46 2010 from 192.168.3.77
ACOS-device2#

At the Password prompt, enter the password for the admin account on the target device.
Example The following example shows the CLI response if you accidentally try to switch to the device
you are already on:
ACOS-device1(config)# vcs admin-session-connect device 1

Unnecessary to do such operation to manage local device
vcs disable
Description Disable aVCS on the device.
Syntax vcs disable
Default N/A. This is an operational command rather than a configuration command.
Mode Privileged EXEC (vMaster or vBlade)
Usage In addition to disabling aVCS on the current device, you can also use device-context to disa-
ble aVCS on another device. See examples below.
Example The following example disables aVCS on the current device:
ACOS-Active-vMaster[1/1]# vcs disable

ACOS-Active-vMaster[1/1]#
Example The following example switches to device 2 from device 1, then disables aVCS on device 2:
ACOS-Active-vMaster[1/1]# configure
ACOS-Active-vMaster[1/1](config:1)# device-context 2
ACOS-Active-vMaster[1/1](config:2)# vcs disable
ACOS-Active-vMaster[1/1](config:2)#
vcs enable
Description Enable aVCS on the device.
Syntax vcs enable
Default N/A. This is an operational command rather than a configuration command.
Mode Privileged EXEC (vMaster or vBlade)
Usage After you enter the vcs enable command, you must enter the vcs reload command to
place any aVCS configuration changes into effect and activate the feature.

Before using this command, many of the VCS commands are not available from the CLI.
The following example shows the commands available prior to running the vcs enable
command:
ACOS(config)# vcs ?
failure-retry-count VCS retry count after fails to join the chassis
vMaster-maintenance During this period, vMaster can leave and come back to
be vMaster again
enable enable VCS
disable disable VCS
ACOS(config)# vcs
In addition to enabling aVCS on the current device, you can also use device-context to
enable aVCS on another device. See examples below.
Example The following example enables aVCS on the current device:
ACOS-Active-vMaster[1/1]# vcs enable

ACOS-Active-vMaster[1/1]#
Example The following example switches to device 2 from device 1, then enables aVCS on device 2:
ACOS-Active-vMaster[1/1]# configure
ACOS-Active-vMaster[1/1](config:1)# device-context 2
ACOS-Active-vMaster[1/1](config:2)# vcs enable
ACOS-Active-vMaster[1/1](config:2)#
vcs vMaster-maintenance
Description Change the length of the vMaster maintenance window.
Syntax [no] vcs vMaster-maintenance seconds
Replace seconds with the length of the maintenance window. You can specify 0-3600
seconds.
Default The default is 60 seconds.
Mode Privileged EXEC (on vBlade); Privileged EXEC and Global Config (on vMaster)
Usage aVCS option that allows the vMaster to briefly be placed into maintenance, without trigger-
ing failover of the vMaster role to a vBlade. During the maintenance window, the vBlades
continue to operate, without attempting to failover to the vMaster role.

vcs vmaster-take-over
Description Force vMaster re-election, by temporarily changing a device’s aVCS priority. This command is
useful for changing a vBlade to vMaster without changing the aVCS configuration profile for
either device.
Syntax [no] vcs vmaster-take-over temp-priority
Replace temp-priority with the priority value, 1-255.
Default N/A
Usage This command does not change the configured aVCS priority on the device. The command
only temporarily overrides the configured priority.
If you enter this command on only one vBlade, you can specify any value within the valid
range (1-255). The takeover occurs regardless of priority settings on the current vMaster.
If you enter the vcs vmaster-take-over command on more than one device, the device
on which you enter the highest temp-priority value becomes the vMaster.
If you enter the same temp-priority value on more than one device, the same parameters
used for initial vMaster election are used to select the new vMaster:
• The device with the highest configured aVCS priority is selected. (This is the priority
configured by the priority command at the configuration level for the aVCS device.)
• If there is a tie (more than one of the devices has the same highest configured aVCS pri-
ority), then the device with the lowest device ID is selected.
In either case, the new vMaster is selected from among only the devices on which you enter
the vcs vmaster-take-over command.
Example The following commands change the management context to a vBlade, then force the
device to become the vMaster:
ACOS-1# vcs admin-session-connect device 2

spawn ssh -l admin 192.168.100.126
The authenticity of host '192.168.100.126 (192.168.100.126)' can't be established.
RSA key fingerprint is ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.100.126' (RSA) to the list of known hosts.
Password:
Last login: Wed Aug 11 20:27:24 2010 from 192.168.3.74
[type ? for help]
ACOS>enable
Password:********

aVCS Configuration Commands
ACOS-2#vcs vmaster-take-over 255

This section describes the aVCS configuration commands.
These commands are used to configure specific aVCS settings, and are available after entering the device-context global
configuration command.
The following commands are available:
• vcs dead-interval
• vcs debug
• vcs device
• vcs failure-retry-count
• vcs floating-ip
• vcs floating-ipv6
• vcs force-wait-interval
• vcs multicast-ip
• vcs multicast-ipv6
• vcs multicast-port
• vcs reload
• vcs ssl-enable
• vcs time-interval
• vcs vmaster-maintenance
vcs dead-interval
Description Configure the number of seconds vBlade devices wait for a keepalive message from the
vMaster, before assuming the vMaster is unavailable and triggering vMaster re-election.
Syntax [no] vcs dead-interval seconds
Replace seconds with the maximum number of seconds to wait for a keepalive message
from the vMaster before triggering vMaster re-election. You can specify 5-60 seconds.

Default 10
Mode Global Config (vMaster only)
Example The following example sets the interval to 20 seconds:
ACOS-Active-vMaster[1/1](config:1)# vcs dead-interval 20
vcs debug
Description Enable aVCS debugging.
Syntax [no] vcs debug {daemon | election | info | vmaster | vblade}
Parameter Description
daemon Enables debugging for the aVCS process.
election Enables debugging for vMaster election.
info Enables display of informational messages in the debugging output.
vmaster Enables debugging for vMaster-related operations.
vblade Enables debugging for vBlade-related operations.
Default Disabled
Example The following commands enable debugging for aVCS vMaster operations, and display the
output:
ACOS-Active-vMaster[1/1](config:1)# vcs debug vmaster

ACOS-Active-vMaster[1/1](config:1)# show vcs debug
Debugging switches: vmaster,
Debugging Buffer Size: 8 MB
2010/08/02 10:46:02, [vMaster], vBlade 0, msg loop, received msg 21
2010/08/02 10:46:02, [vMaster], vBlade 0, msg loop, sent msg 20
...
vcs device
Description Add a device to an existing aVCS chassis, and configure aVCS-related settings for the speci-
fied device.

To configure device-specific or routing settings for an ACOS device in an aVCS environment,

use the device-context command.
Syntax [no] vcs device device-id
Replace device-id with the device ID. The acceptable values for this parameter will vary
depending on your specific hardware platform.
This command changes the CLI to the configuration level for the specified aVCS device,
where the following aVCS-related commands are available.
Command Description
[no] affinity-vrrp-a-vrid Configures a vMaster failover to the Active device on a specified VRID (device run-
vrid-group ning VRRP-A). Use this command on each device that is part of the aVCS cluster,
including the Active device.
For more information about this feature, see “Option To Configure aVCS Master
Affinity to VRRP-A Active” on page 37.
[no] enable Enables aVCS on the device.
aVCS is disabled by default.
[no] interfaces Device interfaces used for aVCS vMaster election traffic. You can specify up to 6
{ethernet portnum | election interfaces.
management |
trunk trunk-num | For vMaster election to work, the other devices in the virtual chassis must be able to
ve ve-num} reach the device on the specified interface(s).
[no] priority num Priority of this device for vMaster election, 1-255. Higher priority values are pre-
ferred over lower ones.
The default priority is 0 (not set).
[no] unicast-port Protocol port used to create TCP connection between the vMaster and vBlade. This
portnum connection is used for configuration synchronization.
The default unicast port is 41216.
Default No aVCS devices are configured by default. When you add an aVCS device, its parameters
have the default values described in the table above.
Usage The election interfaces for devices in an aVCS virtual chassis must be in the shared partition.
Use of an L3V private partition’s interface as an aVCS election interface is not supported.
Example The following commands add device 3 to an existing aVCS chassis. The management inter-
face will be used for aVCS election traffic and its priority is 3.
ACOS-Active-vMaster[1/1](config:1)# vcs device 3

ACOS-Active-vMaster[1/1](config:1-device:3)# interfaces management
ACOS-Active-vMaster[1/1](config:1-device:3)# priority 3
ACOS-Active-vMaster[1/1](config:1-device:3)# enable

vcs failure-retry-count
Description Configure the maximum number of retries for an aVCS device to join a virtual chassis.
Syntax [no] vcs failure-retry-count {retries | forever}
Parameter Description
retries Maximum number of retries for an aVCS device to join a virtual chassis.
You can specify 0-255.
forever Specify an unlimited amount of retries for a aVCS device to join a vir-
tual chassis.
Default 2
Mode Global Config (vMaster or vBlade)
Usage If the device is unable to join the virtual chassis after all allowed retries are used, aVCS stops
on the device. In this case, you use the vcs reload command to restart aVCS on the
device.
Example The following example configures an ACOS device to try 3 times to join a virtual chassis:
ACOS-Active-vMaster[1/1](config:1)# vcs failure-retry-count 3
vcs floating-ip
Description Configure the management IP address for the aVCS virtual chassis.
Syntax [no] vcs floating-ip ipaddr {subnet-mask | /mask-length}
Specifies the IP address and subnet mask.
Default Not set
Example The following command sets the management address for the aVCS virtual chassis to
192.168.1.69/24:
ACOS-Active-vMaster[1/1](config:1)# vcs floating-ip 192.168.1.69 /24
vcs floating-ipv6
Description Configure an IPv6 management IP address for the aVCS virtual chassis.
Syntax [no] vcs floating-ipv6 ipv6-addr/mask-length

Specifies the IP address and subnet mask.
Default Not set
Example The following command sets the management address for the aVCS virtual chassis to the
IPv6 address fc00:0:3::23:a/24:
ACOS-Active-vMaster[1/1](config:1)# vcs floating-ipv6 fc00:0:3::23:a/24
vcs force-wait-interval
Description Delay the start of aVCS following a reload/reboot.
Syntax [no] vcs force-wait-interval seconds
Replace seconds with the number of seconds (5-240) to wait following a a reload or reboot
to start aVCS.
Default 5
Usage This command can be useful if you use staggered upgrade.
Example The following example configures the device to wait 10 seconds before starting the reload or
reboot:
ACOS-Active-vMaster[1/1](config:1)# vcs force-wait-interval 10
vcs multicast-ip
Description Configure the multicast IPv4 address used for aVCS vMaster election.
Syntax [no] vcs multicast-ip ipv4-addr
Replace ipv4-addr with the multicast address.

Default 224.0.0.210
Usage To configure the protocol port, see “vcs multicast-port” on page 62.
vcs multicast-ipv6
Description Configure the multicast IPv6 address used for aVCS vMaster election.
Syntax [no] vcs multicast-ip ipv6-addr
Replace ipv6-addr with the multicast address.
Usage To configure the protocol port, see “vcs multicast-port” on page 62.
vcs multicast-port
Description Configure the protocol port used for aVCS vMaster election.
Syntax [no] vcs multicast-port portnum
Replace portnum with the protocol port number, 1-65535.
Default 41217
Usage To configure the multicast address, see “vcs multicast-ip” on page 61.
vcs reload
Description Reload the aVCS process.
Syntax vcs reload [disable-merge]
The disable-merge option prevents configuration information from being migrated from
the vBlades to the vMaster following the reload. This option is useful when you are replacing
a virtual chassis vBlade by removing an ACOS device and replacing it with another ACOS
device of the same model. In this case, the option allows the replacement device to be
configured by the vMaster.
After the initial configuration migration, configuration synchronization operates normally.
Without this option, when you add an ACOS device to a virtual chassis that is already
running, the device’s configuration information is migrated to the vMaster
Default N/A

Usage aVCS reload is required to place any aVCS-related configuration changes into effect.
vcs ssl-enable
Description Enable or disable SSL for configuration synchronization traffic between aVCS devices.
Syntax [no] vcs ssl-enable
Default Disabled
vcs time-interval
Description Number of seconds between keepalive messages from the vMaster to vBlades.
Syntax [no] vcs time-interval seconds
Replace seconds with the number of seconds between transmission of keepalive messages
from the vMaster to vBlades. You can specify 1-60 seconds.
Default 3
vcs vmaster-maintenance
Description Briefly place the vMaster into maintenance mode without triggering a failover to a vBlade.
Syntax vcs vmaster-maintenance period
Replace period with the amount of time (0-3600 seconds) that the vMaster is placed into
maintenance mode without triggering a failover.
Default 60 seconds
Usage The vMaster can be placed into maintenance mode without triggering a failover to a vBlade.
During this maintenance window, the vBlades continue to operate without attempting to
take over the vMaster role. At the end of the configurable maintenance period, the vMaster
returns to the vMaster role.

aVCS Show Commands
aVCS Show Commands

This section describes the aVCS-specific show commands:
• show vcs debug
• show vcs images
• show vcs stat
• show vcs summary
NOTE: This section only contains aVCS-related show commands beginning with “show vcs.”
Many other show commands can be used in an aVCS context by specifying the specific
ID of a device in the virtual chassis.
For more information, see the “Show Commands” chapter in the Command Line Inter-
face Reference, or type “?” at the CLI prompt.
show vcs debug

Description Display aVCS debug messages.
Syntax show vcs debug [old_first]
Use the old_first option to list messages beginning with the most recent. Without this
option, the list begins with the oldest message in the buffer.
Mode All
show vcs images

Description Display the aVCS-capable software images stored on the ACOS device.
NOTE: Only images that support aVCS are listed. To list all images, use the show bootim-
age command instead.
Syntax show vcs images
Mode All
Example The following command shows the aVCS-capable software images stored on the device:
ACOS# show vcs images

Image Name Type

aVCS Show Commands
aximage_4_0_1_159.tar.gz hd_pri
aximage_4_0_0_536.tar.gz hd_sec
-------- cf_pri
-------- cf_sec
-------- ext
The following table describes the fields in the command output.
Field Description
Image Name Name of the software image.
Type Location of the image:
• hd_pri – Primary image area of the hard drive or Solid State Drive (SSD)
• hd_sec – Secondary image area of the hard drive or SSD
• cf_pri – Primary image area of the compact flash drive
• cf_sec – Secondary image area of the compact flash drive
• ext – Extended image, used for staged upgrades during which multiple ACOS software versions
run in the virtual chassis.
Note: If dashes (--------) are displayed instead of an image name, the image does not support aVCS.
show vcs stat

Description Display aVCS statistics.
Syntax show vcs stat
Mode All
Example The following example shows aVCS statistics. In this example, the command is entered on
the vMaster.
ACOS# show vcs stat

Parameters:
Chassis-ID: 3
time-interval: 3
failure-retry-count: 2
Floating-IPv4: 5.5.5.254/24
Floating-IPv4: 192.168.148.14/24
SSL-enabled: No
Multicast-IP: 224.0.0.210
Multicast-Port: 41217
Dev-ID: 1
Dev-Prio: 200
Unicast-Port: 41216
Interfaces: management

aVCS Show Commands
Enabled: Yes
Dev-ID: 2
Dev-Prio: 199
Unicast-Port: 41216
Enabled: Yes
Dev-ID: 3
Dev-Prio: 100
Unicast-Port: 41216
Interfaces: ethernet 1
Enabled: Yes
Local-Dev-ID: 1
Running parameters:
Chassis-ID: 3
time-interval: 3
failure-retry-count: 2
Floating-IPv4: 5.5.5.254/24
Floating-IPv4: 192.168.148.14/24
SSL-enabled: No
Multicast-IP: 224.0.0.210
Multicast-Port: 41217
Dev-ID: 1
Dev-Prio: 200
Dev-IPv4: 192.168.148.16
Unicast-Port: 41216
Enabled: Yes
Dev-ID: 2
Dev-Prio: 199
Dev-IPv4: 192.168.148.15
Unicast-Port: 41216
Enabled: Yes
Dev-ID: 3
Dev-Prio: 100
Unicast-Port: 41216
Interfaces: ethernet 1
Enabled: Yes
Local-Dev-ID: 1
Dev-State: vMaster
Version: 2.6.1.b478
Config: 68163521ab9b064f, 2962
Election context:
Stop-Request: No

aVCS Show Commands
Parameters:
Num-Sockets: 1
Dev-State: vMaster
Dev-DynPrio: 4294967295
PDU-Seq: 916
vMasterTakeOverPrio: 0
vMaster-Sent: 2011-05-03 10:35:56.363158
Neighbour: seen 911 times, last seen 2011-05-03
10:35:56.461260
Ident: VCE
Version: 1.0
Type: vBlade-PDU
Length: 4
Seq: 912
HW-Model: 5200
Chassis-ID: 3
Device-ID: 2
Device-Prio: 199
Device-DynPrio: 4294967295
Config: 2962
vMaster context:
Stop-Request: No
Server-Connection:
Local-Addr: 192.168.148.16:41216
Remote-Addr: 0.0.0.0:0
State: Listen
IO-State:
SSL: No
Local-Addr: 0.0.0.0:0
State: Closed
IO-State:
SSL: No
State: Closed
IO-State:
SSL: No
State: Closed
IO-State:
SSL: No

aVCS Show Commands
State: Closed
IO-State:
SSL: No
State: Closed
IO-State:
SSL: No
vBlade:
ID: 0
Device-ID: 2
vBlade-State: Ready
Stop-Request: No
Connection:
Local-Addr: 192.168.148.16:41216
Remote-Addr: 192.168.148.15:35768
State: Connected
IO-State: R
SSL: No
Counters:
Daemon:
Start Time: 2011-05-03 09:46:09.279027
Election Started: 2 times
Election Stopped: 1 times
Receive Errors: 0
Send Errors: 0
Received Bytes: 6273103
Sent Bytes: 658841766
Received Messages: 70440
Sent Messages: 70440
Invalid Messages: 0
Message Handling Failure: 0
Election:
Start Time: 2011-05-03 09:49:06.865468
Receive Errors: 0
Send Errors: 0
Received Bytes: 98280
Sent Bytes: 56644
Received vMaster-PDU: 0
Received MC-PDU: 2
Received vBlade-PDU: 1818
Received MTO-PDU: 0
Received Unknown-PDU: 0

aVCS Show Commands
Sent vMaster-PDU: 911

Sent MC-PDU: 3
Sent vBlade-PDU: 0
Sent MTO-PDU: 0
Sent Unknown-PDU: 0
Invalid PDU: 0
PDU HW mismatch: 0
PDU Chassis-ID mismatch: 0
PDU Device-ID collision: 0
MC, discarded vMaster-PDU: 0
MC, replaced vMaster-PDU: 0
MC, duplicate vMaster-PDU: 0
MC, timers reset by MC-PDU: 0
MC, timers reset by MTO-PDU: 0
vBlade, duplicate vMaster-PDU: 0
vBlade, discard challenger: 0
vBlade, replace challenger: 0
vBlade, duplicate challenger: 0
vBlade, discard neighbour: 0
vBlade, too many neighbours: 0
vBlade, duplicate neighbours: 0
vMaster, discard challenger: 0
vMaster, new challenger: 0
vMaster, replace challenger: 0
vMaster, duplicate challenger: 0
vMaster, discard neighbour: 0
vMaster, too many neighbours: 0
vMaster, duplicate neighbours: 909
Enter MC: 0
Enter vBlade: 0
Enter vMaster: 1
Enter MTO: 0
Leave MC: 1
Leave vBlade: 0
Leave vMaster: 0
Leave MTO: 0
vMaster:
Start Time: 2011-05-03 09:49:15.971189
Start vBlade Errors: 0
vBlades Started: 1
vBlades stopped: 0
Received Configuration Updates: 0
Last Configuration Update: N/A
Local Configuration Update Errors: 0

aVCS Show Commands
Remote Configuration Update Errors: 0

Configuration Update Notif Errors: 0
Configuration Update Result Errors: 0
vBlade:
Start Time: N/A
Receive Errors: 0
Send Errors: 0
Received Bytes: 0
Sent Bytes: 0
Received Messages: 0
Sent Messages: 0
Invalid Messages: 0
Received Keepalives: 0
Received Configuration Updates: 0
Last Configuration Update: N/A
Configuration Update Failures: 0
Field Description
Parameters Fields
Chassis-ID ID of the virtual chassis.
time-interval Number of seconds between transmission of keepalive messages from the vMaster to vBlades.
failure-retry-count Maximum number of retries allowed for the device to join the virtual chassis, before aVCS stops on
the device.
Floating-IPv4 Lists the IPv4 interfaces associated with the aVCS floating IP address.
Floating-IPv6 Lists the IPv6 interfaces associated with the aVCS floating IP address.
SSL-enabled State of SSL for management traffic between aVCS devices, Yes (enabled) or No (disabled).
Multicast-IP Multicast IP address used during aVCS vMaster election.
Multicast-Port Multicast port used during aVCS vMaster election.
Dev-ID For each device in the virtual chassis, shows the following aVCS configuration information:
• Dev-Prio – Priority of the device for vMaster election.
• Unicast-Port – Protocol port on which the device listens for aVCS management traffic.
• Interfaces – Device interfaces used for aVCS vMaster election traffic.
• Enabled – State of aVCS on the device.
Local-Dev-ID aVCS device ID (1-8) of the device on which this show command was issued.
Running Parameters Fields
These fields show the aVCS parameters currently in effect on the devices in the virtual chassis. The field descriptions are
the same as those under “Parameters” above.
The running parameters are listed separately in case an aVCS parameter is changed but the change is not yet saved. In this
case, the running parameter is in the running-config but not in the startup-config.

aVCS Show Commands
Field Description
Dev-State Field
Current aVCS state of this device. The state can be vMaster-candidate, vMaster, or vBlade.
Version Field
ACOS software version running on this device.
Config Field
Configuration tag and sequence number.
Election Context Fields
These fields show statistics and configuration information for vMaster election.
Stop-Request Number of times an administrator-initiated aVCS stop request was received.
Note: aVCS stop requests are initiated by a hidden diagnostic command used by A10 Networks for
troubleshooting. This counter is not incremented when you disable aVCS.
Parameters Lists the settings for the following parameters:
• Num-Sockets – Number of sockets used by the vMaster-election protocol. This number equals
the number of vMaster-election interfaces on this device.
• Dev-State – Election state of the device when the show vcs stat command was entered:
• vMaster-candidate – Election of the vMaster is in progress. During the vMaster election pro-
cess, all the devices in the virtual chassis are in the vMaster-candidate state.
• vMaster – vMaster election is complete, and this device is the vMaster.
• vBlade – vMaster election is complete, and this device is a vBlade.
• Dev-DynPrio – Dynamic vMaster-election priority value for the device.
• PDU-Seq – PDU sequence number. This number is incremented each time a vMaster-election
PDU is sent by this device.
• vMasterTakeOverPrio – Priority value assigned to the device to force vMaster reelection.
• vMaster-Sent / vBlade-Sent – Most recent system time when this device sent a vMaster PDU or
vBlade PDU, depending on the device’s aVCS state.
• Neighbor – Lists the following information about the most recent vMaster-election PDUs
received from each of the other devices in the virtual chassis. This information is listed separately
for each neighbor device.
• Ident – aVCS protocol ID, which is “VCE”.
• Version – aVCS protocol version.
• Type – PDU type: vMaster-candidate-pdu, vMaster-pdu, or vBlade-pdu.
• Length – PDU length.
• Seq – PDU sequence number.
• HW-Model – Hardware model of the device.
• Chassis-ID – Virtual chassis ID.
• Device-ID – aVCS device ID.
• Device-Prio – Configured vMaster-election priority.
• Device-DynPrio – Temporary vMaster election priority configured to force vMaster reelection.
• Config – Configuration tag and sequence number.
vMaster Context Fields
Note: vMaster Context fields appear only on the vMaster. On vBlade devices, vBlade Context fields appear instead. (See
below.)

aVCS Show Commands
Field Description
Server-Connection Shows information about the aVCS management connections with each of the other devices.
• Local-Addr – aVCS unicast address of this device.
• Remote-Addr – aVCS unicast address of the device at the other end of the connection.
• State – State of the connection:
• Closed
• Listen
• Accept
• Connecting
• Connected
• IO-State – State of the connection, R (read) or W (write).
• SSL – State of SSL on the connection, Yes (enabled) or No (disabled).
vBlade Shows the following information for each aVCS vBlade in the virtual chassis:
• ID – Internal index number for the device.
• Device-ID – aVCS ID of the device.
• vBlade-State – aVCS state of the vBlade:
• Ready
• Init
• Invalid
• Stop-Request – Number of times an administrator-initiated aVCS stop request was received.
Note: aVCS stop requests are initiated by a hidden diagnostic command used by A10 Networks
for troubleshooting. This counter is not incremented when you disable aVCS.
• Connection – Shows the following information about the device’s aVCS connection to the
vMaster:
• Local-Addr – IP address and protocol port of the device’s connection to the vMaster.
• Remote-Addr – IP address and protocol port on the vMaster.
• State – State of the aVCS connection to the vMaster:
– Closed
– Listen
– Accept
– Connecting
– Connected
• SSL – State of SSL on the connection:
– Yes (enabled)
– No (disabled)
vBlade Context Fields
Note: vBlade Context fields appear only on vBlades. On vMaster devices, vMaster Context fields appear instead. (See
above.)

aVCS Show Commands
Field Description
vMaster-Addr IP address and protocol port of the vMaster’s aVCS management interface.
Connection Shows the following information about the device’s aVCS connection to the vMaster:
• Local-Addr – IP address and protocol port of the device’s connection to the vMaster.
• Remote-Addr – IP address and protocol port on the vMaster.
• State – State of the aVCS connection to the vMaster:
• Closed
• Listen
• Accept
• Connecting
• Connected
• SSL – State of SSL on the connection, Yes (enabled) or No (disabled).
Counters Fields
Daemon Shows statistics for the aVCS process:
• Start Time – System time when the aVCS was started on this device.
• Election Started – Number of times vMaster election occurred after the aVCS process started.
• Election Stopped – Number of times vMaster election stopped.
The following statistics apply to communication between the aVCS process and the CLI or GUI.
• Receive Errors – Number of errors when the aVCS process received a request from the CLI or
GUI.
• Send Errors – Number of errors when the aVCS process sends a response to the CLI or GUI.
• Received Bytes – Number of bytes received from the CLI or GUI.
• Sent Bytes – Number of bytes sent to the CLI or GUI.
• Received Messages – Number of requests received from the CLI or GUI.
• Sent Messages – Number of responses sent to the CLI or GUI.
• Invalid Messages – Number of requests that were invalid.
• Message Handling Failure – Number of times handling of a request failed.

aVCS Show Commands
Field Description
Election Shows statistics for aVCS vMaster election:
• Start Time – System time when vMaster election started.
• Receive Errors – Number of errors in election PDUs received by this device.
• Send Errors – Number of times this device failed to send an election PDU.
• Received Bytes – Number of election PDU bytes received.
• Sent Bytes – Number of election PDU bytes sent.
• Received vMaster-PDU – Number of vMaster PDUs received.
• Received MC-PDU – Number of vMaster-candidate PDUs received.
• Received vBlade-PDU – Number of vBlade PDUs received.
• Received MTO-PDU – Number of vMaster-take-over PDUs received.
• Received Unknown-PDU – Number of Unknown PDUs received.
• Sent vMaster-PDU – Number of vMaster PDUs sent.
• Sent MC-PDU – Number of vMaster-candidate PDUs sent.
• Sent vBlade-PDU – Number of vBlade PDUs sent.
• Sent MTO-PDU – Number of vMaster-take-over PDUs sent.
• Sent Unknown-PDU – Number of Unknown PDUs sent.
• Invalid PDU – Number of invalid PDUs, such as short PDUs or PDUs with the wrong election ID.
• PDU HW mismatch – Number of PDUs in which the hardware model did not match this device’s
hardware model.
• PDU Chassis-ID mismatch – Number of PDUs in which the virtual chassis ID did not match.
• PDU Device-ID collision – Number of PDUs in which the other device’s aVCS device ID was the
same as this device’s aVCS device ID.
• MC, discarded vMaster-PDU – Number of vMaster PDUs discarded by this device when it was in
the vMaster-candidate state.
• MC, replaced vMaster-PDU – Number of vMaster PDUs replaced when this device was in the
vMaster-candidate state. A vMaster PDU is replaced when another vMaster PDU received from a
different device has more favorable vMaster election values.
(cont.)

aVCS Show Commands
Field Description
Election • MC, duplicate vMaster-PDU – Number of duplicate vMaster PDUs received when this device was
in the vMaster-candidate state.
(cont.)
• MC, timers reset by MC-PDU – Number of times vMaster election timers were reset because this
device received a vMaster-candidate PDU from another device with more favorable vMaster-
election values, when this device (the device on which the show stat command was entered)
was in the vMaster-candidate state.
• MC, timers reset by MTO-PDU – Number of times vMaster election timers were reset because
this device received a vMaster-takeover PDU from another device, when this device was in the
vMaster-candidate state. A vMaster-takeover PDU is generated by forced re-election.
• vBlade, duplicate vMaster-PDU – Number of times this device, when in the vBlade state,
received a duplicate vMaster PDU.
• vBlade, discard challenger – Number of times this device, when in the vBlade state, discarded a
PDU from a device with more favorable election values than the current vMaster.
• vBlade, replace challenger – Number of times this device, when in the vBlade state, replaced the
current vMaster with a new vMaster that had more favorable election values.
• vBlade, duplicate challenger – Number of times this device, when in the vBlade state, received a
vMaster PDU from a device with election values just as favorable as the current vMaster’s.
• vBlade, discard neighbor – Number of times this device, when in the vBlade state, discarded an
election PDU from another device in the virtual chassis.
• vBlade, too many neighbors – Number of times this device, when in the vBlade state, discarded
an election PDU because the virtual chassis contained more devices than the maximum
allowed.
• vBlade, duplicate neighbors – Number of times this device, when in the vBlade state, discarded
an election PDU because the other device’s aVCS ID was a duplicate.
• vMaster, discard challenger – Number of times this device, when in the vMaster state, discarded
a PDU from a device with more favorable election values.
(cont.)

aVCS Show Commands
Field Description
Election • vMaster, new challenger – Number of times this device, when in the vMaster state, received a
vMaster PDU from a device with more favorable election values.
(cont.)
• vMaster, replace challenger – Number of times this device, when in the vMaster state, remained
vMaster despite receiving a vMaster PDU from another device that had more favorable election
values.
• vMaster, duplicate challenger – Number of times this device, when in the vMaster state,
received a vMaster PDU from a device with election values just as favorable as the current vMas-
ter’s.
• vMaster, discard neighbor – Number of times this device, when in the vMaster state, discarded
an election PDU from another device in the virtual chassis.
• vMaster, too many neighbors – Number of times this device, when in the vMaster state, dis-
carded an election PDU because the virtual chassis contained more devices than the maximum
allowed.
• vMaster, duplicate neighbors – Number of times this device, when in the vMaster state, dis-
carded an election PDU because the other device’s aVCS ID was a duplicate.
• Enter MC – Number of times this device entered the vMaster-candidate state.
• Enter vBlade – Number of times this device entered the vBlade state.
• Enter vMaster – Number of times this device entered the vMaster state.
• Enter MTO – Number of times this device entered the vMaster-takeover state.
• Leave MC – Number of times this device left the vMaster-candidate state.
• Leave vBlade – Number of times this device left the vBlade state.
• Leave vMaster – Number of times this device left the vMaster state.
• Leave MTO – Number of times this device left the vMaster-takeover state.

aVCS Show Commands
Field Description
vMaster Shows vMaster statistics.
Note: These counters are applicable only when this device is the vMaster.
• Start Time – System time when this device became the vMaster. If the value is “N/A”, this device
is not the vMaster.
• Start vBlade Errors – Number of times this vMaster started a vBlade thread with another device.
• vBlades Started – Number of times this vMaster started a vBlade.
• vBlades stopped – Number of times this vMaster stopped a vBlade.
• Received Configuration Updates – Number of times this vMaster received a configuration
update from the aVCS process.
• Last Configuration Update – Latest system time when this vMaster received a configuration
update.
• Local Configuration Update Errors – Number of errors that occurred during local configuration
update.
• Remote Configuration Update Errors – Number of errors that occurred during remote configu-
ration update.
• Configuration Update Notif Errors – Number of configuration update notification errors.
• Configuration Update Result Errors – Number of configuration update result errors.
• vBlade – Shows the following statistics for each vBlade:
• Start Time – System time when the device became a vBlade.
• Receive Errors – Number of times the vMaster did not receive acknowledgement of a config-
uration synchronization request sent to the vBlade.
• Send Errors – Number of times transmission of a configuration synchronization request to the
vBlade failed.
• Received Bytes – Number of bytes for configuration update requests received from the
vBlade.
• Sent Bytes – Number of bytes for configuration update requests sent to the vBlade.
• Received Messages – Number of aVCS messages received from the device.
(cont.)

aVCS Show Commands
Field Description
vMaster • Sent Messages – Number of aVCS messages sent to the device.
(cont.) • Invalid Messages – Number of invalid aVCS messages received from the device.
• Received Keepalives – Number of keepalive messages received from the device.
• Received Configuration Updates – Number of configuration updates received from the
device.
• Last Configuration Update – System time when the most recent configuration update was
received from the device.
• Configuration Update Failures – Number of configuration update failures.
vBlade Shows vBlade statistics.
Note: These counters are applicable only when this device is a vBlade.
• Start Time – System time when this device became a vBlade. If the value is “N/A”, this device is
not a vBlade.
• Receive Errors – Number of times the device did not receive acknowledgement of a configura-
tion synchronization request.
• Send Errors – Number of times transmission of a configuration synchronization request failed.
• Received Bytes – Number of bytes for configuration update requests received by the device.
• Sent Bytes – Number of bytes for configuration update requests sent by the device.
• Received Messages – Number of aVCS messages received by the device.
• Sent Messages – Number of aVCS messages sent by the device.
• Invalid Messages – Number of invalid aVCS messages received by the device.
• Received Keepalives – Number of keepalive messages received by the device.
• Received Configuration Updates – Number of configuration updates received by the device.
• Last Configuration Update – System time when the most recent configuration update was
received by the device.
• Configuration Update Failures – Number of configuration update failures.
show vcs summary

Description Display aVCS virtual chassis information.
Syntax show vcs summary
Mode All
Example The following command shows summary aVCS information:
ACOS# show vcs summary
VCS Chassis:
VCS Enabled: Yes
Chassis ID: 3
Floating IP: 5.5.5.254
Mask: 255.255.255.0

aVCS Show Commands
Floating IP: 192.168.148.14

Mask: 255.255.255.0
Multicast IP: 224.0.0.210
Multicast Port: 41217
Version: 2.6.1.b478
Members(* means local device):

ID State Priority IP:Port Location
-------------------------------------------------------------------------------
1 vMaster(*) 200 192.168.148.16:41216 Local
2 vBlade 199 192.168.148.15:41216 Remote
Total: 2
Field Description
aVCS Chassis Fields
VCS Enabled State of the aVCS feature, Enabled or Disabled.
Chassis ID ID of the virtual chassis.
Floating IP IP interface associated with the virtual chassis floating IP address.
Mask Network mask of the Floating IP interface.
Multicast IP Multicast IP address used for aVCS vMaster election.
Multicast Port Protocol port used for vMaster election.
Version Software version and build running on the ACOS device.
Members Fields
ID aVCS ID of the member device.
State Current role of the device, vMaster or vBlade.
NOTE: If you enter this command in a session that is logged onto the aVCS floating IP address,
the “local device” is always the vMaster, unless you change the context ID of the management
session.
Priority vMaster election priority of the device.
NOTE: This is the admin-configured priority value, not the dynamic priority assigned by aVCS.
IP:Port IP address and protocol port used for configuration synchronization with the member device.
Location Indicates whether this is the device context on which you entered the show vcs summary
command:
• Local – This is the device context on which you entered the command.
• Remote – This is not the device context on which you entered the command.

aVCS Show Commands


8
Document No.: 410-VCS-001 | 2/16/2016

Vcs

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Vcs

Enviado por

Direitos autorais:

Formatos disponíveis

CONFIGURING ACOS VIRTUAL CHASSIS SYSTEMS

A10 Thunder Series and AX Series

A10 Networks Inc. Software License and End User Agreement

2. sublicense, rent or lease the Software.

Overview of aVCS ..................................................................................................................................................... 7

Deploying a Virtual Chassis .................................................................................................................................25

page 3 | Document No.: 410-VCS-001 - 2/16/2016

Forcing vMaster Takeover.............................................................................................................................................. 33

Adding a Device to a Virtual Chassis ................................................................................................................41

Replacing a Device in a Virtual Chassis ...........................................................................................................45

Configuration Synchronization without Reload ..........................................................................................47

aVCS CLI Commands .............................................................................................................................................51

Document No.: 410-VCS-001 - 2/16/2016 | page 4

show vcs debug ....................................................................................................................................................................................... 64

page 5 | Document No.: 410-VCS-001 - 2/16/2016

Document No.: 410-VCS-001 - 2/16/2016 | page 6

The following topics are covered:

• aVCS Configuration Management and Synchronization

• aVCS Software Image Synchronization

• Customizing the Virtual Chassis

• aVCS Image Location

• Memory Requirements for aVCS with Layer 3 Virtualization

page 7 | Document No.: 410-VCS-001 - 2/16/2016

aVCS Image Location

Memory Requirements for aVCS with Layer 3 Virtualization

TABLE 1 Memory Requirements for aVCS with Layer 3 Virtualization

Before performing a system-reset, always create a system backup of the ACOS

Document No.: 410-VCS-001 - 2/16/2016 | page 8

• Synchronize aFleX policies

• Synchronize black/white lists

• Synchronize code versions

FIGURE 1 vMaster - Control Point for all Devices

page 9 | Document No.: 410-VCS-001 - 2/16/2016

Virtual Chassis Management Interface (Floating IP Address)

For additional information, refer to “aVCS CLI-Session Management” on page 35.

aVCS Configuration Management

aVCS Software Version Management

The following topics are covered:

• Understanding vMaster Election

• vMaster Election During Initial (First-Time) Deployment

• vMaster Election Using Dynamic Priority

• vMaster Election and Heartbeat Messages

• vMaster Election and Split Chassis

• Forced vMaster Takeover

Document No.: 410-VCS-001 - 2/16/2016 | page 10

Understanding vMaster Election

• aVCS Initial Deployment

• VRRP-A Active/Standby Device Selection

• aVCS and VRRP-A vMaster Selection

aVCS Initial Deployment

VRRP-A Active/Standby Device Selection

For more information, see Configuring VRRP-A High Availability.

aVCS and VRRP-A vMaster Selection

page 11 | Document No.: 410-VCS-001 - 2/16/2016

vMaster Election During Initial (First-Time) Deployment

Document No.: 410-VCS-001 - 2/16/2016 | page 12

page 13 | Document No.: 410-VCS-001 - 2/16/2016

FIGURE 3 vMaster Election in Initial Deployment - Different Priority Values Configured

vMaster Election Using Dynamic Priority

Document No.: 410-VCS-001 - 2/16/2016 | page 14

FIGURE 4 vMaster Election with Dynamic Priority

page 15 | Document No.: 410-VCS-001 - 2/16/2016

vMaster Election and Heartbeat Messages

FIGURE 5 Heartbeat Messages