A10 Thunder AX 271-P2 Admin-2013.07.22

System
Configuration and Administration Guide
A10 Thunder™ Series and AX Series

Document No.: D-030-01-00-0024
ACOS 2.7.1 7/22/2013
©
2013 A10 Networks, Inc. - All Rights Reserved
Information in this document is subject to change without notice.
Trademarks
A10 Networks, A10 Thunder, vThunder, the A10 logo, aACI, aCloud, ACOS, aDCS, aDNS, aELB, aFleX, aFlow, aGalaxy,
aPlatform, aUSG, aVCS, aWAF, aXAPI, IDAccess, IDSENTRIE, IP to ID, SmartFlow, SoftAX, Thunder, Unified Service
Gateway, Virtual Chassis, VirtualADC, and VirtualN are trademarks or registered trademarks of A10 Networks, Inc. All
other trademarks are property of their respective owners.
Patents Protection
A10 Networks products including all AX Series products are protected by one or more of the following US patents and pat-
ents pending: 20120216266, 20120204236, 20120179770, 20120144015, 20120084419, 20110239289, 20110093522,
20100235880, 20100217819, 20090049537, 20080229418, 20080148357, 20080109887, 20080040789, 20070283429,
20070282855, 20070271598, 20070195792, 20070180101, 8423676, 8387128, 8332925, 8312507, 8291487, 8266235,
8151322, 8079077, 7979585, 7716378, 7675854, 7647635, 7552126
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 Software 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 infor-
mation is provided "as-is." The product specifications and features described in this publication are based on the latest
information available; however, specifications are subject to change without notice, and certain features may not be avail-
able 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 contact the manufacturer of that component. Always consult local authorities for regulations regarding proper dis-
posal of electronic components in your area.
Further Information
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10
Networks location, which can be found by visiting www.a10networks.com.
A10 Thunder Series and AX Series—System Guide
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid A10
Networks Regular and Technical Support service contracts, the A10 Net-
works Technical Assistance Center provides support services online and
over the phone.
Corporate Headquarters
A10 Networks, Inc.

3 West Plumeria Dr
San Jose, CA 95134 USA
Tel: +1-408-325-8668 (main)

Tel: +1-888-822-7210 (support – toll-free in USA)
Tel: +1-408-325-8676 (support – direct dial)
Fax: +1-408-325-8666
www.a10networks.com
Collecting System Information

Your A10 Networks device provides a simple method to collect configura-
tion and status information for Technical Support to use when diagnosing
system issues.
To collect system information, use either of the following methods.
USING THE GUI (RECOMMENDED)

1. Log into the GUI.
2. On the main page (Monitor Mode > Overview > Summary), click
. This option downloads a text log file.
3. Email the file as an attachment to support@a10networks.com.
Customer Driven Innovation 3 of 602

Document No.: D-030-01-00-0024 - ACOS 2.7.1 7/22/2013
USING THE CLI

1. Log into the CLI.
2. Enable logging in your terminal emulation application, to capture out-
put generated by the CLI.
3. Enter the enable command to access the Privileged EXEC mode of the
CLI. Enter your enable password at the Password prompt.
4. Enter the show techsupport command.
5. After the command output finishes, save the output in a text file.
6. Email the file as an attachment to support@a10networks.com.
Note: As an alternative to saving the output in a log file captured by your termi-
nal emulation application, you can export the output from the CLI using
the following command:
show techsupport export [use-mgmt-port] url
(For syntax information, see the CLI Reference for the software version
you are running.)
4 of 602 Customer Driven Innovation

About This Document
About This Document
This document describes features of the A10 Networks Advanced Core

Operating System (ACOS). These features are supported on the following
product lines:
• A10 ThunderTM Series Unified Application Service Gateway
• AX Series Advanced Traffic Manager / Application Delivery Controller.
FIGURE 1 A10 Thunder 6430
FIGURE 2 AX 5630
For details about feature support on specific models, see the release notes.

About This Document
User Documentation
Information is available for ACOS products in the following documents.
These documents are included on the documentation CD shipped with your
product, and also are available on the A10 Networks support site.
Basic Setup
• Installation Guides
• System Configuration and Administration Guide
Security Guides
• Management Access Security Guide
• Application Access Management and DDoS Mitigation Guide
• Web Application Firewall Guide
Application Delivery Guides

• Application Delivery and Server Load Balancing Guide
• Global Server Load Balancing Guide
References
• LOM Reference
• GUI Reference
• CLI Reference
• aFleX Reference
• MIB Reference
• aXAPI Reference
Make sure to use the basic deployment instructions in the Installation Guide
for your Thunder or AX model, and in the System Configuration and
Administration Guide. Also make sure to set up your device’s Lights Out
Management (LOM) interface, if applicable.
Note: Some guides include GUI configuration examples. In these examples,

some GUI pages may have new options that are not shown in the example
screen images. In these cases, the new options are not applicable to the
examples. For information about any option in the GUI, see the GUI Ref-
erence or the GUI online help.

About This Document
Audience
This document is intended for use by network architects for determining
applicability and planning implementation, and for system administrators
for provision and maintenance of A10 Networks products.
Documentation Updates
Updates to these documents are published periodically to the A10 Networks
support site, on an updated documentation CD (posted as a zip archive). To
access the latest version, please log onto your A10 support account.
http://www.a10networks.com
A10 Virtual Application Delivery Community

You can use your A10 support login to access the A10 Virtual Application
Delivery Community (VirtualADC). The VirtualADC is an interactive
forum where you can find detailed information from product specialists.
You also can ask questions and leave comments. To access the VirtualADC,
navigate here:
http://www.a10networks.com/adc/

About This Document

Contents
Obtaining Technical Assistance 3

Collecting System Information.............................................................................................................. 3
About This Document 5

User Documentation............................................................................................................................... 6
Audience.................................................................................................................................................. 7
Documentation Updates ........................................................................................................................ 7
A10 Virtual Application Delivery Community....................................................................................... 7
System Overview 23
A10 Thunder Series and AX Series Features..................................................................................... 23
ACOS Architecture ............................................................................................................................... 26
ACOS Software Processes ............................................................................................................. 27
Memory Pre-allocation .................................................................................................................... 28
Hardware Interfaces ............................................................................................................................. 28
Software Interfaces............................................................................................................................... 28
Server Load Balancing Features......................................................................................................... 29
Intelligent Server Selection ............................................................................................................. 30
SLB Configuration Templates ......................................................................................................... 30
Outbound Link Load Balancing ....................................................................................................... 32
Transparent Cache Switching ......................................................................................................... 32
Firewall Load Balancing .................................................................................................................. 32
Where Do I Start?.................................................................................................................................. 33
SoftAX 35
SoftAX for Multiple Hypervisors.......................................................................................................... 35
Standardized Parameter Limits for SoftAX Models ........................................................................ 38
SoftAX for Citrix XenServer 5.6........................................................................................................... 39
Application Delivery Partition Support............................................................................................... 39
Single-interface Mode for SoftAX (VMware only) .............................................................................. 39
AX-V 41
Installation Overview ....................................................................................................................... 42

Contents
Basic Setup 43
Logging On ............................................................................................................................................43
Logging Onto the CLI ..................................................................................................................... 45
Logging Onto the GUI .................................................................................................................... 46
Configuring Basic System Parameters ...............................................................................................49
Setting the Hostname and Other DNS Parameters ........................................................................ 49
Setting the CLI Banners ................................................................................................................. 50
Setting Time/Date Parameters ....................................................................................................... 52
Setting the NTP Server Authentication ....................................................................................... 54
CLI Example ............................................................................................................................... 56
Setting the NTP Server Preference ............................................................................................. 56
CLI Example ............................................................................................................................... 57
Configuring Syslog Settings ........................................................................................................... 58
Single-priority Logging ................................................................................................................ 60
Log Rate Limiting ........................................................................................................................ 61
Enabling SNMP .............................................................................................................................. 63
SNMP Traps ................................................................................................................................ 65
SNMP Communities and Views .................................................................................................. 67
SNMP Configuration Steps ......................................................................................................... 68
SNMP Source Interface for Notifications ..................................................................................... 71
Console Restart .............................................................................................................................. 72
Configuration Examples .......................................................................................................................73
Replacing the Web Certificate..............................................................................................................78
Emailing Log Messages........................................................................................................................80
Increased I/O Buffer Support ...............................................................................................................85
Network Setup 87
Overview ................................................................................................................................................87
Trunk Support ................................................................................................................................. 87
Virtual LAN Support ........................................................................................................................ 88
IP Subnet Support .......................................................................................................................... 89
Routing Support ............................................................................................................................. 90
Gateway Health Monitoring ............................................................................................................ 90
Partitioning with ADPs .................................................................................................................... 90
High Availability .............................................................................................................................. 91

Contents
Management Interface Configuration ................................................................................................. 91
Configuration Example ................................................................................................................... 92
Transparent Mode Deployment ........................................................................................................... 95
Route Mode Deployment...................................................................................................................... 97
Jumbo Frames 101
Link Trunking 107

Overview.............................................................................................................................................. 107
Static Trunk Configuration................................................................................................................. 108
Trunk Parameters and Trunk Interface Parameters ..................................................................... 110
Configuring Trunk Parameters ...................................................................................................... 111
Adding Ports to a Trunk ............................................................................................................. 111
Configuring Port-threshold Parameters ..................................................................................... 111
Configuring Interface-level Parameters on a Static Trunk ......................................................... 112
Static Trunk Configuration Example ............................................................................................. 113
Dynamic Trunk Configuration ........................................................................................................... 114
LACP Parameters ......................................................................................................................... 114
UDLD ......................................................................................................................................... 116
Configuration ................................................................................................................................ 117
Minimum Port Threshold for LACP ............................................................................................... 119
Monitoring LACP via the GUI .................................................................................................... 121
LACP Passthrough ............................................................................................................................. 126
Configuration ................................................................................................................................ 128
Displaying LACP Information ........................................................................................................ 128
Clearing LACP Statistics ............................................................................................................... 129
Configuration Example ...................................................................................................................... 129
Link Monitoring with Automated Link Disable

or Session Clear 135
Configuration ................................................................................................................................ 137
Using the CLI ............................................................................................................................. 137

Contents
Link Layer Discovery Protocol 141

Overview ..............................................................................................................................................141
Configuration.......................................................................................................................................142
LLDP Configuration Example ....................................................................................................... 143
Bidirectional Forwarding Detection 145

BFD Parameters ..................................................................................................................................146
Static Route Support...........................................................................................................................147
Configure BFD with OSPF (for IPv4) .................................................................................................149
Configure BFD with OSPF (for IPv6) .................................................................................................150
Configure BFD with IS-IS (for IPv4) ...................................................................................................151
Sample Configuration ................................................................................................................ 152
Configure BFD with IS-IS (for IPv6) ...................................................................................................153
Configure BFD with BGP ....................................................................................................................154
Configuring Static BFD.......................................................................................................................154
Configuration of BFD Intervals ..........................................................................................................155
Authentication .....................................................................................................................................156
Enable Echo and Demand function ...................................................................................................157
Viewing BFD Status ............................................................................................................................158
Gateway Health Monitoring 165

Overview ..............................................................................................................................................165
Configuration.......................................................................................................................................167
Open Shortest Path First (OSPF) 169

Support for Multiple OSPFv2 and OSPFv3 Processes ....................................................................169
Support for OSPFv2 and OSPFv3 on the Same Interface or Link ..................................................169
OSPF MIB Support ..............................................................................................................................169
OSPF Configuration Example ............................................................................................................170
Interface Configuration ................................................................................................................. 170
Global OSPF Parameters ............................................................................................................. 171
Clearing Specific OSPF Neighbors .............................................................................................. 172
OSPF Logging .............................................................................................................................. 174
Configuring Router Logging for OSPF ...................................................................................... 174

Contents
DHCP and DHCP Relay 181

DHCP Overview................................................................................................................................... 181
Configuring DHCP ........................................................................................................................ 182
DHCP Relay Overview ........................................................................................................................ 182
Configuring DHCP Relay .............................................................................................................. 183
Internet Group Multicast Protocol Queries 189

Configuring IGMP Membership Queries ....................................................................................... 190
Application Delivery Partitions 193

Overview.............................................................................................................................................. 193
Partition Benefits ........................................................................................................................... 194
Types of Partitions ........................................................................................................................ 196
Hardware-Supported Number of Partitions ................................................................................... 196
Supported RBA and L3V Partitions Per ACOS Device ................................................................. 197
Partition Logos .............................................................................................................................. 198
Partition-Based Logging ............................................................................................................... 199
Partition-Based Banners ............................................................................................................... 199
Limiting Resources for Partitions Using Templates ...................................................................... 200
Administering Private Partitions .................................................................................................... 200
Administrative Roles ..................................................................................................................... 200
Administering the Shared Partition ............................................................................................... 201
Additional Administrative Capabilities ....................................................................................... 203
Configuring a Custom GUI Access Role ....................................................................................... 204
Configuring Partition Admin Accounts .......................................................................................... 204
Disabling Private Partition Admin Access to the Shared Partition ................................................ 206
Configuring Private Partitions ....................................................................................................... 208
Deleting a Partition ....................................................................................................................... 208
Viewing and Saving the Configuration ............................................................................................. 209
Viewing the Configuration ............................................................................................................. 209
Saving the Configuration .............................................................................................................. 210
Switching To Another Partition ......................................................................................................... 211
Synchronizing the Configuration ...................................................................................................... 212
Manual Synchronization ............................................................................................................... 212
Operator Management of Real Servers ............................................................................................ 214
To Disable or Re-Enable Servers .............................................................................................. 216
To Disable or Re-Enable Real Service Ports ............................................................................ 217

Contents
Role Based Administration Private Partition 219

Overview ..............................................................................................................................................219
Resources Contained in RBA Private Partitions .......................................................................... 220
Migrating Resources Between Partitions ..................................................................................... 221
Simple RBA Partition Configuration..................................................................................................221
Creating Private Partitions ........................................................................................................ 222
Example 2: Multiple RBA Partition Configuration ...................................................................... 225
Layer 3 Virtualization of Private Partitions 227

Overview ..............................................................................................................................................227
L3V Advantages ........................................................................................................................... 228
Resources Contained in L3V Private Partitions ........................................................................... 229
Layer 2/3 Virtualization ................................................................................................................. 230
Jumbo Frame Support .............................................................................................................. 231
Requirements ............................................................................................................................ 231
Per-partition Feature Support for Layer 2/3 Virtualization ......................................................... 234
Per-partition Default SLB Templates for Layer 2/3 Virtualization .............................................. 235
Limitations ................................................................................................................................. 235
L3V Partition Configuration................................................................................................................236
Creating Private Partitions ........................................................................................................ 236
Configuration Examples .....................................................................................................................239
Example 1: Simple L3V Partition Configuration ........................................................................ 239
Example 2: Enabling Layer2/3 Virtualization ............................................................................. 242
Example 3: Configuring Partition-Specific Layer 2/3 Resources ............................................... 242
Resource Templates for L3V Partitions 247

Overview ..............................................................................................................................................247
Resource Template Parameters .................................................................................................. 247
Application Resource Parameters ............................................................................................. 248
Network Resource Parameters ................................................................................................. 248
System Resource Parameters .................................................................................................. 249
Creating a System Resource Template ....................................................................................... 251
Assigning Resource Limits ........................................................................................................ 252
Applying a System Resource Template to a Partition .................................................................. 254
Removing a Resource Template from a Partition ........................................................................ 256
Contradictory Resource Usage Scenario ..................................................................................... 257

Contents
Inter-Partition Routing 259

Configuration ................................................................................................................................ 260
Configuration Example ................................................................................................................. 260
Configuration in the Shared Partition ........................................................................................ 261
Configuration in the Private Partition ......................................................................................... 263
SLB configuration within a Private Partition .............................................................................. 265
High Availability 267

Overview.............................................................................................................................................. 267
Layer 3 Active-Standby HA ........................................................................................................... 269
Layer 3 Active-Active HA .............................................................................................................. 271
Layer 2 Active-Standby HA (Inline Deployment) .......................................................................... 273
Preferred HA Port ...................................................................................................................... 275
Port Restart ............................................................................................................................... 276
Layer 3 Active-Standby HA (Inline Deployment) .......................................................................... 278
HA Messages ............................................................................................................................... 279
HA Heartbeat Messages ........................................................................................................... 280
Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6) ...................................... 280
HA Interfaces ................................................................................................................................ 281
VLAN ID Requirement ............................................................................................................... 283
Session Synchronization .............................................................................................................. 283
Optional Failover Triggers ............................................................................................................ 284
VLAN-based Failover ................................................................................................................ 284
Gateway-based Failover ........................................................................................................... 285
Route-based Failover ................................................................................................................ 285
Real Server or Port Health-based Failover ............................................................................... 286
VIP-based Failover .................................................................................................................... 286
How the Active ACOS Device Is Selected .................................................................................... 288
HA Pre-Emption ............................................................................................................................ 290
HA Sets ......................................................................................................................................... 291
HA Configuration Parameters ....................................................................................................... 292
HA Status Indicators .......................................................................................................................... 299
In the GUI .................................................................................................................................. 299
Configuring Layer 3 HA...................................................................................................................... 301
Configuring Layer 2 HA (Inline Mode) .............................................................................................. 311
Layer 2 Inline HA Configuration Example ..................................................................................... 312
Configuring Layer 3 HA (Inline Mode) .............................................................................................. 319
Layer 3 Inline HA Configuration Example ..................................................................................... 320

Contents
Configuring Optional Failover Triggers ............................................................................................324
VLAN-Based Failover Example .................................................................................................... 325
Gateway-Based Failover Example ............................................................................................... 326
Route-Based Failover Example .................................................................................................... 327
VIP-Based Failover Example ....................................................................................................... 329
Forcing Active Groups to Change to Standby Status .....................................................................331
Enabling Session Synchronization ...................................................................................................332
Configuring OSPF-Related HA Parameters ......................................................................................333
OSPF Awareness of HA ............................................................................................................... 333
OSPF Support on Standby ACOS Device in Layer 3 Inline Mode ............................................... 335
Manually Synchronizing Configuration Information........................................................................335
Configuration Items That Are Backed Up ..................................................................................... 336
Configuration Items That Are Not Backed Up ........................................................................... 337
Performing HA Synchronization ................................................................................................... 339
Tip for Ensuring Fast HA Failover .....................................................................................................341
HA To VRRP-A Migration 345

Migration Exceptions .................................................................................................................... 346
Differences between HA and VRRP-A ......................................................................................... 347
Migrating from HA to VRRP-A ...................................................................................................... 350
Reverting to HA from VRRP-A ..................................................................................................... 352
VRRP-A High Availability 355

Overview ..............................................................................................................................................355
Virtual Router ID ........................................................................................................................... 355
Partition Support ....................................................................................................................... 356
Default VRID ............................................................................................................................. 357
Non-Default VRID ..................................................................................................................... 357
Leader and Follower VRIDs ...................................................................................................... 357
VRID Virtual MAC Addresses ................................................................................................... 358
Floating IP Addresses .................................................................................................................. 359
Configuration Synchronization ..................................................................................................... 360
Session Synchronization .............................................................................................................. 360
Active / Standby Device Selection ................................................................................................ 361
Failover ......................................................................................................................................... 363
Policy-based Failover ................................................................................................................ 364
VRRP-A Hello Messages .......................................................................................................... 364
Dynamic Priority Reduction ....................................................................................................... 365
Pre-emption .............................................................................................................................. 367
Force-self-standby .................................................................................................................... 368

Contents
VRRP-A Interfaces ....................................................................................................................... 368
Explicitly Configured VRRP-A Interfaces (optional) .................................................................. 369
Preferred Receive Interface for Session Synchronization ......................................................... 370
Comparison of VRRP-A and HA ................................................................................................... 370
VRRP-A Parameters ..................................................................................................................... 372
Deploying VRRP-A.............................................................................................................................. 376
Specify the VRRP-A Device ID ..................................................................................................... 376
Configuring Floating IP Addresses for VRRP-A VRIDs ................................................................ 376
Enable VRRP-A ............................................................................................................................ 377
Force-Self-Standby Reload or Restart Persistence ...................................................................... 377
Displaying VRRP-A Information .................................................................................................... 378
Manually Synchronizing the Configuration...................................................................................... 379
VRRP-A Information Included ....................................................................................................... 379
Peer IP Address Option ................................................................................................................ 380
Configuration Examples .................................................................................................................... 384
Simple Deployment ....................................................................................................................... 384
Deployment with Custom Priority Settings .................................................................................... 384
Configuration of Tracking Options ................................................................................................ 386
Increased VLANs for VRRP-A- Failover Tracking ..................................................................... 388
Configuring the Non-default VRID ................................................................................................ 391
Configuring a Leader and Follower VRID ..................................................................................... 392
VRRP-A Status in CLI Prompt ...................................................................................................... 394
VRRP-A Configuration and Monitoring

Using the GUI 397
Configuration ...................................................................................................................................... 398
Configuring VRRP-A Global Parameters ...................................................................................... 398
General ...................................................................................................................................... 399
VRID .......................................................................................................................................... 401
Floating IP Address ................................................................................................................... 402
VRRP-A Tracking ...................................................................................................................... 403
Preferred Session Sync Port ..................................................................................................... 405
VRID Leader .............................................................................................................................. 406
Force Self Standby .................................................................................................................... 407
Configuring VRRP-A Interface Parameters .................................................................................. 408
GUI Configuration Examples ........................................................................................................ 410
Simple GUI Deployment ............................................................................................................ 410
Deployment with Custom Priority Settings .................................................................................... 411
Configuration of GUI Tracking Options ......................................................................................... 418
Monitoring the VRRP-A VRID ....................................................................................................... 426
Monitoring VRRP-A Status ........................................................................................................... 427

Contents
VRRP-A Policy-Based Failover Template 429

Events Tracked for Weight via the Templates .............................................................................. 435
Configuring VRRP-A Policy-Based Failovers ............................................................................... 436
Failover Policy Template Error Message ..................................................................................... 443
VRRP-A Failover Policy Template Configuration Examples ........................................................ 443
Failover Policy Template in a Private Partition ............................................................................. 445
Show Command Configuration Examples .................................................................................... 446
ACOS Virtual Chassis System 451

Overview ..............................................................................................................................................452
High Availability ............................................................................................................................ 455
VRRP-A ........................................................................................................................................ 455
vMaster Election ........................................................................................................................... 456
Heartbeat Messages ................................................................................................................. 461
Forced vMaster Takeover ......................................................................................................... 462
Automated Configuration Synchronization ................................................................................... 463
Manual Configuration Synchronization ..................................................................................... 466
Software Image Synchronization .................................................................................................. 466
Virtual Chassis Management Interface ........................................................................................ 467
Requirements ............................................................................................................................... 468
aVCS Parameters ................................................................................................................................469
Deploying a Virtual Chassis (first-time deployment only)...............................................................471
Details for step 1 .......................................................................................................................... 472
Monitoring Mode ....................................................................................................................... 477
First-Time Deployment Example .................................................................................................. 481
Forcing vMaster Takeover ............................................................................................................ 482
Determining a Device’s aVCS ID ................................................................................................. 483
Displaying aVCS Information ....................................................................................................... 483
aVCS CLI-session Management Enhancements ......................................................................... 484
CLI Message for Commands That Affect Only the Local Device .............................................. 484
Option To Configure aVCS Master Affinity to VRRP-A Active .................................................. 485
Option To Display Information for the Active VRRP-A Device .................................................. 488
Option to Disable Syncing of SNMP syscontact OID ................................................................ 491
vMaster Maintenance Mode ...................................................................................................... 491
Configurable aVCS Message Buffer ......................................................................................... 492
Upgrading a Virtual Chassis ..............................................................................................................493
Adding a Configured ACOS Device to a Virtual Chassis.................................................................493
Overview ...................................................................................................................................... 495
Procedure ..................................................................................................................................... 500

Contents
Replacing a Device in a Virtual Chassis........................................................................................... 500
Configurable aVCS Prompts ......................................................................................................... 501
Configuration Synchronization without Reload 505

VRRP-A with aVCS Deployment Example ................................................................................ 506
HA with aVCS Deployment Example ........................................................................................ 507
Note Regarding HA Group ID .................................................................................................... 508
Network Address Translation 509

Overview.............................................................................................................................................. 509
Configuring Dynamic IP Source NAT................................................................................................ 511
Configuring Static IP Source NAT..................................................................................................... 517
NAT ALG Support for PPTP ............................................................................................................... 520
Configuring NAT ALG for PPTP ................................................................................................... 521
Faster Timeout for TCP/UDP IP NAT Translations ................................................................... 524
Mapping Allocation Method............................................................................................................... 524
Fast Aging for IP NATted ICMP and DNS Sessions......................................................................... 525
Client and Server TCP Resets for NATted TCP Sessions............................................................... 527
Requirements for Translation of DNS Traffic ................................................................................... 527
Pool-specific TCP Maximum Segment Life...................................................................................... 527
IP NAT Use in Transparent Mode in Multi-Netted Environment ..................................................... 529
NAT Range List Requires ACOS Device Interface
or Route Within the Global Subnet ................................................................................................... 530
IP NAT in HA Configurations ............................................................................................................. 530
Configuring Dynamic IP NAT with Many Pools................................................................................ 531
Configure NAT Pools .................................................................................................................... 531
Configure LIDs .............................................................................................................................. 531
Configure a Class List ................................................................................................................... 532
Class List Syntax ....................................................................................................................... 532
Importing a Class List ................................................................................................................ 532
Configuring a Class List Using the CLI ...................................................................................... 533
Enable Inside Source NAT ........................................................................................................... 534
Configuration Example ................................................................................................................. 534

Contents
Specifying the Source Interface for Management Traffic 537

Management Interface as the Source for Management Traffic .......................................................537
Route Tables ................................................................................................................................ 537
Management Routing Options ...................................................................................................... 538
Management Interface as Source for Automated Management Traffic .................................... 539
Management Interface as Source Interface for Manually Generated
Management Traffic .................................................................................................................. 540
Commands at the User EXEC Level ......................................................................................... 540
Commands at the Privileged EXEC Level ................................................................................. 540
Commands at the Global Configuration Level .......................................................................... 540
Show Commands ...................................................................................................................... 541
Using a Loopback Interface as the Source for Management Traffic ............................................ 541
Boot Options 545

Storage Areas ......................................................................................................................................545
Displaying Storage Information .................................................................................................... 546
Displaying the Storage Location for Future Reboots .................................................................... 549
Booting from a Different Storage Area..............................................................................................550
Temporarily Changing the Boot Image for the Next Reboot ........................................................ 550
Permanently Changing the Storage Location for Future Reboots ................................................ 552
Configuration Management 557

Backing Up System Information ........................................................................................................557
Saving Multiple Configuration Files Locally.....................................................................................559
Configuration Profiles ................................................................................................................... 560
Power On Auto Provisioning 569

Configuration ................................................................................................................................ 570
System Center Operations Manager Support 573

Configuration ................................................................................................................................ 574
Multiple Port-monitoring Mirror Ports 577

Port Monitoring and Mirroring for aVCS Devices ......................................................................... 580

Contents
VLAN-to-VLAN Bridging 581

Overview.............................................................................................................................................. 581
Configuration ...................................................................................................................................... 582
FIPS Support 585

FIPS-Compliant and FIPS-Certified ACOS Devices......................................................................... 585
FIPS Compliance for Hardware ......................................................................................................... 586
SSL Modules ................................................................................................................................ 586
Tamper-Proof Seals ...................................................................................................................... 586
Changes to ACOS Device Chassis .............................................................................................. 588
FIPS Compliance for SSL................................................................................................................... 588
FIPS Compliance for Software .......................................................................................................... 589
Software Upgrade Image .............................................................................................................. 589
Ports ............................................................................................................................................. 589
RMAs ............................................................................................................................................ 589
Lost Passwords ............................................................................................................................ 590
Web Support for FIPS Compliance ................................................................................................... 590
CLI Support for FIPS Compliance ..................................................................................................... 590
FIPS-compliant Web Server............................................................................................................... 591
Fail-safe Automatic Recovery 593

Error Types Monitored by Automatic Recovery .............................................................................. 593
Hardware Errors ........................................................................................................................... 593
Software Errors ............................................................................................................................. 594
Recovery Timeout............................................................................................................................... 594
Configuration ...................................................................................................................................... 595

Contents

A10 Thunder Series and AX Series Features
System Overview
This chapter provides a brief overview of the A10 Thunder Series and
AX Series system and features. For more information, see the other chapters
in this guide.

Key features of the A10 Thunder Series and AX Series include the follow-
ing.
Note: Support for some features depends on ACOS device model or software
version. The specific models and software versions required are listed in
the detailed sections for the features.
• Application Delivery Features
• Comprehensive IPv4/IPv6 Support
• Advanced Layer 4/Layer 7 Server Load Balancing

• Fast HTTP, Full HTTP Proxy
• High-performance, template-based Layer 7 switching with
header/URL/domain manipulation
• Comprehensive Layer 7 application persistence support
• Comprehensive load balancing methods

• Round Robin, Least Connections, Weighted RR, Weighted LC,
and Fastest Response
• aFleX – deep packet inspection and transformation for customiz-
able, and application-aware switching
• Advanced Health Monitoring
• Comprehensive Protocol Support
– ICMP, TCP, UDP, HTTP, HTTPS, FTP, RTSP, SMTP, POP3,
SNMP, DNS, RADIUS, and LDAP
• TCL Scriptable Health Check Support
• High Availability – Active-Active, Active-Standby configura-
tions with sub-second failover
• SIP Load Balancing for VoIP and other rich-media applications
• STARTTLS support for Secure Email (POPS, SMTPS, IMAPS)
& LDAPS

• Spam Filter Support – high-speed application of very large
black/white lists
• Firewall Load Balancing (FWLB)
• Global Server Load Balancing (GSLB)
• Transparent Cache Switching (TCS)
• Link Load Balancing (LLB)
• Diameter AAA Load Balancing
• Database Load Balancing
• Acceleration and Security Features

• HTTP Acceleration and Optimization
• HTTP Connection Multiplexing
• HTTP Caching
• HTTP Compression
• SSL Acceleration
• Hardware-based SSL Offload
• Support for all TCP Protocols – SSL Termination, SSL Bridging
(SSL Initiation)
• TLS 1.2 and 4096-bit SSL key support
• SSL Session ID Reuse
• Hardware-based SYN Cookies, IP Anomaly Detection
• Connection Rate Limiting/Connection Limiting
• DNS Application Firewall
• SSL Intercept
• Web Application Firewall (WAF)
• Application Access Management (AAM)
• High Performance and Scalable Platform
• ACOS Operating System

• Multi-core, Multi-CPU support
• Linear Application Scaling
• Linux on Control Plane
• ACOS on Data Plane

• Networking
• Integrated Layer 2/Layer 3
• Transparent Mode/Gateway Mode
• Routing – Static Routes, IS-IS (v4/v6), RIPv2/ng, OSPF v2/v3, and

BGP4+
• VLAN (802.1Q)
• Trunking (802.1AX), LACP
• Access Control Lists (ACLs)
• Traditional IPv4-->IPv4 NAT/NAPT
• IPv6-->IPv6 NAPT
• Jumbo frame support
• Management
• Dedicated management interface (Console, SSH, Telnet, HTTPS)
• Web-based Graphical User Interface (GUI) with Language Local-

ization
• Industry-standard Command Line Interface (CLI)
• SNMP, Syslog, and Email Alerts
• Port Mirroring
• REST-style XML API (aXAPI)
• LDAP, TACACS+, and RADIUS Support
• Virtualization
• aVCS (AX Virtual Chassis System)
• SoftAX Virtual Appliance
• Multi-tenancy with Application Delivery Partitions (ADPs)

• Role-based Administration (RBA)
• Partition-based Management
• L2/L3 Virtualization
• Hypervisor acceleration and management integration

ACOS Architecture
• Carrier-grade hardware (specific options depend on model)
• Advanced hardware architecture
• Redundant Power Supplies
• AC or DC Power Supplies
• Smart Fans (hot swap)
• Solid-state drive (SSD) and Compact Flash
• High Port Density
• 40 Gb and 10 Gb Ports
• Tamper Detection
• Lights Out Management (LOM/IPMI)
ACOS Architecture
A10 Thunder Series and AX Series devices use embedded Advanced Core
Operating System (ACOS) architecture. ACOS is built on top of a set of
Symmetric Multi-Processing CPUs and uses shared memory architecture to
maximize application data delivery.
ACOS is designed to handle high-volume application data with integrated

Layer 2 / Layer 3 processing and integrated SSL acceleration built into the
system. In addition, ACOS incorporates the A10 Networks customizable
aFleX scripting language, which provides administrators with configuration
flexibility for application data redirection.
ACOS inspects packets at Layers 2, 3, 4, and 7 and uses hardware-assisted

forwarding. Packets are processed and forwarded based on ACOS configu-
ration.
You can deploy the ACOS device into your network in transparent mode or
gateway (route) mode.
• Transparent mode – The ACOS device has a single IP interface. For
multinetted environments, you can configure multiple Virtual LANs
(VLANs).
• Route mode – Each ACOS interface is in a separate IP subnet.

ACOS Architecture
ACOS Software Processes

The ACOS software performs its many tasks using the following processes:
• a10mon – Parent process of the ACOS device. This process is executed
when the system comes up. The a10mon process does the following:
• Brings user-space processes up and down.
• Monitors all its child processes and restarts a process and all depen-
dent processes if any of them die.
• syslogd – System logger daemon that logs kernel and system events.
• a10logd – Fetches all the logs from the ACOS Log database.
• a10timer – Schedules and executes scheduled tasks.
• a10stat – Monitors the status of all the main processes of the ACOS
device, such as a10switch (on models AX 2200 and higher) and a10lb.
The a10stat process probes every thread within these processes to ensure
that they are responsive. If a thread is deemed unhealthy, a10stat kills
the process, after which a10mon restarts the process and other processes
associated with it.
• a10switch – Contains libraries and APIs to program the Switching ASIC
to perform Layer 2 and Layer 3 switching at wire speed.
• a10hm – Performs health-checking for real servers and services. This
process sends pre-configured requests to external servers at pre-defined
intervals. If a server or individual service does not respond, it is marked
down. Once the server or service starts responding again, it is marked
up.
• a10rt – Routing daemon, which maintains the routing table with routes
injected from OSPF, as well as static routes.
• a10rip – Implements RIPv1 and v2 routing protocols.
• a10ospf – Implements the OSPFv2 routing protocol.
• a10snmpd – SNMPv2c and v3 agent, which services MIB requests.
• a10wa – Embedded Web Server residing on the ACOS device. This pro-
cess serves the Web-based management Graphical User Interface (GUI).
• a10gmpd – Global SLB (GSLB) daemon.
• a10snpm_trapd – Handles SNMP traps initiated by a10lb.
• a10lb – The heart of the ACOS device. This process contains all the
intelligence to perform Server Load Balancing.

Hardware Interfaces
• rimacli – This process is automatically invoked when an admin logs into
the ACOS device through an interface address. The admin is presented a
Command Line Interface (CLI) that can issue and save commands to
configure the system.
Memory Pre-allocation
As part of normal operation, ACOS pre-allocates memory. For this reason,
memory utilization can be high even when the device first boots up. The
system allocates more memory if needed for burst conditions. In this case,
the additional memory is freed only slowly, in case further burst conditions
occur.
Hardware Interfaces
See the Installation Guide for your A10 Thunder or ACOS model.
Software Interfaces
The ACOS device supports the following management interfaces:
• Graphical User Interface (GUI)
• Command Line Interface (CLI) accessible using console, Telnet, or

Secure Shell (v1 and v2)
• Simple Network Management Protocol (SNMP) v1, v2c, and v3
• XML Application Programming Interface (aXAPI)
The configuration examples in this manual show how to configure the

A10 Thunder Series and AX Series using the CLI and GUI. For more infor-
mation about the ACOS management interfaces, see the following docu-
ments:
• GUI Reference
• CLI Reference
• MIB Reference
• aXAPI Reference

Server Load Balancing Features

Server Load Balancing (SLB) is a suite of resource management features
that make server farms more reliable and efficient.
You can easily grow server farms in response to changing traffic flow, while
protecting the servers behind a common virtual IP address. From the per-
spective of a client who accesses services, requests go to and arrive from a
single IP address. The client is unaware that the server is in fact multiple
servers managed by an ACOS device. The client simply receives faster,
more reliable service.
Moreover, you do not need to wait for DNS entries to propagate for new
servers. To add a new server, you simply add it to the configuration for the
virtual server, and the new real server becomes accessible immediately.
FIGURE 2 SLB Example

Intelligent Server Selection

The services managed by the ACOS device are controlled by service
groups. A service group is a set of real servers. The ACOS device selects a
real server for a client’s request based on a set of tunable criteria including
server health, server response time, and server load. These criteria can be
tuned for individual servers and even individual service ports.
The ACOS device provides a robust set of configurable health monitors for
checking the health (availability) of servers and individual services.
SLB Configuration Templates

SLB configuration is simplified by the use of templates. Templates simplify
configuration by enabling you to configure common settings once and use
them in multiple service configurations. The ACOS device provides tem-
plates to control server and port configuration parameters, connectivity
parameters, and application parameters.
Server and Port Configuration Templates

The ACOS device provides the following types of server and port configu-
ration templates:
• Server – Controls parameters for real servers
• Port – Controls parameters for service ports on real servers
• Virtual server – Controls parameters for virtual servers
• Virtual port – Controls parameters for service ports on virtual servers
Connectivity Templates
The ACOS device provides the following types of connectivity templates:
• TCP-Proxy – Controls TCP/IP stack parameters
• TCP – Controls TCP connection settings such as the idle timeout for
unused sessions, and specifies whether the ACOS device sends TCP
Resets to clients or servers after a session times out
• UDP – Controls UDP connection settings such as the idle timeout for
unused sessions, and specifies how quickly sessions are terminated after
a server response is received

Application Templates
The following types of application templates are provided:
• DBLB – MS-SQL and MySQL database load balancing.
• Diameter – Provides proxy service and load balancing for Diameter

AAA
• DNS – Provides DNS security and optimization.
• HTTP – Provides a robust set of options for HTTP header manipulation

and for load balancing based on HTTP header content or the URL
requested by the client, and other options
• FTP – Provides load balancing for FTP traffic.
• Policy – Uses Policy-based SLB (PBSLB) to permit or deny clients, or

direct them to service groups, based on client black/white lists
• External-service – Adds capabilities needed for intelligently steering
traffic based on application (example: Internet Content Adaptation Pro-
tocol [ICAP]).
• Cache – Caches web content on the ACOS device to enhance website
performance for clients
• Client SSL – Offloads SSL validation tasks from real servers
• Server SSL – Validates real servers on behalf of clients
• Cipher – Contains a set of SSL ciphers that can be applied to a client-

SSL or server-SSL template.
• Connection reuse – Reduces overhead from TCP connection setup by
establishing and reusing TCP connections with real servers for multiple
client requests
• Cookie persistence – Inserts a cookie into server replies to clients, to
direct clients to the same service group, real server, or real service port
for subsequent requests for the service
• Source-IP persistence – Directs a given client, identified by its IP
address, to the same service port, server, or service group
• Destination-IP persistence – Configures persistence to real servers based
on destination IP address
• FIX – Configures Financial Information eXchange load balancing.
• Logging – Configures logging to external servers over TCP.
• SSL session-ID persistence – Directs all client requests for a given vir-
tual port, and that have a given SSL session ID, to the same real server
and real port

• SIP – Customizes settings for load balancing of Session Initiation Proto-
col (SIP) traffic
• SMPP – Configures load balancing for Short Message Peer to Peer
(SMPP).
• SMTP – Configures STARTTLS support for Simple Mail Transfer Pro-
tocol (SMTP) clients
• Streaming-media – Directs client requests based on the requested con-
tent
Where applicable, the ACOS device automatically applies a default tem-

plate with commonly used settings. For example, when you configure SLB
for FTP, the ACOS device automatically applies the default TCP template.
If required by your application, you can configure a different template and
apply that one instead. The configuration examples in this guide show how
to do this.
Outbound Link Load Balancing

Outbound Link Load Balancing (LLB) balances client-server traffic across
a set of WAN links. In outbound LLB, the clients are located on the internal
side of the network. The servers are located on the external side of the net-
work.
Transparent Cache Switching

Transparent Cache Switching (TCS) enables you to improve server
response times by redirecting client requests for content to cache servers
containing the content.
Firewall Load Balancing

Firewall Load Balancing (FWLB) maximizes throughput through firewall
bottlenecks by load balancing server-client sessions across the firewalls.

Where Do I Start?
Where Do I Start?
• To configure basic system settings, see “Basic Setup” on page 43.
• To configure network settings, see “Network Setup” on page 87.
• To configure management access security features, see the Management

Access Security Guide.
• To configure and secure application delivery and Server Load Balancing
features, see the following:
• Application Delivery and Server Load Balancing Guide
• Application Access Management and DDoS Mitigation Guide
• Web Application Firewall Guide

Where Do I Start?

SoftAX for Multiple Hypervisors
SoftAX
SoftAX is a fully operational software-only version of A10 Networks’ line

of A10 Thunder Series and AX Series Advanced Traffic Managers / Server
Load Balancers.

SoftAX is a fully operational software-only version of A10 Networks’ line
of AX Series Advanced Traffic Managers.
ACOS release 2.6.1 first introduced support for SoftAX for VMware ESX/
ESXi. Support for additional hypervisors was added in subsequent releases,
with the current release supporting SoftAX on the following hypervisors:
• VMware (ESX 4.0 or higher, or ESXi 4.0 or higher).
• KVM (hypervisor 0.8.8 version of ‘libvirt’)
• Citrix Xen (XenServer, Xen Cloud Platform (XCP), or Xen Hypervisor)
• Open source Xen (Xen.org)
• Microsoft Hyper-V (Windows 2012)

Network Topology
Figure 3 shows the network topology in which a SoftAX can be installed on
multiple hypervisors.
FIGURE 3 SoftAX for Multiple Hypervisors
The hypervisor is installed on top of commodity hardware, and the virtual-

ized SoftAX instance sits on top of the hypervisor layer. Functionality of
SoftAX is, for the most part, the same as a hardware-based ACOS device.
Installation of SoftAX
The SoftAX software can be downloaded as an ISO image. Multiple
SoftAX instances can be installed in a single hardware platform, such as a
PC, with each instance running independently from the others.
• VMware—SoftAX for VMware is available as a virtual machine image
in Open Virtualization Format (OVF). You can install SoftAX for

VMware on a hardware platform running VMware ESX 4.0 or higher,
or ESXi 4.0 or higher.
• KVM—SoftAX for KVM instance can be installed and run on Fedora
15 (qemu-kvm-0.14.0) with hypervisor 0.8.8 version of ‘libvirt’.
• Xen (Citrix)—SoftAX for Xen is installed as a fully virtualized virtual
machine in a Xen system, such as XenServer, Xen Cloud Platform
(XCP), or Xen Hypervisor.
• Xen (Xen.org)—SoftAX for Xen.org can run on Xen.org’s open-source,
type-1 (or “bare-metal”) hypervisor, which is not to be confused with
SoftAX for Citrix Xen.
• HyperV—SoftAX for HyperV instance can be installed and run on a
Microsoft Windows 2012 system that has the Hyper-V role added.
System Requirements
The virtualized hardware upon which the SoftAX instance is installed must
meet the following requirements:
• 1 virtual CPU
• At least 2 GB RAM
• At least 8 GB storage
• One management interface and at least one data network interface
• Processor must support Intel VT-enabled or AMD V-enabled technology

(required by SoftAX for full virtualization)
Management of SoftAX
SoftAX can be managed from the ACOS CLI or GUI, which is the same as
any standard hardware-based ACOS device.
Feature Support
SoftAX supports most of the same features that are supported on the hard-
ware-based ACOS devices.
However, SoftAX does not support the following features:

• Transparent (Layer 2) deployment

• Hardware-specific features (for example, hardware-based HTTP/
HTTPS compression and hardware-based SSL acceleration)
• Role-Based Administration (RBA). Only the shared partition is sup-
ported. Private partitions are not supported.
• IPv6 migration features (Large-scale NAT, DS-Lite, NAT64/DNS64)
• Port mirroring
• SSL Intercept and SSL Forward Proxy (features require SSL ASIC)
For more information on which features are supported and which are not,
please refer to the SoftAX Advanced Traffic Manager Installation Guide(s).
Standardized Parameter Limits for SoftAX Models

SoftAX versions vary by price according to the amount of bandwidth
offered. A10 Networks offers a Lab/Developer Edition, as well as the fol-
lowing paid versions, which can be used in production environments:
• Entry Level/Lab Editions:
• 200 Mbps
• 1 Gbps
• High-performance Editions:
• 4 Gbps
• 8 Gbps
In prior ACOS releases, the maximum limits for the various system parame-
ters varied from one edition to the next for system parameters such as Max-
imum SSL VIPs, or the maximum number of Layer 4 sessions supported.
However, as of ACOS release 2.7.0, these parameters have been standard-
ized such that the maximum limits for the SoftAX system parameters are
the same for the Entry Level edition (with 200-Mbps throughput) as for the
High-performance edition (with 8-Gbps throughput).
This standardization enhancement affects both publicly available parame-

ters, such as Layer 4 sessions, real servers, virtual servers, and server ports,
and also so-called “private parameters”, which can not be viewed through
the CLI, such as the maximum number of supported NAT pools, templates,
as well as the limits associated with cookie persistence.

SoftAX for Citrix XenServer 5.6
SoftAX for Citrix XenServer 5.6

Previous releases introduced SoftAX for Citrix XenServer 6.0. However,
many A10 customers continue to use older versions of the XenServer soft-
ware. Therefore, to address the market demand for a SoftAX version that
can run on older versions of the XenServer software, ACOS release 2.7.1
introduces support for SoftAX running on Citrix XenServer 5.6 (in addition
to support for 6.0).
The set of features supported in SoftAX for XenServer 5.6 is the same as
those supported in version 6.0. The requirements for the virtualized hard-
ware upon which the SoftAX instance is installed remain unchanged from
those associated with XenServer 6.0.
Application Delivery Partition Support

This release supports Layer 3 Virtualization (L3V) within an Application
Delivery Partition. While previous releases offered support for shared parti-
tions, this release extends support by enabling a SoftAX administrator to
configure up to 32 private partitions for each SoftAX instance.
L3V offers administrators virtualized management of network resources

and SLB resources, which are based on administrative domains or parti-
tions. Layer 2/3 virtualization can be enabled or disabled on a per-partition
basis, allowing each private partition to own its network resources.
L3V support applies to the following SoftAX hypervisors, which are

included in the 2.7.1 release:
• SoftAX for Microsoft Hyper-V
• SoftAX for Kernel-based Virtual Machine (KVM)
• SoftAX for VMware ESXi
• SoftAX for Citrix XenServer
Single-interface Mode for SoftAX (VMware only)

To simplify deployment, the SoftAX for VMware can be configured to use a
single interface for management and data traffic. While SoftAX is typically
deployed with a separate management and data interface, “single-interface
mode” requires consolidating the functionality of both the data and manage-
ment interfaces into one unified interface.

Single-interface Mode for SoftAX (VMware only)
You can configure SoftAX to receive a DHCP-assigned IP address, and this
same IP address will be used for the interface IP, Source NAT IP, and the
SLB VIP.
Prerequisites:
• This functionality is only supported for SoftAX running on the VMware
hypervisor, and it is not supported on any of the other hypervisors.
• The SoftAX interface type must be set to “vmxnet3” for single-interface
mode.
For more information on configuring Single-interface Mode, see the SoftAX

for VMware Installation Guide.

AX-V
This release introduces the A10 Thunder Series and AX Series AX-V
Advanced Traffic Manager / Server Load Balancer. The AX-V appliance
combines A10 Networks high-performance, purpose-built hardware with
the flexibility of SoftAX.
AX-V enables you to respond to changing traffic volume by provisioning or
de-provisioning multiple high performance SoftAX appliances as required.
You can configure multiple SoftAX appliances on the AX-V appliance for
High Availability (HA), thus providing complete software failover capabil-
ity on a single platform.
System Specifications
The AX-V is a 1-rack unit (1 RU) appliance with the following hardware
features:
• 20 Ethernet data interfaces: 4 10-Gig Fiber and 16 1-Gig Copper
• USB and VGA ports for console access to the AX-V management sub-
system
• Solid State Drive (SSD)
• Redundant power supplies
• Hardware-based SSL support (ASIC)
• The AX-V uses VMware ESXi 4.1.0.
SoftAX Virtual Appliances

The AX-V comes with 6 factory-installed SoftAX virtual ACOS devices.
Although up to 12 SoftAX instances can be installed on the AX-V, it is not
recommended to install more than 6 instances.
Each SoftAX is an independent virtual chassis that can be configured to

operate autonomously or as a member of a High Availability (HA) set for
redundancy. You can even configure multiple SoftAX devices into a single
virtual chassis using ACOS Virtual Chassis System (aVCS).
Each SoftAX installed on the AX-V has three interfaces:

• Management – Dedicated management interface
• Ethernet 1 – Data interface
• Ethernet 2 – Data interface

Installation Overview
To install the AX-V appliance:
• Install the AX-V chassis.
• Configure the AX-V chassis management IP address.
• Change the default admin name (“root”) and password (“password”) to

access the appliance management configuration.
• Set up each SoftAX:
• Power on the SoftAX.
• Configure the management IP address.
• Change the admin password.
• Set the enable password for secure access to the operational and
configuration levels of the CLI.
You do not need to install the SoftAX virtual appliances on VMware. They
are already installed at the factory.
Optionally, you can perform the following additional configuration, if nec-

essary.
• Add Port Groups (as needed)
• Add Ethernet Data Interfaces (as needed)
• Configure a direct path to use the Cavium processor for hardware-based

SSL offload.

Logging On
Basic Setup
This chapter describes how to log onto the ACOS device and how to config-
ure the following basic system parameters:
• Hostname and other Domain Name Server (DNS) settings
• CLI banner messages
• Date/time settings
• System log (Syslog) settings
• Simple Network Management Protocol (SNMP) settings
• Recovering from a console session that appears to be hung
After you are through with this chapter, go to “Network Setup” on page 87.
Note: The only basic parameters that you are required to configure are date/time
settings. Configuring the other parameters is optional.
Note: This chapter does not describe how to access the serial console interface.
For that information, see the installation guide for your A10 Thunder
Series or AX Series model.
Caution: When you make configuration changes, be sure to remember to save

the changes. Unsaved configuration changes will be lost following a
reboot. To save changes, click Save on the top row of the GUI window
or enter the write memory command in the CLI.
Logging On
A10 Thunder Series and AX Series devices provide the following manage-
ment interfaces:
• Command-Line Interface (CLI) – Text-based interface in which you
type commands on a command line. You can access the CLI directly
through the serial console or over the network using either of the
following protocols:
• Secure protocol – Secure Shell (SSH) version 2
• Unsecure protocol – Telnet (if enabled)
• Graphical User Interface (GUI) – Web-based interface in which you

click to access configuration or management pages and type or select

Logging On
values to configure or manage the device. You can access the GUI using
either of the following protocols:
• Secure protocol – Hypertext Transfer Protocol over Secure Socket
Layer (HTTPS)
• Unsecure protocol – Hypertext Transfer Protocol (HTTP)
• aXAPI – XML Application Programming Interface based on the Repre-

sentational State Transfer (REST) architecture. The aXAPI enables you
to use custom third-party applications to configure and monitor Server
Load Balancing (SLB) parameters on the ACOS device, and to monitor
Ethernet interfaces. (For more information, see the A10 Thunder Series
and AX Series aXAPI Reference.)
Note: By default, Telnet access is disabled on all interfaces, including the man-
agement interface. SSH, HTTP, HTTPS, and SNMP access are enabled by
default on the management interface only, and disabled by default on all
data interfaces.
Note: The ACOS device supports a maximum of 128 simultaneous management

sessions. This includes any combination of CLI, GUI, and aXAPI ses-
sions.
Federal Information Processing Standards (FIPS) Compliance

To comply with FIPS security standards, beginning in AX Release 2.4.2,
management access to the ACOS device has the following requirements:
• Web access to GUI – The browser used to access the ACOS GUI must
support encryption keys of 128 bits or longer. Shorter encryption keys
(for example, 40 bits) are not supported. The browser also must support
TLS 1.0. Beginning in AX Release 2.6.1-P1, browsers that support only
SSL are not supported.
• SSH access to CLI – The SSH client used to access the CLI must sup-
port SSHv2. SSHv1 is not supported. The SSHv2 client must support
one of the following encryption ciphers:
• 3des-cbc
• aes128-cbc
• aes192-cbc
• aes256-cbc
Other ciphers are not supported.

Logging On
Logging Onto the CLI

Note: The A10 Thunder Series and AX Series provides advanced features for
securing management access to the device. This section assumes that only
the basic security settings are in place. (For more information about secur-
ing management access, see “Management Security Features” on
page 459.)
To log onto the CLI using SSH:

1. On a PC connected to a network that can access the ACOS device’s
management interface, open an SSH connection to the IP address of the
management interface.
2. Generally, if this the first time the SSH client has accessed the ACOS
device, the SSH client displays a security warning. Read the warning
carefully, then acknowledge the warning to complete the connection.
(Press Enter.)
3. At the login as: prompt, enter the admin username.
4. At the Password: prompt, enter the admin password.

If the admin username and password are valid, the command prompt for
the User EXEC level of the CLI appears: ACOS>
The User EXEC level allows you to enter a few basic commands,
including some show commands as well as ping and traceroute.
Note: The “ACOS” in the CLI prompt is the hostname configured on the device,
which is “ACOS” by default. If the hostname has already been changed,
the new hostname appears in the prompt instead of “ACOS”.
5. To access the Privileged EXEC level of the CLI and allow access to all
configuration levels, enter the enable command.
At the Password: prompt, enter the enable password. (This is not the
same as the admin password, although it is possible to configure the
same value for both passwords.)
If the enable password is correct, the command prompt for the Privi-
leged EXEC level of the CLI appears: ACOS#
6. To access the global configuration level, enter the config command. The
following command prompt appears: ACOS(config)#

Logging On
Logging Onto the GUI

Web access to the ACOS device is supported on the Web browsers listed in
Table 1.
TABLE 1 GUI Browser Support

Platform
Browser Windows Linux MAC
IE 6.0-9.0 Supported N/A N/A
Firefox 3.5-7.0 Supported Supported N/A
Safari 3.0 Not Supported N/A Supported
Safari 2.0 Not Supported N/A Not Supported
Chrome 5.0 Supported Supported Supported
A screen resolution of at least 1024x768 is recommended.

1. Open one of the Web browsers listed in Table 1.
2. In the URL field, enter the IP address of the ACOS device’s manage-
ment interface.
3. If the browser displays a certificate warning, select the option to con-

tinue to the server (the ACOS device).
Note: To prevent the certificate warning from appearing in the future, you can
install a certificate signed by a Certificate Authority. See “Replacing the
Web Certificate” on page 78.
A login dialog is displayed. The name and appearance of the dialog
depends on the browser you are using.

Logging On
FIGURE 4 GUI Login Dialog (Internet Explorer)
4. Enter your admin username and password and click OK.
Note: The default admin username and password are “admin”, “a10”.
The Summary page appears, showing at-a-glance information for your
ACOS device.
You can access this page again at any time while using the GUI, by
selecting Monitor Mode > Overview > Summary.

Logging On
FIGURE 5 Monitor Mode > Overview > Summary
Note: GUI management sessions are not automatically terminated when you
close the browser window. The session remains in effect until it times out.
To immediately terminate a GUI session, click Logout.
Note: For more information about the GUI, see the A10 Thunder Series and
AX Series GUI Reference or the GUI online help.

Configuring Basic System Parameters

This section describes the basic system parameters and provides CLI and
GUI steps for configuring them.
Note: If you plan to use the GUI, the Basic System page under Config Mode
also provides configuration access to most of the system parameters
described in this chapter. For information, navigate to Config Mode > Get
Started > Basic System, then click Help.
Setting the Hostname and Other DNS Parameters

The default hostname is “ACOS”. To change the hostname, use either of the
following methods.
Note: Do not use a period ( . ) in the hostname. If you do use a period, the
ACOS device will use the text after the period as the DNS suffix instead
of the DNS suffix you configure.
USING THE GUI

1. Select Config Mode > Network > DNS. The DNS page appears.
2. In the Hostname field, edit the name to one that will uniquely identify
this particular ACOS device (for example, “ACOS-SLB1”).
3. In the DNS Suffix field, enter the domain name to which the host
(A10 Thunder Series and AX Series) belongs.
4. In the Primary DNS field, enter the IP address of the external DNS
server the A10 Thunder Series and AX Series should use for resolving
DNS queries.
5. In the Secondary DNS field, enter the IP address of an external backup

DNS server the A10 Thunder Series and AX Series should use if the pri-
mary DNS server is unavailable.
6. Click OK.

USING THE CLI

1. Access the global configuration level of the CLI:
ACOS>enable
Password:enable-password
ACOS#config
ACOS(config)#
2. Use the following command to change the hostname:

hostname string
After you enter this command, the command prompt should change to
the same value as the new hostname.
Note: The “ > ” or “ # ” character and characters in parentheses before “ # ” indi-

cate the CLI level you are on and are not part of the hostname.
3. To set the default domain name (DNS suffix) for hostnames on the
ACOS device, use the following command:
ip dns suffix string
4. To specify the DNS servers the ACOS device should use for resolving
DNS requests, use the following command:
ip dns {primary | secondary} ipaddr
The primary option specifies the DNS server the ACOS device should
always try to use first. The secondary option specifies the DNS server
that the ACOS device should use if the primary DNS server is unavail-
able.
Setting the CLI Banners

The CLI displays banner messages when you log onto the CLI. By default,
the messages shown in bold type in the following example are displayed:
login as: admin
Welcome to ACOS
Using keyboard-interactive authentication.
Password:
Last login: Thu Feb 7 13:44:32 2008 from
192.168.1.144
[type ? for help]
You can format banner text as a single line or multiple lines.

If you configure a banner message that occupies multiple lines, you must
specify the end marker that indicates the end of the last line. The end marker
is a simple string up to 2-characters long, each of the which must be an
ASCII character from the following range: 0x21-0x7e.
The multi-line banner text starts from the first line and ends at the marker. If
the end marker is on a new line by itself, the last line of the banner text will
be empty. If you do not want the last line to be empty, put the end marker at
the end of the last non-empty line.
USING THE GUI

1. Select Config Mode > System > Settings > Terminal > Banner.
2. To configure a banner:
a. Select the banner type, single-line or multi-line.
b. If you selected multi-line, enter the delimiter value in the End
Marker field.
c. Enter the message in the Login Banner or Exec Banner field.
If the message is a multi-line message, press Enter / Return at the
end of every line. Do not type the end marker at the end of the mes-
sage. The GUI automatically places the end marker at the end of the
message text in the configuration.
3. If you are configuring both messages, repeat step 2 for the other mes-
sage.
4. Click OK.
USING THE CLI
To change one or both banners, use the following command:
[no] banner {exec | login} [multi-line end-marker]

line
The login option changes the first banner, which is displayed after you enter
the admin username. The exec option changes the second banner, which is
displayed after you enter the admin password.
To use blank spaces within the banner, enclose the entire banner string with
double quotation marks.

Setting Time/Date Parameters

To configure time/date parameters:
• Set the timezone.
• Set the system time and date manually or configure the device to use a
Network Time Protocol (NTP) server. You can specify a preferred NTP
server and authenticate NTP servers with encrypted keys.
The default timezone is Europe/Dublin, which is equivalent to Greenwich

Mean Time (GMT). The time and date are not set at the factory, so you must
manually set them or configure NTP.
Note: You do not need to configure Daylight Savings Time. The ACOS device
automatically adjusts the time for Daylight Savings Time based on the
timezone you select. The UTC time standard does not observe daylight
savings time.
Note: When you change the ACOS timezone, the statistical database is cleared.
This database contains general system statistics (performance, CPU,
memory, and disk utilization) and SLB statistics.
USING THE GUI

1. Select Config Mode > System > Settings > Time. The Date/Time page
appears.
• To set the time and date by synchronizing them with the time and
date on the PC from which you are running the GUI, click Sync
Local Time.
• To configure the time and date manually:
a. Enter the date in the Date field or select the date using the cal-
endar.
b. Enter the time in the Time field.
• To set the time and date using NTP:
a. Select the Automatically Synchronize with Internet Time
Server checkbox.
b. In the NTP Server field, enter the NTP server’s IP address.
c. Click on Add to add the server name to NTP server list. You
can also delete any server that is in the list that you do not wish
to use. In addition, Enable or Disable the NTP server.
2. To select the timezone follow the steps documented below:

a. From Config Mode > System > Settings > Time, click Time Zone.

b. From the Time Zone Name pull-down list, select the time zone.
The system timezone can include the Coordinated Universal Time
(UTC) time standard or the Greenwich Mean Time (GMT) standard.
The UTC timezone is equivalent to the GMT timezone.
c. Click OK.
d. Click Date/Time to re-display the section, if not already displayed.
3. Click OK.
USING THE CLI
To set the timezone
Enter the following command at the global configuration level of the CLI:
clock timezone timezone [nodst]
Enter UTC for the timezone option to apply the UTC time standard to the
system. Enter timezone ? to display additional timezone options.
The nodst option disables Daylight Savings Time (DST) for the zone. DST
is enabled by default, if applicable to the timezone.
Note: The UTC time standard does not observe daylight savings time.
Use the following command to show the timezone selected for the device:
show clock
To configure the ACOS device to use NTP

1. To specify the NTP server to use, enter the following command at the
global configuration level of the CLI:
ntp server {hostname | ipaddr}
You can configure a maximum of 4 NTP servers.
2. To enable NTP and synchronize the ACOS device clock with the NTP
server, enter the following command:
ntp enable
To set the time and date manually

1. Return to the Privileged EXEC level of the CLI by entering the exit
command.

2. Enter the following command at the Privileged EXEC level of the CLI:
clock set time day month year
Enter the time and date in the following format:
time – hh:mm:ss
day – 1-31
month – January, February, March, ...
year – 2008, 2009 ...
Note: The clock is based on 24 hours. For example, for 1 p.m., enter the hour as
“13”.
3. To display clock settings, use the following command:

show clock [detail]
Setting the NTP Server Authentication
ACOS 2.7.1 increases security with the ability to authenticate Network

Time Protocol (NTP) servers. NTP server authentication keys are stored
using a special A10 Networks encryption algorithm to conceal the clear-text
form of the authentication key. You can add the ID numbers of encrypted
authentication keys to a list of trusted keys, and apply the trusted keys to
one or more NTP servers.
An NTP server can operate in either authentication or non-authentication

mode. If an authentication key is specified in the client’s NTP request, the
NTP server appends a message authentication code (MAC) to the response
packet header, using the authentication key. The NTP client compares the
MAC of the NTP server against the specified authentication key and accepts
the packet from the NTP server if the MAC matches.
To configure NTP server authentication:

1. Create a list of authentication keys. The encrypted keys are stored on
the ACOS device.
2. Add the identification numbers of one or more authentication keys to the

list of trusted keys. Only keys from the trusted key list are valid for NTP
server authentication.
3. Configure an NTP server and apply a trusted authentication key.
Note: The NTP server and NTP client must reference the same authentication
key ID number. If the NTP server and NTP client are configured with dif-

ferent authentication key ID numbers, NTP server authentication will
always fail.
USING THE GUI
In the current release, this enhancement is not supported from the GUI.
USING THE CLI
Create Authentication Keys
Enter the following command to create an authentication key:

[no] ntp auth-key num M string
For num, enter a value between 1-65535. This value applies an identifica-
tion number to the authentication key, which is referred to when adding the
key to the trusted key list or NTP server.
For string, enter a series of 1-31 alphanumeric characters for the key. This
value is stored in the system using the A10 encryption algorithm.
Note: Do not enter the encrypted option when configuring an authentication

key. This option is placed into configuration by the ACOS to indicate that
the authentication key string is in encrypted form.
Use the no form of the command to delete an authentication key.
Set Trusted Keys

Enter the following command to add an authentication key to the list of
trusted keys:
[no] ntp trusted-key num
For num, enter the identification number of a configured authentication key

to add the key to the trusted key list. You can enter more than one number,
separated by whitespace, to simultaneously add multiple authentication
keys to the trusted key list.
Use the no form of the command to remove one or more authentication keys
from the trusted key list.
Configure NTP Servers

Enter the following command to configure an NTP server and apply a
trusted authentication key:
[no] ntp server ip-addr [key num]

For ip-addr, enter the IPv4 or IPv6 address of the NTP server. If an NTP
server at the specified IP address does not currently exist, this command
will configure a new NTP server with the authentication key applied. You
can configure a maximum of 4 NTP servers.
For key num, enter the identification number of an authentication key that is
included in the trusted key list.
Display NTP Server and Key Configuration

To view NTP server and authentication key configuration, use the show run
command from the privileged EXEC level of the CLI.
CLI Example
The following example creates 3 authentication keys (1337, 1001, and
1012) and adds these keys to the list of trusted keys. The NTP server located
at 10.10.3.18 is configured to use a trusted key (1337) for authentication:
ACOS(config)#ntp auth-key 1337 M XxEnc192
ACOS(config)#ntp auth-key 1001 M Vke1324as
ACOS(config)#ntp auth-key 1012 M 28fj039
ACOS(config)#ntp trusted-key 1337 1001 1012
ACOS(config)#ntp server 10.10.3.18 key 1337
You can verify the NTP server and authentication key configuration with
the show run command. The following example includes an output modi-
fier to display only NTP-related configuration:
ACOS(config)#show run | include ntp
ntp auth-key 1001 M encrypted
FSNiuf10Dtzc4aY0tk2J4DwQjLjV2wDnPBCMuNXbAOc8EIy41dsA5zwQjLjV2wDn
ntp auth-key 1012 M encrypted
NEMuh8GgapM8EIy41dsA5zwQjLjV2wDnPBCMuNXbAOc8EIy41dsA5zwQjLjV2wDn
ntp auth-key 1337 M encrypted zIJptJHuaQaw/
5o10esBTDwQjLjV2wDnPBCMuNXbAOc8EIy41dsA5zwQjLjV2wDn
ntp trusted-key 1001 1012 1337
ntp server 10.10.3.18 key 1337
Setting the NTP Server Preference
You can configure a preference option to the configuration of NTP servers.

You now direct the ACOS to use the prioritized NTP server by default and

rely on additional NTP servers as backup if the preferred NTP server
becomes unavailable.
Note: A10 Networks recommends enabling the preference option for a single
NTP server only. If preference is selected for more than one NTP server,
the prioritized NTP server is determined by an internal calculation.
USING THE GUI
In the current release, you cannot set a preferred NTP server from the GUI.
USING THE CLI

The following command applies preference to an NTP server.
[no] ntp server ip-addr [prefer]
For ip-addr, enter the IPv4 or IPv6 address of the NTP server. If an NTP
server at the specified IP address does not currently exist, this command
will configure a new NTP server with preference applied. You can configure
a maximum of 4 NTP servers, regardless of preference settings.
Enter the prefer option to direct the ACOS to use this NTP server by
default. Additional NTP servers are used as backup servers if the preferred
NTP server is unavailable.
Use the no form of the command to remove an NTP server.
CLI Example
The following commands create an NTP server at 11.12.13.14 with pre-
ferred priority and verifies this configuration with the show run command:
ACOS(config)#ntp server 11.12.13.14 prefer
ACOS(config)#show run | begin ntp server
ntp server 11.12.13.14 prefer
!
...
The following commands remove preference for the NTP server at

11.12.13.14 and creates a new, preferred NTP server at 15.16.17.18. The

show run command displays the configured NTP servers and change in
server preference:
ACOS(config)#ntp server 11.12.13.14
ACOS(config)#ntp server 15.16.17.18 prefer
ACOS(config)#show run | begin ntp server
ntp server 11.12.13.14
!
ntp server 15.16.17.18 prefer
!
...
Configuring Syslog Settings

The ACOS device logs system events with Syslog messages. The ACOS
device can send Syslog messages to the following places:
• Local buffer
• Console CLI session
• Console SSH and Telnet sessions
• External Syslog server
• Email address(es)
• SNMP servers (for events that are logged by SNMP traps)
Logging to the local buffer and to CLI sessions is enabled by default. Log-
ging to other places requires additional configuration. The standard Syslog
message severity levels are supported:
• Emergency – 0
• Alert – 1
• Critical – 2
• Error – 3
• Warning – 4
• Notification – 5
• Information – 6
• Debugging – 7
Table 2 lists the configurable Syslog parameters.

TABLE 2 Configurable System Log Settings

Parameter Description Supported Values
Disposition Output options for each message level. For each mes- The following message levels can be
(message target) sage level, you can select which of the following out- individually selected for each output
put options to enable: option:
• Console – Messages are displayed in Console ses- • Emergency (0)
sions. • Alert (1)
• Buffered – Messages are stored in the system log • Critical (2)
buffer.
• Error (3)
• Email – Messages are sent to the email addresses
• Warning (4)
in the Email To list. (See below.)
• Notification (5)
• SNMP – SNMP traps are generated and sent to the
SNMP receivers. • Information (6)
• Syslog – Messages are sent to the external log • Debug (7)
servers specified in the Log Server fields. (See Only Emergency, Alert, and Critical
below.) can be selected for SNMP.
• Monitor – Messages are displayed in Telnet and Only Emergency, Alert, Critical, and
SSH sessions. Notification can be selected for Email.
Note: For information about emailing log messages,
see “Emailing Log Messages” on page 80.
Logging Email Settings for sending log messages by email. See “Emailing Log Messages” on
Filter page 80.
Logging Email
Buffer Number
Logging Email
Buffer Time
Facility Standard Syslog facility to use. Standard Syslog facilities listed in
RFC 3164.
Log Buffer Maximum number of log entries the log buffer can 10000 to 50000 entries
Entries store. Default: 30000
Log Server IP addresses or fully-qualified domain names of Any valid IP address or fully-quali-
external log servers. fied domain name.
Only the message levels for which Syslog is selected Default: None configured
in the Disposition list are sent to log servers.
Note: By default, the ACOS device can reach remote
log servers only if they are reachable through the
ACOS device’s data ports, not the management port.
To enable the ACOS device to reach remote log serv-
ers through the management port, see “Specifying
the Source Interface for Management Traffic” on
page 537.
Log Server Port Protocol port to which log messages sent to external Any valid protocol port number
log servers are addressed. Default: 514

TABLE 2 Configurable System Log Settings (Continued)
Parameter Description Supported Values
Email To Email addresses to which to send log messages. Valid email address. Click the down
Only the message levels for which Email is selected arrow next to the input field to add
in the Disposition list are sent to log servers. another address (up to 10).
Each email address can be a maxi-
mum of 31 characters long.
SMTP Server IP address or fully-qualified domain name of an Any valid IP address or fully-quali-
email server using Simple Message Transfer Proto- fied domain name.
col. Default: None configured
Note: By default, the ACOS device can reach SMTP
servers only if they are reachable through the ACOS
device’s data ports, not the management port. To
enable the ACOS device to reach SMTP servers
through the management port, see “Specifying the
Source Interface for Management Traffic” on
page 537.
SMTP Server Protocol port to which email messages sent to the Any valid protocol port number
Port SMTP server are addressed. Default: 25
Mail From Specifies the email From address. Valid email address
Default: Not set
Need Authenti- Specifies whether access to the SMTP server requires Selected (enabled) or unselected (dis-
cation authentication. abled)
Default: disabled
Username Username required for access to the SMTP server. Valid username
Default: Not set
Password Password required for access to the SMTP server. Valid password
Default: Not set
Single-priority Logging
Single-priority logging allows you to identify one specific severity level to
be logged from among the standard syslog message severity levels 0–7:
• 0 – emergency
• 1 – alert
• 2 – critical
• 3 – error
• 4 – warning
• 5 – notification
• 6 – information

• 7 – debugging
Single-priority logging allows you to remove excess data so that you can
see a desired subset of log messages at your target severity level.
In prior releases, when you specify a severity level to be logged, the

selected level becomes the “basement level”, or the most trivial level that
will appear along with the more important messages. For example, if you
specify level 3 (error), you would also get severities 2, 1, and 0, but 3 would
be the most trivial severity level to be included in the log messages.
Prior releases did not offer a way for you to single out a particular subset of
log messages at a singular severity level. There was no way to only display
log message of the 5 (notification) level without also see levels 4–0.
Single-priority logging offers more granular control of syslog messages.
Log Rate Limiting

The ACOS device uses a log rate limiting mechanism to ensure against
overflow of external log servers and the internal logging buffer.
The rate limit for external logging is 15,000 messages per second from the
device.
The rate limit for internal logging is 32 messages per second from the
device.
• If the number of new messages within a one-second interval exceeds 32,
then during the next one-second interval, the ACOS device sends log
messages only to the external log servers.
• If the number of new messages generated within the new one-second
interval is 32 or less, then during the following one-second interval, the
ACOS device will again send messages to the local logging buffer as
well as the external log server. In any case, all messages (up to 15,000
per second) get sent to the external log servers.
USING THE GUI

1. Select Config Mode > System > Settings > Log.
2. Change settings as needed. (For descriptions of the settings, see

Table 2.)
3. Click OK.

USING THE CLI

1. To change the severity level of messages that are logged in the local
buffer, use the following command:
logging buffered severity-level
2. To change the severity level of messages that are logged in other places,
use the following command:
logging target severity-level
The target can be one of the following:
• console – Serial console
• email – Email
• monitor – Telnet and SSH sessions
• syslog – external Syslog host
• trap – external SNMP trap host
Note: Only severity levels emergency, alert, critical, and notification can be
sent by email. Sending log messages by email requires additional configu-
ration. See “Emailing Log Messages” on page 80.
3. To configure the ACOS device to send log messages to an external Sys-

log server, use the following command to specify the server:
logging host ipaddr [ipaddr...]
[port protocol-port]
You can enter more than one server IP address on the same command
line. The default protocol port is 514. You can specify only one protocol
port with the command. All servers must use the same protocol port to
listen for syslog messages.
If you use the command to add some log servers, then need to add a new
log server later, you must enter all server IP addresses in the new com-
mand. Each time you enter the logging host command, it replaces any
set of servers and syslog port configured by the previous logging host
command.
4. To configure the ACOS device to send log messages by email, use the
following commands to specify the email server and the email
addresses:
smtp {hostname | ipaddr} [port protocol-port]
The port option specifies the protocol port to which to send email. The
default is 25.
logging email-address address [...]
To enter more than one address, use a space between each address.

5. To send event messages to an external SNMP server, see “Enabling
SNMP” on page 63.
Example for Single Priority Logging
To use single-priority logging to identify on severity level of system events

to be logged, use the following command at the global config mode:
[no] logging single-priority severity-level

{0 | emergency}
{1 | alert}
{2 | critical}
{3 | error}
{4 | warning}
{5 | notification}
{6 | information}
{7 | debugging}
The severity-level specifies the severity level to log. You can enter the name
of the severity level or the number that corresponds to the severity level.
Enabling SNMP
ACOS devices support the following SNMP versions: v1, v2c, v3. SNMP is
disabled by default.
You can configure the ACOS device to send SNMP traps to the Syslog and
to external trap receivers. You also can configure read (GET) access to
SNMP Management Information Base (MIB) objects on the ACOS device
by external SNMP managers.
Note: SNMP access to the ACOS device is read-only. SET operations (write
access) are not supported.
The ACOS device supports the following SNMP-related RFCs:
• RFC 1157, A Simple Network Management Protocol (SNMP)
• RFC 1213, Management Information Base for Network Management of

TCP/IP-based internets: MIB-II
The sysService object returns a value that indicates the set of services
the ACOS device offers. For the ACOS device, the sysService object
always returns the following value: 76
This value indicates that the ACOS device offers the following services:
• datalink/subnetwork – 0x2
• internet – 0x4

• end-to-end – 0x8
• applications – 0x40
For information about how the value is calculated, see the RFC.
• RFC 1850, OSPF Version 2 Management Information Base
• draft-ietf-ospf-ospfv3-mib-08, OSPF Version 3 Management Informa-

tion Base
• RFC 1901, Introduction to Community-based SNMPv2
• RFC 2233, The Interfaces Group MIB using SMIv2
• RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of

the Internet-standard Network Management Framework
• 2790, Host Resources MIB
The following subtrees are supported:
• hrSystem: .1.3.6.1.2.1.25.1
• hrStorage: .1.3.6.1.2.1.25.2
• hrDeviceTable: .1.3.6.1.2.1.25.3.2
• hrProcessorTable: .1.3.6.1.2.1.25.3.3
• RFC 3410, Introduction and Applicability Statements for Internet Stan-

dard Management Framework
• RFC 3411, An Architecture for Describing Simple Network Manage-
ment Protocol (SNMP) Management Frameworks
• RFC 3412, Message Processing and Dispatching for the Simple Net-
work Management Protocol (SNMP)
• RFC 3413, Simple Network Management Protocol (SNMP) Applica-
tions
• RFC 3414, User-based Security Model (USM) for version 3 of the Sim-
ple Network Management Protocol (SNMPv3)
• RFC 3415, View-based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP)
• RFC 3635, Definitions of Managed Objects for the Ethernet-like Inter-
face Types

SNMP Traps
Table 3 lists the SNMP traps supported by the ACOS device. All traps are
disabled by default.
TABLE 3 SNMP Traps

Trap Category Trap Description
SNMP Link Up Indicates that an Ethernet interface has come up.
Link Down Indicates that an Ethernet interface has gone down.
System Start Indicates that the ACOS device has started.
Shutdown Indicates that the ACOS device has shut down.
Restart Indicates that the ACOS device is going to reboot or reload.
Control CPU utilization Indicates that the control CPU utilization is higher than the
configured threshold.*
Data CPU utilization Indicates that data CPU utilization is higher than the config-
ured threshold.*
High Temperature Indicates that the temperature inside the ACOS chassis is
higher than the configured threshold.*
If you see this trap, check for fan failure traps. Also check
the installation location to ensure that the chassis room tem-
perature is not too high (40 C or higher) and that the chassis
is receiving adequate air flow.
Fan Failure Indicates that a system fan has failed. Contact A10 Net-
works.
Power Supply Failure Indicates that a power supply has failed. Contact A10 Net-
works.
Primary Hard Disk Indicates that the primary Hard Disk has failed or the RAID
system has failed. Contact A10 Networks. In dual-disk mod-
els, the primary Hard Disk is the one on the left, as you are
facing the front of the ACOS chassis.
Note: This trap applies only to models that use disk drives.
Secondary Hard Disk Indicates that the secondary Hard Disk has failed or the
RAID system has failed. Contact A10 Networks. The sec-
ondary Hard Disk is the one on the right, as you are facing
the front of the ACOS chassis.
Note: This trap applies only to models that use disk drives.
High Disk Usage Indicates that hard disk usage on the ACOS device is higher
than the configured threshold.*
High Memory Usage Indicates that the memory usage on the ACOS device is
higher than the configured threshold.*
Packet Buffer drop† Indicates that the ACOS device is dropping too many pack-
ets.*

TABLE 3 SNMP Traps (Continued)
Network Trunk Ports Threshold Indicates that the trunk ports threshold feature has disabled
trunk members because the number of up ports in the trunk
has fallen below the configured threshold.
Routing IS-IS Indicates routing events for Intermediate System To Inter-
mediate System (IS-IS) routing.
(For the complete list, enter the see the GUI or enter the fol-
lowing: snmp-server enable traps routing isis ?)
OSPF Indicates routing events for Open Shortest Path First (OSPF)
routing.
(For the complete list, enter the see the GUI or enter the fol-
lowing: snmp-server enable traps routing ospf ?)
High Availability (HA) Active Indicates that the ACOS device is going from HA Standby
mode to Active mode.
Standby Indicates that the ACOS device is going from HA Active
mode to Standby mode.
Active-Active Indicates that an Active-Active HA configuration has been
enabled.
VRRP Indicates that a VRID has changed state between active and
standby.

TABLE 3 SNMP Traps (Continued)
Server Load Balancing Server Up Indicates that an SLB server has come up.
(SLB) Server Down Indicates that an SLB server has gone down.
Service Up Indicates that an SLB service has come up.
Service Down Indicates that an SLB service has gone down.
Server Connection Indicates that an SLB server has reached its configured con-
Limit nection limit.
Server Connection Indicates that an SLB server has reached its configured con-
Resume nection-resume value.
Service Connection Indicates that an SLB service has reached its configured
Limit connection limit.
Service Connection Indicates that an SLB service has reached its configured
Resume connection-resume value.
Virtual Server Indicates that the connection limit configured on a virtual
Connection Limit server has been exceeded.
Virtual Port Indicates that the connection limit configured on a virtual
Connection Limit port has been exceeded.
Virtual Server Indicates that the connection rate limit configured on a vir-
Connection-Rate Limit tual server has been exceeded.
Virtual Port Indicates that the connection rate limit configured on a vir-
Connection-Rate Limit tual port has been exceeded.
Virtual Port Up Indicates that an SLB virtual service port has come up. An
SLB virtual server’s service port is up when at least one
member (real server and real port) in the service group
bound to the virtual port is up.
Virtual Port Down Indicates that an SLB virtual service port has gone down.
Application Buffer Indicates that the configured SLB application buffer thresh-
Threshold old has been exceeded.*
*. The thresholds are configurable. The configurable ranges and default threshold values may depend on the event type and
on the A10 Thunder Series or AX Series model. To use the GUI, navigate to Config > System > Settings > General >
Threshold. In the CLI, use the monitor command at the global configuration level.
†. This trap is not applicable to some device types. The trap is applicable to hardware-based A10 Thunder Series or AX
Series models and SoftAX.
SNMP Communities and Views

You can allow external SNMP managers to access the values of MIB
objects from the ACOS device. To allow remote read-only access to ACOS
MIB objects, configure one or both of the following types of access.
SNMP Community Strings

An SNMP community string is a string that an SNMP manager can present
to the ACOS device when requesting MIB values.

Community strings are similar to passwords. You can minimize security risk
by applying the same principles to selecting a community name as you
would to selecting a password. Use a hard-to-guess string and avoid use of
commonly used community names such as “public” or “private”.
You also can restrict access to specific Object IDs (OIDs) within the MIB,
on an individual community basis. OIDs indicate the position of a set of
MIB objects in the global MIB tree. The OID for A10 Networks
A10 Thunder Series and AX Series objects is 1.3.6.1.4.1.22610.
SNMP Views
An SNMP view is like a filter that permits or denies access to a specific OID
or portions of an OID. You can configure SNMP user groups and individual
SNMP users, and allow or disallow them to read specific portions of the
ACOS MIBs using different views.
When you configure an SNMP user group or user, you specify the SNMP
version. SNMP v1 and v2c do not support authentication or encryption of
SNMP packets. SNMPv3 does. You can enable authentication, encryption,
or both, on an individual SNMP user-group basis when you configure the
groups. You can specify the authentication method and the password for
individual SNMP users when you configure the users.
SNMP Configuration Steps
To configure SNMP:
1. Optionally, configure location and contact information.
2. Optionally, configure external SNMP trap receivers.
3. Optionally, configure one or more read-only communities.
4. Optionally, configure views, groups, and users.
5. Enable the SNMP agent and SNMP traps.
6. Save the configuration changes.
You are not required to perform these configuration tasks in precisely this
order. The workflow in the GUI is slightly different from the workflow
shown here.
Note: By default, the ACOS device can reach remote logging and trap servers
only if they are reachable through the ACOS device’s data ports, not the
management port. To enable the ACOS device to reach remote logging

and trap servers through the management port, see “Specifying the Source
Interface for Management Traffic” on page 537.
USING THE GUI
Note: To configure support for SNMPv3 or to configure views, groups, and

users, use the CLI. The current release does not support configuration of
SNMPv3 using the GUI.
1. Select Config Mode > System > SNMP.
2. In the General section, configure general settings:

a. To enable SNMP, select Enabled next to System SNMP Service.
b. In the System Location field, enter a description of the ACOS
device’s location.
c. In the System Contact field, enter the name or email address of the
administrator to contact for system issues.
3. In the Community section, configure community strings:

a. Click Community.
b. In the SNMP Community field, enter a community name.
c. To restrict SNMP access to a specific host or subnet, enter a host-
name or an IP address and network mask in the Hostname (IP/
Mask) field.
By default, any host can access the SNMP agent on the ACOS
device.
d. In the Object Identifier field, enter the OID at which SNMP man-
agement applications can reach the ACOS device.
e. Click Add.
f. Repeat step b through step e for each combination of community
string, management host, and OID.
4. In the Trap section, specify external trap receivers:

a. Click Trap.
b. In the Community field, enter the name of the community sending
the traps.
c. In the IP Address (host) field, enter the IP address or fully-qualified
hostname of the SNMP trap receiver.
d. If the trap receiver does not use the standard protocol port to listen
for traps, change the port number in the Port field.

e. Select SNMP the version from the Version drop-down list:
• V1
• V2c
f. Click Add to add the receiver.
g. Repeat step b through step f for each trap receiver.
5. In the Trap List section, enable traps:

a. Click Trap List.
b. To enable all traps, select All Traps. Otherwise, select the individual
traps you want to enable.
6. Click OK.
7. To save the configuration changes, click the Save button.
Note: When there are unsaved configuration changes on the ACOS device, the
Save button flashes.
USING THE CLI

All SNMP configuration commands are available at the global configura-
tion level of the CLI.
1. To configure location and contact information, use the following com-
mands:
snmp-server location location
snmp-server contact contact-name
2. To configure external SNMP trap receivers, use the following com-

mand:
snmp-server host trap-receiver
[version {v1 | v2c}]
community-string
[udp-port port-num]
3. To configure one or more read-only communities, use the following

command:
snmp-server community read ro-community-string
[oid oid-value]
[remote {hostname | ipaddr mask-length |
ipv6-addr/prefix-length}]

4. To configure views, groups, and users, use the following commands:
snmp-server view view-name oid [oid-mask]
{included | excluded}
snmp-server group group-name
{v1 | v2c | v3 {auth | noauth | priv}}
read view-name
snmp-server user username group groupname
{v1 | v2 | v3 [auth {md5 | sha} password
[encrypted]]}
5. To enable the SNMP agent and SNMP traps, use the following com-
mand:
snmp-server enable
[
traps [
snmp [trap-name] |
system [trap-name] |
network [trap-name] |
ha [trap-name] |
slb [trap-name]
]
]
6. To save the configuration changes, use the following command at the

Privileged EXEC level or any configuration level of the CLI:
write memory
SNMP Source Interface for Notifications

The current release extends SNMP support by allowing you to specify a
data interface to use as the source interface for SNMP traps.
While previous releases sent SNMP traps from the management port of the
ACOS device, the SNMP Trap Source feature allows you to select a data
interfaces from which to send the traps.
By default, the management interface is the source interface for SNMP

traps.
Details:
• This feature does not support IPv6.
• This feature supports SNMPv1 but not SNMPv2c or SNMPv3.

The interface can be any of the following types:
• Ethernet
• VLAN / VE
• Loopback
When the ACOS device sends an SNMP trap from the data interface you
specify, the “agent-address” in the SNMP trap is the data interface’s IP
address.
USING THE GUI
This feature is not supported in the GUI.
USING THE CLI

To enable the SNMP Trap Source feature, configure an interface (Ethernet,
VE, or Loopback) on the ACOS device, and then use the following com-
mand:
[no] snmp-server trap-source
The no form of the command can be used to disable the feature.
CLI Example
The following command attempts to set a loopback interface as the SNMP
trap source. However, the feature has already been enabled on Ethernet port
1, and only one interface can be enabled for SNMP traps, so this example
shows that the existing trap source will be overwritten with the new one:
ACOS(config)#interface loopback 1
ACOS(config-if:loopback1)#snmp-server trap-source
The trap source already exists for interface eth1. Do you want to overwrite?
[yes/no]:yes
ACOS(config-if:loopback1)#
Console Restart
The current release provides the following new command that enables you
to terminate the current login process and start a new one:
[no] clear console

Configuration Examples
Use this command if you notice that SSH and data traffic still appear to be
operational, though the console session is hung. This may be caused if rima-
cli is in a hung state. rimacli is the process that is automatically invoked
when an admin logs into the ACOS device through an interface address.
This process provides admins access to the Command Line Interface (CLI)
to be able to issue and save commands to configure the system.
To resolve the issue of the hung console, due to an underlying hung rimacli
process, use the clear console command. After the hung login process is
terminated, the console will revert to the login prompt.
CLI Example
For the current session, the following command helps kill the console login
process that is causing the window to hang:
ACOS(config)#clear console
The following examples show how to configure the system settings
described in this chapter.
GUI EXAMPLE
The following examples show the GUI screens used for configuration of the
basic system settings described in this chapter.
Note: The GUI does not support configuration of SNMPv3 settings.
FIGURE 6 Config Mode > Network > DNS

FIGURE 7 Config Mode > System > Setting > Time

FIGURE 8 Config Mode > System > Settings > Log

FIGURE 9 Config Mode > System > SNMP
FIGURE 10 Save Button

CLI EXAMPLE
The following commands log onto the CLI, access the global configuration
level, and set the hostname and configure the other DNS settings:
login as: admin
Welcome to ACOS
Password:********
Last login: Tue Jan 13 19:51:56 2009 from 192.168.1.144
[type ? for help]
ACOS>enable
Password:********
ACOS#config
ACOS(config)#hostname ACOS-SLB2
ACOS-SLB2(config)#ip dns suffix ourcorp
ACOS-SLB2(config)#ip dns primary 10.10.20.25
ACOS-SLB2(config)#ip dns secondary 192.168.1.25
The following examples set the login banner to “welcome to login mode”
and set the EXEC banner to “welcome to exec mode”:
ACOS-SLB2(config)#banner login “welcome to login mode”
ACOS-SLB2(config)#banner exec “welcome to exec mode”
The following commands set the timezone and NTP parameters:

ACOS-SLB2(config)#clock timezone ?
Pacific/Midway (GMT-11:00)Midway Island, Samoa
Pacific/Honolulu (GMT-10:00)Hawaii
America/Anchorage (GMT-09:00)Alaska
America/Tijuana (GMT-08:00)Pacific Time(US & Canada); Tijuana
America/Los_Angeles (GMT-08:00)Pacific Time
...
ACOS-SLB2(config)#clock timezone America/Los_Angeles

ACOS-SLB2(config)#ntp server 10.1.4.20
ACOS-SLB2(config)#ntp server enable
The following commands configure the ACOS device to send system log
messages to an external syslog server and to email Emergency messages to
the system admins. In this example, the message levels sent to the external
server are left at the default, Error (3) and above. By default, the same mes-

Replacing the Web Certificate
sage levels are sent to the management terminal in CLI sessions. The mes-
sage level emailed to admins is set to Emergency (0) messages only.
ACOS-SLB2(config)#logging host 192.168.10.10
ACOS-SLB2(config)#smtp ourmailsrvr
ACOS-SLB2(config)#logging email-address admin1@example.com admin2@exam-
ple.com
ACOS-SLB2(config)#logging email 0
The following commands enable SNMP and all traps, configure the ACOS
device to send traps to an external trap receiver, and configure a community
string for use by external SNMP managers to read MIB data from the
ACOS device.
ACOS-SLB2(config)#snmp-server location ourcorp-HQ
ACOS-SLB2(config)#snmp-server contact Me_admin1
ACOS-SLB2(config)#snmp-server enable trap
ACOS-SLB2(config)#snmp-server community read ourcorpsnmp
ACOS-SLB2(config)#snmp-server host 192.168.10.11 ourcorpsnmp
The following command saves the configuration changes to the startup-con-

fig. This is the file from which the ACOS device loads the configuration fol-
lowing a reboot.
ACOS-SLB2(config)#write memory

You can replace the web certificate shipped with the ACOS device. Replac-
ing the certificate with a CA-signed certificate prevents the certificate warn-
ing from being displayed by your browser when you log onto the GUI.
USING THE GUI

1. Select Config Mode > System > Settings > Web Certificate.
2. Select the location(s) of the certificate and key files to be imported:

• Local – The file is on the PC you are using to run the GUI, or is on
another PC or server in the local network. Go to step 3.
• Remote – The file is on a remote server. Go to step 5.
Likewise, to import certificate chains, select the location.
3. Click Browse and navigate to the location of the class list.

4. Click Open. The path and filename appear in the Source field. Go to
step 11.
5. To use the management interface as the source interface for the connec-
tion to the remote device, select Use Management Port. Otherwise, the
ACOS device will attempt to reach the remote server through a data
interface.
6. Select the file transfer protocol: FTP, TFTP, RCP, SCP, or SFTP.
7. In the Host field, enter the directory path and filename.
8. Specify the Key Source.
9. If needed, change the protocol port number n the port field. By default,
the default port number for the selected file transfer protocol is used.
10. In the User and Password fields, enter the username and password
required for access to the remote server.
11. Click OK.
USING THE CLI
Use the following command at the global configuration level of the CLI:
certificate-reset

Emailing Log Messages

You can configure the ACOS device to email log messages, using email log
filters. By default, emailing of log messages is disabled.
Log email filters consist of the following parameters:

• Filter ID – Filter number, 1-8.
• Conditions – One or more of the following:

• Severity – Severity levels of messages to send in email. If you do
not specify a message level, messages of any severity level match
the filter and can be emailed.
• Software Module – Software modules for which to email messages.
Messages are emailed only if they come from one of the specified
software modules. If you do not specify a software module, mes-
sages from all modules match the filter and can be emailed.
• Regular Expression (Patterns and Operators) – Message text to
match on. Standard regular expression syntax is supported. Only
messages that meet the criteria of the regular expression can be
emailed. The regular expression can be a simple text string or a
more complex expression using standard regular expression logic. If
you do not specify a regular expression, messages with any text
match the filter and can be emailed.
The operators (AND, OR, NOT) specify how the conditions should
be compared. (See ““Boolean Operators” on page 80”.)
• Trigger option – Specifies whether to buffer matching messages or send
them immediately.
Boolean Operators
A logging email filter consists of a set of conditions joined by Boolean
expressions (AND / OR / NOT).
The CLI Boolean expression syntax is based on Reverse Polish Notation

(also called Postfix Notation), a notation method that places an operator
(AND, OR, NOT) after all of its operands (in this case, the conditions list).
After listing all the conditions, specify the Boolean operator(s). The follow-
ing operators are supported:
• AND – All conditions must match in order for a log message to be
emailed.
• OR – Any one or more of the conditions must match in order for a log
message to be emailed.

• NOT – A log message is emailed only if it does not match the conditions
(For more information about Reverse Polish Notation, see the following
link: http://en.wikipedia.org/wiki/Reverse_Polish_notation.)
USING THE GUI

1. Select Config Mode > System > Settings > Log.
FIGURE 11 Config Mode > System > Settings > Log
2. In the Logging Email Filter section, click Add. A configuration page for
the filter appears.
3. In the ID field, enter the filter ID, 1-8.
4. To immediately send matching messages in an email instead of buffer-

ing them, select Trigger. Otherwise, matching messages are buffered
until the message buffer becomes full or the send timer for emailed log
messages expires.

5. Construct the rest of the filter by selecting the conditions.
Note: The conditions must be selected in the order described here. Otherwise,
the filter will be invalid. If you accidentally configure an invalid filter,
you can click Clear to remove the filter conditions and start again.
a. Select the message severity level from the Level drop-down list, and
click Add. To add more severity levels, repeat this step for each
severity level.
b. Optionally, select a software module from the Module drop-down
list, and click Add. To add more modules, repeat this step for each
module.
c. Optionally, enter a regular expression in the Pattern field to specify
message text to match on, and click Add.
d. Select the operator from the Operator drop-down list, and click Add.
6. Click OK. The new filter appears in the Logging Email Filter section on
the Log page.
7. Optionally, to change the maximum number of log messages to buffer

before sending them in email, edit the number in the Logging Email
Buffer Number field. You can specify 16-256 messages. The default is
50.
8. Optionally, to change the number of minutes the ACOS device waits

before sending all buffered messages, edit the number in the Logging
Email Buffer Time field. This option takes effect if the buffer does not
reach the maximum number of messages allowed. You can specify 10-
1440 minutes. The default is 10.
9. When finished configuring log settings, click OK.
10. From the Audit tab, indicate your configuration choices:

a. Choose Enable to commence logging of configuration commands.
b. Choose Disable to turn off auditing capabilities.
c. Choose Enable Privilege to log configuration commands and opera-
tional commands.
d. In the Audit Buffer Size menu, indicate the number of entries the
audit log can hold.

FIGURE 12 Config Mode > System > Settings > Log - Audit
e. When the log is full, the oldest entries are removed to make room
for new entries. The typical size is between 1000-30000 entries. The
default is 20000.
11. From the Log Status section, enter the following information:
FIGURE 13 Config Mode > System > Settings > Log - Status
a. Configure the log levels that will be displayed on the Monitor Mode
> Overview > Status page. You also can change the display color for
each message level. By default, all levels are enabled
b. Configure how often the Status page is automatically refreshed. The
time range can be 5-60 seconds. The default is 10 seconds.
c. Configure how many log entries can be views on the Status page.
The range of entries can be from 10-1000 messages. The default is
100 most recent messages.
USING THE CLI

To configure log email settings, use the following commands at the global
configuration level of the CLI:
[no] logging email buffer [number num]

[time minutes]
This command configures message buffering. The number option specifies
the maximum number of messages to buffer. You can specify 16-256. The
default is 50. The time option specifies how long to wait before sending all
buffered messages, if the buffer contains fewer than the maximum allowed
number of messages. You can specify 10-1440 minutes. The default is 10.

Whenever an email is triggered, the email will contain all buffered log mes-
sages.
[no] logging email filter filter-num conditions

operators [trigger]
The filter-num option specifies the filter number, and can be 1-8.
The conditions list can contain one or more of the following:

• level severity-levels – Specifies the severity levels of messages to send
in email. You can specify the severity levels by number (0-7) or by
name: emergency, alert, critical, error, warning, notification, infor-
mation, or debugging.
• mod software-module-name – Specifies the software modules for which
to email messages. Messages are emailed only if they come from one of
the specified software modules. For a list of module names, enter ?
instead of a module name, and press Enter.
• pattern regex – Specifies the string requirements. Standard regular
expression syntax is supported. Only messages that meet the criteria of
the regular expression will be emailed. The regular expression can be a
simple text string or a more complex expression using standard regular
expression logic.
The operators are a set of Boolean operators (AND, OR, NOT) that specify
how the conditions should be compared.
The trigger option immediately sends the matching messages in an email

instead of buffering them. If you omit this option, the messages are buffered
based on the logging email buffer settings.
Considerations
• You can configure up to 8 filters. The filters are used in numerical order,
starting with filter 1. When a message matches a filter, the message will
be emailed based on the buffer settings. No additional filters are used to
examine the message.
• A maximum of 8 conditions are supported in a filter.
• The total number of conditions plus the number of Boolean operators

supported in a filter is 16.
• For backward compatibility, the following syntax from previous releases
is still supported:
logging email severity-level

Increased I/O Buffer Support
The severity-level can be one or more of the following: 0, 1, 2, 5, emer-
gency, alert, critical, notification.
The command is treated as a special filter. This filter is placed into effect
only if the command syntax shown above is in the configuration. The
filter has an implicit trigger option for emergency, alert, and critical
messages, to emulate the behavior in previous releases.
CLI Example
The following command configures the ACOS device to buffer log mes-
sages to be emailed. Messages will be emailed only when the buffer reaches
32 messages, or 30 minutes passes since the previous log message email,
whichever happens first.
ACOS(config)#logging email buffer number 32 time 30
The following command resets the buffer settings to their default values.
ACOS(config)#no logging email buffer number time
The following command configures a filter that matches on log messages if

they are information-level messages and contain the string “abc”. The trig-
ger option is not used, so the messages will be buffered rather than emailed
immediately.
ACOS(config)#logging email filter 1 level information pattern "abc" and
The following command reconfigures the filter to immediately email

matching messages.
ACOS(config)#logging email filter 1 level information pattern "abc" and trigger

The AX 5200-11 and AX 5630 platforms previously supported 4 million
buffers. Beginning with ACOS 2.7.1, these models now support up to 8
million buffers. This enhancement accompanies the following system-wide
improvement: the buffer index is expanded from 22 to 24 bits.
Note: The AX 5200-11 requires 96 Gb of memory to support this feature. To

check that your system meets this requirement, use the show memory
system CLI command, as displayed below:
AX5200-11(config)#show memory system
System Memory Usage:
Total(KB) Free Shared Buffers Cached Usage
---------------------------------------------------------------------------
98154912 73082128 0 24220 198968 25.3%

USING THE GUI
In the current release, enabling this feature is not supported from the GUI.
USING THE CLI
Enter the following command to enable more I/O buffers for the system:
[no] big-buff-pool
Use the no version of the command to remove a larger buffer for the system.
Example:
AX5630(config)#no big-buff-pool
This will modify your boot profile to disable big I/O buffer pool.
It will take effect starting from the next reboot.
Please confirm: You want to disable the big I/O buffer pool(N/Y)?:
Y
Use the following command to view statistics for the I/O buffer pool:
show system platform buffer-stats
Example:
AX5630(config)#show system platform buffer-stats
Buffers available in various states/threads...
-------------------------------------------
Thread Cache App APPQ Misc
-------------------------------------------
Q0 0001ec70 00000000 00000000 00000000
.
.
.
-------------------------------------------
Total=> 003fed27 00000000 00000000 00000000
-------------------------------------------
Approximate # buffers in App_cp 0
Approximate # buffers in Cache_cp 1024
Approximate # buffers in dfree 0
Approximate # buffers free 4199129
Approximate # buffers avail in HW 4183985

Overview
Network Setup
This chapter describes how to add the ACOS device to your network.
Overview
A10 Thunder Series and AX Series devices can be inserted into your net-
work with minimal or no changes to your existing network. You can insert
the ACOS device into your network as a Layer 2 switch (transparent mode)
or a Layer 3 router (route mode).
In either deployment mode, the ACOS device has a dedicated Ethernet man-
agement interface, separate from the Ethernet data interfaces. You can
assign an IPv4 address and an IPv6 address to the management interface.
This chapter provides the following configuration examples:

• “Management Interface Configuration” on page 91
• “Transparent Mode Deployment” on page 95
• “Route Mode Deployment” on page 97
Trunk Support
The ACOS device supports aggregation of multiple Ethernet data ports into
logical links, called “trunks”. Trunks can enhance performance by provid-
ing higher throughput and greater link reliability.
You can configure the following types of trunks:

• Static trunks – You can configure static trunks containing 2-8 Ethernet
data ports.
• Dynamic trunks – You can enable Link Aggregation Control Protocol
(LACP) on Ethernet data interfaces, to make those interfaces candidate
members of dynamically configured trunks.
Up to 16 trunks are supported, in any combination of static and dynamic

trunks.
Although this chapter does not show trunking examples, the following
chapter does: “Link Trunking” on page 107

Overview
Virtual LAN Support

A VLAN is a Layer 2 broadcast domain. MAC-layer broadcast traffic can
be flooded within the VLAN but does not cross to other VLANs. For traffic
to go from one VLAN to another, it must be routed.
You can segment the ACOS device into multiple VLANs. Each Ethernet
data port can be a member of one or more VLANs, depending on whether
the port is tagged or untagged:
• Tagged – Tagged ports can be members of multiple VLANs. The port
can recognize the VLAN to which a packet belongs based on the VLAN
tag included in the packet.
• Untagged – Untagged ports can belong to only a single VLAN. By
default, all Ethernet data ports are untagged members of VLAN 1.
Note: A port actually can be an untagged member of a single VLAN, and also a
tagged member of one or more other VLANs. For example, to add a port
to a new VLAN, it is not required either to remove the port from VLAN 1,
or to change its status in VLAN 1 from untagged to tagged.
Default VLAN (VLAN 1)

By default, all the ACOS device’s Ethernet data ports are members of a sin-
gle virtual LAN (VLAN), VLAN 1.
On a new or unconfigured ACOS device, as soon as you configure an IP

interface on any individual Ethernet data port or trunk interface, Layer 2
forwarding on VLAN 1 is disabled.
When Layer 2 forwarding on VLAN 1 is disabled, broadcast, multicast, and

unknown unicast packets are dropped instead of being forwarded. Learning
is also disabled on the VLAN. However, packets for the ACOS device itself
(ex: LACP, HA, OSPF) are not dropped.
To re-enable Layer 2 forwarding on VLAN 1, use the following command

at the global configuration level of the CLI:
enable-def-vlan-l2-forwarding
Note: Configuring an IP interface on an individual Ethernet interface indicates

you are deploying in route mode (also called “gateway mode”). If you
deploy in transparent mode instead, in which the ACOS device has a sin-
gle IP address for all data interfaces, Layer 2 forwarding is left enabled by
default on VLAN 1.

Overview
Virtual Ethernet Interfaces
On ACOS devices deployed in route mode (Layer 3 mode), you can config-
ure IP interfaces on VLANs. To configure an IP interface on a VLAN, add a
Virtual Ethernet (VE) interface to the VLAN, then assign the IP interface to
the VE.
Each VLAN can have one VE. The VE ID must be the same as the VLAN
ID. For example, VLAN 2 can have VE 2, VLAN 3 can have VE 3, and so
on.
Maximum Number of Supported Virtual Ethernet Interfaces
• For all FPGA models: 128 VEs on a single port*
• For non-FPGA models: 128 VEs on a single port
• For private partitions enabled for Layer 2/3 virtualization (both FPGA
and non-FPGA models): 32 VEs on a single port
IP Subnet Support
The ACOS device has a management interface and data interfaces. The
management interface is a physical Ethernet port. A data interface is a phys-
ical Ethernet port, a trunk group, or a Virtual Ethernet (VE) interface.
The management interface can have a single IPv4 address and a single IPv6
address.
An ACOS device deployed in transparent mode (Layer 2) can have a single

IP address for all data interfaces. The IP address of the data interfaces must
be in a different subnet than the management interface’s address.
An ACOS device deployed in route mode (Layer 3) can have separate IP

addresses on each data interface. No two interfaces can have IP addresses
that are in the same subnet. This applies to the management interface and all
data interfaces.
*.
An exception is model AX 5200, which supports 384.

Overview
Routing Support
The ACOS device supports the following dynamic routing protocols:
• Open Shortest Path First (OSPF) version 2 for IPv4 and OSPFv3 for
IPv6
• Intermediate System to Intermediate System (IS-IS) for IPv4 and IPv6
• Border Gateway Protocol version 4 with multiprotocol extensions

(BGP4+), for IPv6 and IPv4
• Routing Information Protocol (RIP) for a single IPv4 RIP process and a
single IPv6 RIP process.
For OSPF information, see the following:

• “Open Shortest Path First (OSPF)” on page 169
• CLI Reference
For IS-IS, BGP, and RIP information, see the CLI Reference.
Note: It is recommended to set a fixed router-ID for all dynamic routing proto-
cols you plan to use on the ACOS device, to prevent router-ID changes
caused by HA or VRRP-A failover.
Gateway Health Monitoring

You can configure the ACOS device to monitor the health (Layer 3 reach-
ability) of its nexthop gateways. Gateway health monitoring provides more
efficient routing by sending traffic only to available gateways.
For more information, see “Gateway Health Monitoring” on page 165.
Partitioning with ADPs

The ACOS device provides Advanced Delivery Partitions (ADP) that can
allow the device to be segmented virtually to operate and behave like sepa-
rate entities. These partitions can either be Role Based Administration
(RBA) partitions or Layer 3 Virtualization (L3V) partitions.
RBA partitions provide Layer 4-7 support and no direct access to system
and networking resources. RBA partitions are dependent on the shared par-
tition’s network resources. For details on RBA partitions, refer to “Role
Based Administration Private Partition” on page 219.

Management Interface Configuration
Layer 2/3 virtualization is a feature that enables you to partition the ACOS
device into multiple virtual devices, each with its own completely separate
Layer 2/3 networking resources.
L3V partitions allow for the ACOS device to be partitioned into multiple
virtual devices, each with their own administrators. From a partition admin-
istrator’s point of view, they have management control of a complete, anton-
ymous device, separate from the other virtual devices (partitions).
L3V allows administrators to configure and view network and SLB

resources based on administrative domains (“partitions”). In addition to pro-
viding separate partitions for these types of resources, L3V partitions sup-
port direct access to networking resources per partition. Layer 2/3
virtualization can be enabled on individual partitions, allowing partitions to
own their own network resources.
For more information, see “Layer 3 Virtualization of Private Partitions” on

page 227.
High Availability
You can deploy the ACOS device as a single unit or as a High Availability
(HA) pair. Deploying a pair of ACOS devices in an HA configuration pro-
vides an extra level of redundancy to help ensure your site remains available
to clients. For simplicity, the examples in this chapter show deployment of a
single ACOS device. For information about HA, see the following chapters:
• “VRRP-A High Availability” on page 355
• “High Availability” on page 267

The management interface (MGMT) is an Ethernet interface to which you
can assign a single IPv4 address and a single IPv6 address. The manage-
ment interface is separate from the Ethernet data interfaces.
Figure 14 shows an example of the management interface on an
A10 Thunder Series and AX Series device.

FIGURE 14 ACOS Deployment Example – Management Interface
By default, the ACOS device attempts to use a route from the main route
table for management connections originated on the ACOS device. You can
enable the ACOS device to use the management route table to initiate man-
agement connections instead. (For information, see “Specifying the Source
Interface for Management Traffic” on page 537.)
Note: The ACOS device allows the same IP address to be configured as the
ACOS device’s global IP address, and as a NAT pool address. However,
in Layer 2 (transparent) deployments, if you do configure the same
address in both places, and later delete one of the addresses, you must
reload the ACOS device to place the change into effect.
Configuration Example
This section shows the GUI screens and CLI commands needed to config-
ure the management interface as shown in Figure 14.
USING THE GUI

1. Log into the GUI.
Note: Unless you have already configured an IP interface, navigate to the

default IP address: http://172.31.31.31.
2. Select Config Mode > Network > Interface > Management. (See
Figure 15.)
Figure 15 shows the GUI screen used to configure the management IP
addresses shown in Figure 14. Here and elsewhere in this guide, the
command paths used to access a GUI screen are listed in the figure cap-
tion.

3. In the IPv4 section, enter the IPv4 address, network mask, and default
gateway address.
4. In the IPv6 section, enter the IPv6 address, prefix length, and default
gateway address.
5. Click OK.
FIGURE 15 Config Mode > Network > Interface > Management
USING THE CLI
The following commands access the global configuration level of the CLI:
login as: admin
Welcome to AOCS
Password:***
[type ? for help]
AOCS>enable
Password:(just press Enter on a new system)
AOCS#
AOCS#config
AOCS(config)#

The following commands configure IPv6 access on the management inter-
face:
AOCS(config)#interface management
AOCS(config-if:mgmt)#ipv6 address 2001:db8::2/32
AOCS(config-if:mgmt)#ipv6 default-gateway 2001:db8::1
The following commands configure IPv4 access on the management inter-

face:
AOCS(config)#interface management
AOCS(config-if:mgmt)#ip address 192.168.2.228 /24
AOCS(config-if:mgmt)#ip default-gateway 192.168.2.1
The following commands verify the configuration:

AOCS(config-if:mgmt)#show interface management
GigabitEthernet 0 is up, line protocol is up.
Hardware is GigabitEthernet, Address is 0090.0b0b.ea38
Internet address is 192.168.10.2, Subnet mask is 255.255.255.0
Internet V6 address is 2001:db8::2/32
Configured Speed auto, Actual 1000, Configured Duplex auto, Actual fdx
Flow Control is disabled, IP MTU is 1500 bytes
781 packets input, 58808 bytes
Received 33 broadcasts, Received 66 multicasts, Received 662 unicasts
0 input errors, 0 CRC 0 frame
0 runts 0 giants
924 packets output 3549 bytes
Transmitted 157 broadcasts 7 multicasts 770 unicasts
0 output errors 0 collisions

Transparent Mode Deployment

Figure 16 shows an example of an A10 Thunder Series and AX Series
device deployed in transparent mode.
FIGURE 16 ACOS Deployment Example – Transparent Mode
Note: For simplicity, this example and the other examples in this chapter show
the physical links on single Ethernet ports. Everywhere a single Ethernet
connection is shown, you can use a trunk, which is a set of multiple ports
configured as a single logical link.
This section shows the GUI screens and CLI commands needed to deploy
the ACOS device as shown in Figure 16.
USING THE GUI

1. Select Config Mode > Network > Interface > Transparent. (See
Figure 17.)
2. Enter the IP address, mask or prefix length, and gateway address.
3. Click OK.
4. On the menu bar, click LAN. The data interface table appears. (See
Figure 18.)
5. Select the checkbox next to each Ethernet data interface to enable.
6. Click Enable.

FIGURE 17 Config Mode > Network > Interface > Transparent
FIGURE 18 Config Mode > Network > Interface > LAN
USING THE CLI

The following commands configure the global IP address and default gate-
way:
AOCS(config)#ip address 10.10.10.2 /24
AOCS(config)#ip default-gateway 10.10.10.1
The following commands enable the Ethernet interfaces used in the exam-
ple:
AOCS(config)#interface ethernet 1
AOCS(config-if:ethernet1)#enable
AOCS(config-if:ethernet1)#interface ethernet 2

Route Mode Deployment
AOCS(config-if:ethernet3)#exit

Figure 19 shows an example of an ACOS device deployed in route mode.
Note: Route mode is also called “gateway” mode.
FIGURE 19 ACOS Deployment Example – Route Mode
In this example, the ACOS device has separate IP interfaces in different

subnets on each of the interfaces connected to the network. The ACOS
device can be configured with static IP routes and can be enabled to run
OSPF and IS-IS. In this example, a static route is configured to use as the
default route through 10.10.10.1.
Although this example shows single physical links, you could use trunks as
physical links. You also could use multiple VLANs. In this case, the IP
addresses would be configured on Virtual Ethernet (VE) interfaces, one per
VLAN, instead of being configured on individual Ethernet ports.
Since the ACOS device is a router in this deployment, downstream devices

can use the ACOS device as their default gateway. For example, devices
connected to Ethernet port 2 would use 192.168.3.100 as their default gate-
way, devices connected to port 3 would use 192.168.1.111 as their default
gateway, and so on.

If a pair of ACOS devices in a High Availability (HA) configuration is used,
the downstream devices would use a floating IP address shared by the two
ACOS devices as their default gateway. (For more on HA, see “High Avail-
ability” on page 267.)
This section shows the GUI screens and CLI commands needed to imple-
ment the configuration shown in Figure 19.
USING THE GUI

1. Select Config Mode > Network > Interface > LAN.
2. Click on the interface name (for example, “e1”). The configuration page
for the port appears. (See Figure 20.)
3. To assign an IPv4 address, click “IPv4” to display the configuration

fields for that section, and enter the address information.
4. To assign an IPv6 address, click “IPv6” to display the configuration

fields for that section, and enter the address information.
5. Click OK.
Configuring the Default Route

1. Select Config Mode > Network > Route > IPv4 Static (or IPv6 Static)
> .
2. Enter the route information. (For an IPv4 example, see Figure 21.)
3. Click OK.

FIGURE 20 Config Mode > Network > Interface > LAN - Ethernet data port
1 selected
FIGURE 21 Config Mode > Network > Route > IPv4 Static

FIGURE 22 Config Mode > Network > Route > IPv6Static
USING THE CLI
The following commands enable the Ethernet interfaces used in the exam-
ple and configure IP addresses on them:
AOCS(config)#interface ethernet 1
AOCS(config-if:ethernet1)#ip address 10.10.10.2 /24
The following command configures the default route through 10.10.10.1:

AOCS(config)#ip route 0.0.0.0 /0 10.10.10.1

Jumbo Frames
The current release adds support for jumbo frames. A jumbo frame is an
Ethernet frame that is more than 1522 bytes long.
By default, the maximum transmission unit (MTU) on all physical Ethernet

interfaces is 1500 bytes. The default Ethernet frame size is 1522 bytes,
which includes 1500 bytes for the payload, 14 bytes for the Ethernet header,
4 bytes for the CRC, and 4 bytes for a VLAN tag. Jumbo support is disabled
by default.
You can enable jumbo support on a global basis. In this case, the MTU is
not automatically changed on any interfaces, but you can increase the MTU
on individual interfaces.
• On FPGA models, you can increase the MTU on individual Ethernet
interfaces up to 12000 bytes.
• On non-FPGA models, you can increase the MTU on individual Ether-
net interfaces up to 9216 bytes.
Notes:
• If your configuration uses VEs, you must enable jumbo on the individ-
ual Ethernet ports first, then enable it on the VEs that use the ports. If
the VE uses more than port, the MTU on the VE should be the same or
smaller than the MTU on each port.
• Enabling jumbo support does not automatically change the MTU on any
interfaces. You must explicitly increase the MTU on those interfaces
you plan to use for jumbo packets.
• Jumbo support is not recommended on 10/100 Mbps ports.
• On FPGA models only, for any incoming jumbo frame, if the outgoing
MTU is less than the incoming frame size, the ACOS device fragments
the frame into 1500-byte fragments, regardless of the MTU set on the
outbound interface. If it is less than 1500 bytes, it will be fragmented
into the configured MTU.

• Setting the MTU on an interface indirectly sets the frame size of incom-
ing packets to the same value. (This is the maximum receive unit
[MRU]).
• In previous releases, the default MTU is 1500 and can not be set to a
higher value.
• Jumbo frames are not supported on models AX 1030, AX 2500,
AX 2600, SoftAX, or AX-V 3000-11-GCF.
Caution: On non-FPGA models, after you enable (or disable) jumbo frame
support, you must save the configuration and reboot to place the
change into effect.
If jumbo support is enabled on a non-FPGA model and you erase the
startup-config, the device is rebooted after the configuration is
erased.
USING THE GUI
Enabling Jumbo Support (FPGA models)

1. Select Config Mode > Network > Interface > Global.
2. Select Enabled next to Jumbo Frame.
3. Click OK.
Enabling Jumbo Support (non-FPGA models)

If you are using a non-FPGA model (see above):
2. Select Enabled next to Jumbo Frame.
3. Click OK.
4. Click Save at the top of the GUI window to save the configuration
change.
5. Select Config Mode > System > Settings > Action > Reboot.
Changing the MTU on an Interface

2. Click on the interface number, in the Interface column. The configura-

tion page for the interface appears.

3. Edit the value in the MTU field.
4. Click OK.
Disabling Jumbo Support (FPGA models)

On each interface with an MTU higher than 1500 bytes:
2. Click on the interface number, in the Interface column. The configura-

tion page for the interface appears.
3. Edit the value in the MTU field to be 1500 (or less).
4. Click OK.
5. Repeat for each interface on which the MTU is greater than 1500 bytes.
7. Select Disabled next to Jumbo Frame.
8. Click OK.
Disabling Jumbo Support (non-FPGA models)

If you are using a non-FPGA model:
2. Click on an interface number, in the Interface column. The configuration

page for the interface appears.
3. Edit the value in the MTU field to be 1500 (or less).
4. Click OK.
5. Repeat for each interface on which the MTU is greater than 1500 bytes.
7. Select Disabled next to Jumbo Frame.
8. Click OK.
9. Click Save at the top of the GUI window to save the configuration
change.
10. Select Config Mode > System > Settings > Action > Reboot.

Caution: On non-FPGA models, you must save the configuration and reboot
after entering the “no enable-jumbo” command. If you reload or
reboot without first saving the configuration, the feature can not be
re-enabled until you first repeat the procedure above to disable it.
Then, you can re-enable the feature.
USING THE CLI
Enabling Jumbo Support (FPGA models)

To globally enable jumbo support, use the following command at the global
enable-jumbo
Enabling Jumbo Support (non-FPGA models)

If you are using a non-FPGA model (see above):
1. Use the following command at the global configuration level of the
CLI: enable-jumbo
2. Enter the following command to save the configuration: write memory
3. Use the following command at the Privileged EXEC level to reboot:

reboot
Changing the MTU on an Interface

To change the MTU on an interface, use the following command at the
configuration level for the interface:
mtu bytes
Disabling Jumbo Support (FPGA models)

1. On each interface with an MTU higher than 1500 bytes, enter the fol-
lowing command: no mtu
2. Use the following command at the global configuration level of the CLI:
no enable-jumbo
Disabling Jumbo Support (non-FPGA models)

If you are using a non-FPGA model:
1. On each interface with an MTU higher than 1500 bytes, enter the fol-
lowing command: no mtu
no enable-jumbo

3. Enter the following command to save the configuration: write memory
4. Use the following command at the Privileged EXEC level to reboot:

reboot
Caution: On non-FPGA models, you must save the configuration and reboot
after entering the “no enable-jumbo” command. If you reload or
reboot without first saving the configuration, the feature can not be
re-enabled until you first repeat the procedure above to disable it.
Then, you can re-enable the feature.
CLI Example
The following commands change the MTU on some Ethernet ports, then
change the MTU to the same value on the VE that uses the ports:
AX3400(config)#interface ethernet 15
AX3400(config-if:ethernet15)#mtu 6000
AX3400(config-if:ethernet15)#interface ethernet 16
AX3400(config-if:ethernet16)#mtu 6000
AX3400(config-if:ethernet16)#vlan 300
AX3400(config-vlan:300)#tagged ethernet 15 to 16
AX3400(config-vlan:300)#router-interface ve 300
AX3400(config-vlan:300)#interface ve 300
AX3400(config-if:ve300)#ip address 10.30.30.30 /24
AX3400(config-if:ve300)#mtu 6000
The following commands show detailed information for the interfaces,

which includes the MTU settings:
AX3400(config-if:ve300)#show interface ve 300
VirtualEthernet 300 is down, line protocol is down
Hardware is VirtualEthernet, Address is 001f.a005.53e6
Router Interface for L2 Vlan 300
IP MTU is 6000 bytes
0 packets input 0 bytes
Transmitted 0 broadcasts, Transmitted 0 multicasts, Transmitted 0 unicasts
AX3400(config-if:ve300)#show interface ethernet 15

Ethernet 15 is disabled, line protocol is down
Hardware is GigabitEthernet, Address is 001f.a005.53e0

Configured Speed auto, Actual unknown Configured Duplex auto, Actual unknown
Member of L2 Vlan 300, Port is Tagged
Port as Mirror disabled, Monitoring this Port disabled
0 runts 0 giants
300 second input rate: 0 bits/sec, 0 packets/sec, 0% utilization
300 second output rate: 0 bits/sec, 0 packets/sec, 0% utilization
AX3400(config-if:ve300)#show interface ethernet 16

Ethernet 16 is disabled, line protocol is down
Configured Speed auto, Actual unknown Configured Duplex auto, Actual unknown
Member of L2 Vlan 300, Port is Tagged
0 runts 0 giants

Overview
Link Trunking
This chapter describes how to configure trunk links on the ACOS device.
Overview
The ACOS device supports aggregation of multiple Ethernet data ports into
logical links, called “trunks”. Trunks can enhance performance by provid-
ing higher throughput and greater link reliability.
Higher throughput is provided by the aggregate throughput of the individual

links in the trunk. Greater link reliability is provided by the multiple links in
the trunk. If an individual port in the trunk goes down, the trunk link contin-
ues to operate using the remaining up ports in the trunk.
You can configure the following types of trunks:

• Static trunks – You can configure up to 16 static trunks. Each trunk can
contain 2-8 Ethernet data ports.
• Dynamic trunks – You can enable Link Aggregation Control Protocol
(LACP) on Ethernet data interfaces, to make those interfaces candidate
members of dynamically configured trunks. You can configure up to 16
dynamic trunks with a maximum of 8 Ethernet data member ports per
trunk.
Interface parameters for a trunk apply collectively to the entire trunk, as a

single interface. For example, IP addresses and other IP parameters apply to
the entire trunk as a single interface.

Static Trunk Configuration

You can configure up to 16 static trunks. Each trunk can contain 2-8 Ether-
net data ports.
USING THE GUI
To configure a static trunk:

1. Go to Config Mode > Network > Trunk.
The following window appears:
2. Click on Add to be able to create a static trunk.

3. Indicate a Trunk ID from 1-16.
4. In the Interface section, click on the interface you want to associate with
the trunk and move the interface from the Available column using the
greater than redirect arrows (>>). If you want to move them back to the
Available column, select the interface, and move it back using the less

than redirect arrows. Similarly, you can move the interface from the Port
to the Disabled Port column.
5. In the Ports Threshold section, do the following:

a. Click the checkbox in the Threshold field and from the drop down
menu, choose a value of 2-8. This field specifies the minimum num-
ber of ports that must be up in order for the trunk to remain up
b. In the Port Threshold Timer field, indicate a timer value from 1-300
seconds. This threshold timer specifies how many seconds to wait
after a port goes down before marking the trunk down, if the thresh-
old is not met. You can set the ports-threshold timer to 1-300 sec-
onds. The default is 10 seconds.
6. Click on OK.
Your static trunk will be added:
USING THE CLI
To configure a static trunk:

1. Add the trunk and configure trunk parameters:
• Port membership. You can add 2-8 Ethernet data ports to the trunk.
• Optionally, configure port-threshold parameters. The port threshold

specifies the minimum number of member ports in the trunk that
must be up, for the trunk itself to remain up.
2. Configure interface-level parameters on the trunk, if applicable:

• Name – You can assign a name to the trunk, in addition to the
numeric ID you specify when you create the trunk. The name can be
1-63 characters in length, can contain numbers, upper case and

lower case characters, and must not include the following symbols:
~!@#$%^&*()_+|}{:”<>?
• IPv4 and IPv6 parameters – You can assign one or more IPv4 and
IPv6 addresses, and configure other IP-related parameters such as
IP helper or IPv6 neighbor discovery.
• Dynamic routing – You can configure interface-level OSPF and
IS-IS parameters.
• Access list (ACL) – You can filter incoming traffic based on source
and destination IPv4 or IPv6 address and protocol port, as well as
additional parameters such as ICMP type and code or VLAN ID.
• ICMP rate limiting – You can enable protection against denial-of-
service (DoS) attacks such as Smurf attacks, which consist of floods
of spoofed broadcast ping messages.
• Layer 3 forwarding – Layer 3 forwarding is enabled by default. You
can disable it.
If you want to allow Layer 3 forwarding except between VLANs, a
separate option allows you to disable Layer 3 forwarding between
VLANs.
Trunk Parameters and Trunk Interface Parameters

You can configure trunk-related parameters at the following configuration
levels:
• Trunk
• Interface
At the trunk configuration level, you can enable or disable the trunk, add or
remove trunk members, and set port-threshold parameters. Using the dis-
able command at the trunk configuration level completely disables all ports
in the trunk.
At the interface configuration level for a trunk, you can configure interface-
related parameters such as IP, IPv6, and routing settings. You also can dis-
able or re-enable Layer 3 forwarding on the trunk.
Using the disable command at the interface configuration level for a trunk
disables Layer 3 forwarding on the trunk but does not completely disable
the trunk.

Configuring Trunk Parameters

To configure trunk parameters, use the following commands.
[no] trunk trunk-id-num

Enter this command at the global configuration level of the CLI. This com-
mand changes the CLI to the configuration level for the specified trunk. The
trunk-id-num can range from 1-16.
Adding Ports to a Trunk
To add Ethernet data ports to the trunk, use the following command:
[no] ethernet portnum

[to portnum] [ethernet portnum] ...
Configuring Port-threshold Parameters
By default, a trunk’s status remains UP so long as at least one of its member

ports is up. You can change the ports threshold of a trunk to 2-8 ports.
If the number of up ports falls below the configured threshold, the ACOS
device automatically disables the trunk’s member ports. The ports are dis-
abled in the running-config. The ACOS device also generates a log message
and an SNMP trap, if these services are enabled.
Note: After the feature has disabled the members of the trunk group, the ports
are not automatically re-enabled. The ports must be re-enabled manually
after the issue that caused the ports to go down has been resolved.
In some situations, a timer is used to delay the ports-threshold action. The

configured port threshold is not enforced until the timer expires. The ports-
threshold timer for a trunk is used in the following situations:
• When a member of the trunk links up.
• A port is added to or removed from the trunk.
• The port threshold for the trunk is configured during runtime. (If the
threshold is set in the startup-config, the timer is not used.)
To configure port-threshold parameters, use the following commands at the

configuration level for the trunk:
[no] ports-threshold num

This command specifies the minimum number of ports that must be up in
order for the trunk to remain up. You can specify 2-8.
If the number of up ports falls below the configured threshold, the ACOS
device automatically disables the trunk’s member ports. The ports are dis-
abled in the running-config. The ACOS device also generates a log message
and an SNMP trap, if these services are enabled.
[no] ports-threshold-timer seconds

This command specifies how many seconds to wait after a port goes down
before marking the trunk down, if the threshold is not met. You can set the
ports-threshold timer to 1-300 seconds. The default is 10 seconds.
Configuring Interface-level Parameters on a Static Trunk
To configure interface-level parameters for the trunk, use the following

command to access the interface configuration level for the trunk:
interface trunk num
mand changes the CLI to the interface configuration level for the specified
trunk, where the following commands are available:
[no] access-list acl-num in
bfd
clear
disable
do
enable
end
exit
[no] icmp-rate-limit options
[no] icmpv6-rate-limit options
[no] interface options
[no] ip options
[no] ipv6 options
[no] isis options
[no] l3-vlan-fwd-disable
[no] mtu options

[no] name string
no
[no] ospf options
show
write
Note: The disable and enable commands at the interface configuration level for
the trunk control Layer 3 forwarding on the trunk but do not completely
disable the trunk. To control all forwarding on the trunk, use the disable
or enable command at the trunk configuration level instead.
For more information about these commands, see the “Config Commands:
Interface” chapter of the CLI Reference.
Static Trunk Configuration Example

The following commands configure trunk 7 with ports 5-8, and verify the
configuration:
ACOS(config)#trunk 7
ACOS(config-trunk:7)#ethernet 5 to 8
ACOS(config-trunk:7)#show trunk
Trunk ID : 7 Member Count: 4
Trunk Status : Up
Members : 5 6 7 8
Cfg Status : Enb Enb Enb Enb
Oper Status : Up Up Up Up
Ports-Threshold : None
Working Lead : 5
ACOS(config-trunk:7)#exit
The following commands access the interface configuration level for the
trunk and assign an IPv6 address to the trunk interface:
ACOS(config)#interface trunk 7
ACOS(config-if:trunk7)#ipv6 address 2001:db8::7/32

Dynamic Trunk Configuration

Link Aggregation Control Protocol (LACP) dynamically creates trunk
links.
The ACOS implementation of LACP is based on the 802.3ad IEEE specifi-

cation.
You can configure a maximum of 16 LACP trunks on an ACOS device. An

interface can belong to a single LACP trunk.
LACP Parameters
The following LACP parameters are configurable.
Global LACP Parameter

• LACP system priority – Specifies the LACP priority of the ACOS
device. In cases where LACP settings on the local device (the ACOS
device) and the remote device at the other end of the link differ, the set-
tings on the device with the higher priority are used.
You can specify 1-65535. A low priority number indicates a high prior-
ity value. The highest priority is 1 and the lowest priority is 65535. The
default is 32768.
Global Parameters for Individual LACP Trunks

• Trunk state – Enabled or disabled. LACP trunks are enabled by default.
• Ports threshold – Minimum number of ports that must be up in order for

the trunk to remain up. If the number of up ports falls below the config-
ured threshold, the ACOS device automatically disables the trunk’s
member ports. The ports are disabled in the running-config. You can
specify 2-8. By default, no port threshold is set. A trunk remains up if
even 1 of its ports is up.
• Ports threshold timer – Number of seconds to wait after a port goes
down before marking the trunk down, if the configured threshold is not
met. You can set the ports-threshold timer to 1-300 seconds. The default
is 10 seconds.

Interface-Level LACP Parameters
• LACP trunk ID – ID of a dynamic trunk. Adding an interface to an
LACP trunk makes that interface a candidate for membership in the
trunk. During negotiation with the other side of the link, LACP selects
the interfaces to actively participate in the link.
You add up to 8 interfaces to an LACP trunk.
When you add an interface, you must specify whether LACP will run in
active or passive mode on the interface. Active mode initiates link for-
mation with the other end of the link. Passive mode waits for the other
end of the link to initiate link formation.
The admin key must match on all interfaces in the trunk. The value can
be 10000-65535.
• LACP port priority – Priority of the interface for selection as an active
member of a link. If the LACP trunk has more candidate members than
are allowed by the device at the other end of the link, LACP selects the
interfaces with the highest port priority values as the active interfaces.
The other interfaces are standbys, and are used only if an active inter-
face goes down.
You can specify 1-65535. A low priority number indicates a high prior-
ity value. The highest priority is 1 and the lowest priority is 65535. The
default is 32768.
• LACP timeout – Aging timeout for LACP data units from the other end
of the LACP link.
You can specify short (3 seconds) or long (90 seconds). The default is
long.
• Mode – Indicate whether you want LACP to operate in Active or Pas-
sive Mode. The Active mode initiates link formation with the other end
of the link. In this case, the ACOS device will send the LACP frame to
its link partner. Passive mode waits for the other end of the link to initi-
ate link formation. In this case, the ACOS device will only send an
LACP frame if it receives an LACP frame from the link partner.
• Admin Key – The admin key must match on all interfaces in the trunk.
The value can be 10000-65535.
• Unidirectional Link Detection (UDLD) – UDLD checks the links in
LACP trunks to ensure that both the send and receive sides of each link
are operational. UDLD can only be configured on the single port LACP
trunk. UDLD is not supported on multilink LACP trunks. (For more
information, see “UDLD” on page 116.)

UDLD
When UDLD is enabled, the UDLD uses LACP protocol packets as heart-
beat messages. If an LACP link on the ACOS device does not receive an
LACP protocol packet within a specified timeout, LACP blocks traffic on
the port. This corrects the problem by forcing the devices connected by the
non-operational link to use other, fully operational links.
A link that is blocked by LACP can still receive LACP protocol packets but
blocks all other traffic.
UDLD is disabled by default on LACP trunk links. You can enable UDLD
on individual LACP trunk interfaces.
Heartbeat Timeout
The local port waits for a configurable timeout to receive an LACP protocol
packet from the remote port. If an LACP protocol packet does not arrive
before the timeout expires, LACP disables the local port. You can set the
timeout to 1-60 seconds (slow timeout) or 100-1000 milliseconds (fast time-
out). The default is 1 second.
If the remote port begins sending LACP protocol packets again, LACP on
the local port re-enables the port.
Requirements
To operate properly, UDLD must be supported and enabled on both devices
that are using LACP trunk links.
It is recommended to use auto-negotiation on each end of the link to estab-

lish the mode (half duplex or full duplex). Auto-negotiation helps ensure
link bidirectionality at Layer 1, while UDLD helps at Layer 2.

Configuration
USING THE GUI
Configuring LACP via the GUI
Configure the global LACP parameter:

1. Go to Config Mode > Network > Interface > LAN.
2. Choose an Ethernet number.


3. Scroll down and click on the LACP tab.
4. Enter the Trunk ID.

The LACP window refreshes and displays additional configuration
options:
5. Enter the LACP priority.
6. Choose a Timeout value of Long or Short.
7. Click the radio button to indicate if LACP should operate in Active or in

Passive mode.
8. Specify an Admin Key.
9. Click the checkbox for Uni-directional Detection.
10. Click OK.
To configure the LACP system priority, follow these steps:

1. Go to Config Mode > Network > LACP.
The following window will appear:

2. Accept the default LACP system priority or change it to the desired
value.
3. Click OK.
Minimum Port Threshold for LACP

This release enhances LACP with support for minimum port thresholds.
Previous releases support minimum port thresholds for static trunks but not
for dynamic (LACP) trunks.
By default, a trunk’s status remains Up so long as at least one of its member

ports is up. You can change the ports threshold of a trunk to 2-8 ports.
Since a trunk comprises of several member links, if the number of opera-

tional members of a trunk goes below the configured threshold value, the
remaining member links are automatically marked as “blocked” and the
trunk is considered non--operational. When the down link is functional
again, the remaining links that were marked blocked are also operational
again, making the trunk available for use.
Note: If you administratively disable the LACP feature from members of the
trunk group, the links are not automatically re-enabled. The links must be
re-enabled manually after the issue that caused the links to go down has
been resolved.
The LACP feature can also be administratively disabled on links in a trunk.
In some situations, a timer is used to delay the ports-threshold action. The

configured port threshold is not enforced until the timer expires. The ports-
threshold timer for a trunk is used in the following situations:
• When a member of the trunk link is up.
• A port is added to or removed from the trunk.
• The port threshold for the trunk is configured during runtime. (If the
threshold is set in the “startup-config” file, the timer is not used.)

USING THE GUI
To configure the port threshold parameters for LACP trunks, do the follow-
ing.
Note: These steps assume that you have already created an LACP dynamic
trunk using Config Mode > Interface > LAN (from the LACP tab). For
details, refer to the System and Administration Guide.
1. Go to Config Mode > Network > Trunk.
2. Click on the existing LACP Trunk 1.

The Trunk >>Create window will appear. You will not be able to edit
any interface information in this window. It is displayed for informa-
tional purposes only. If you want to add any interfaces to this LACP
trunk, you must add these interfaces from the System > LAN > Inter-
faces menu where you originally created the LACP trunk:

3. In the Ports Threshold section, do the following:
a. Click the checkbox in the Threshold field and from the drop down
menu, choose a value of 2-8. This field specifies the minimum num-
ber of ports that must be up in order for the trunk to remain up
b. In the Port Threshold Timer field, indicate a timer value from 1-300
seconds. This threshold timer specifies how many seconds to wait
after a port goes down before marking the trunk down, if the thresh-
old is not met. You can set the ports-threshold timer to 1-300 sec-
onds. The default is 10 seconds.
4. Click on OK.
Verifying Port Threshold Configuration
To verify your LACP configuration of the Port Threshold and the Port
Threshold Timer, do the following:
Go to Monitor Mode > Network > Trunk.

The following window will display the configured Port Threshold Timer of
10 for ethernet3 that belongs to Trunk ID 1:
Monitoring LACP via the GUI
You can monitor LACP from Monitoring Mode. View the following LACP
information:
• Display LACP system IDs.
• Display LACP counters.
• Display LACP trunk administration key list details.
• Display summarized and detailed information on LACP ports and

1-16 trunk lists.
To monitor LACP, do the following:

1. Go to Monitor Mode > Network > LACP > System ID.
The following window will appear displaying information on the
system ID:
2. Go to Monitor Mode > Network > LACP > Counter.

The following window will appear displaying information on the LACP
counters:
3. Go to Monitor Mode > Network > LACP > Trunk.

This menu will display information on Admin Key List, Summary, and
Detail:
a. View information in the trunk Admin Key List tab:

b. View information in the trunk Summary tab:
c. View information in the trunk Detail tab:
USING THE CLI

Configuring each Interface
1. Change the CLI to the configuration level for the interface.
2. Assign the interface to the LACP trunk, using the following command:
[no] lacp trunk lacp-trunk-id [admin-key num]
mode {active | passive}
[unidirectional-detection]
The interface becomes a candidate member of the trunk.
3. (Optional) Specify the LACP priority of the interface, using the follow-
ing command:
[no] lacp port-priority num
You can specify 1-65535. The default is 32768.
4. (Optional) Specify the aging timeout for LACP data units from the other
end of the LACP link, using the following command:
[no] lacp timeout {short | long}
You can specify short (3 seconds) or long (90 seconds). The default
is long.

5. (Optional) Specify the UDLD aging timeout, using the following com-
mand:
[no] lacp udld-timeout {fast | slow} num
You can specify fast (100-1000 milliseconds) or slow (1-60 sec-
onds). The default is slow 1.
Configuring LACP
1. (Optional) Set the LACP system priority, using the following command
[no] lacp system-priority num
You can specify 1-65535. The default is 32768.
2. (Optional) Configure ports-threshold settings:

a. Specify the minimum number of ports that must remain up, using
the following command at the LACP trunk configuration level of
the CLI:
[no] ports-threshold num [do-manual-recovery]
You can specify 2-8 ports.
The do-manual-recovery option disables automatic recovery of the
trunk when the required number of ports come back up. If you use
this option, the trunk remains disabled until you re-enable it.
b. Specify how many seconds to wait after a port goes down before
marking the trunk down, if the configured threshold is not met.
[no] ports-threshold-timer seconds
You can specify 2-8 ports. You can set the ports-threshold timer to
1-300 seconds. The default is 10 seconds.
Configuring Interface-level Parameters on an LACP Trunk
To configure interface-level parameters for the trunk, use the following

command to access the interface configuration level for the trunk:
interface trunk num
mand changes the CLI to the interface configuration level for the specified
trunk, where the following commands are available:
[no] access-list acl-num in
bfd

clear
disable
do
enable
end
exit
[no] icmp-rate-limit options
[no] icmpv6-rate-limit options
[no] interface options
[no] ip options
[no] ipv6 options
[no] isis options
[no] l3-vlan-fwd-disable
[no] mtu options
[no] name string
no
[no] ospf options
show
write
Note: The disable and enable commands at the interface configuration level for
the trunk control Layer 3 forwarding on the trunk but do not completely
disable the trunk. To control all forwarding on the trunk, use the disable
or enable command at the trunk configuration level instead.
For more information about these commands, see the “Config Commands:
Interface” chapter of the CLI Reference.

LACP Passthrough
LACP Passthrough
LACP passthrough allows the ACOS device to forward traffic on one trunk
that originated on another trunk that is down. With this feature, if an LACP
trunk goes down, the other trunk is used to continue connectivity for the
traffic.
This feature can be useful in topologies that use LACP and where multiple
ACOS devices connect to the server farm. In this type of topology, if the
ACOS device acts as a proxy for client-server traffic, LACP passthrough
can help prevent sessions from being dropped following failover from one
LACP trunk to another.
FIGURE 23 LACP Passthrough - Example Topology
LACP passthrough creates a tunnel from one LACP trunk to another

through the ACOS device. One end of the tunnel is connected to clients and
the other end of the tunnel is connected to the servers.
In this example, two ACOS devices are connected through redundant device
pairs to clients and servers. Two VLANs are used, 210 and 220. Each
ACOS device has trunk interfaces in both VLANs:
VLAN 210 contains the following trunks:

• Trunk 1 (Ethernet ports 6 and 10) connected to clients
• Trunk 3 (Ethernet ports 5 and 9) connected to servers
Similarly, VLAN 220 contains the following trunks:

• Trunk 2 (Ethernet ports 8 and 12) connected to clients
• Trunk 4 (Ethernet ports 7 and 11) connected to servers

LACP Passthrough
On each ACOS device, the following LACP tunnels are configured:
• Ethernet ports 5 and 6
Link monitoring (new in ACOS Release 2.6.1-GR1-P3-SP3) is configured

to automatically disable all interfaces on a trunk if any of its ports goes
down.
Without LACP passthrough, if trunk 1 goes down, existing client connec-

tions on that trunk stop working. This occurs even if the client traffic begins
to arrive on trunk 2. With LACP configured as described above, the ACOS
device continues service for the client-server sessions without interruption.
Notes
• The current release supports LACP passthrough only on untagged
VLAN ports. Tagged ports are not supported in this release.
• Each LACP passthrough tunnel can contain two Ethernet data ports.
These ports must be in the same VLAN and use the same Virtual Ether-
net (VE) interface. On of the ports must be connected to the clients. The
other port must be connected to the servers.
• This feature requires use of the link monitoring and automatic disable
feature to bring all of a trunk’s ports down if any of its ports goes down.
(See “Link Monitoring with Automated Link Disable or Session Clear”
on page 135.)
• Similarly, the nexthop devices that connect the ACOS device to the cli-
ents and servers must be configured to bring a trunk down when any of
its member ports goes down.
• The current release has been tested only with virtual port type HTTP.

LACP Passthrough
Configuration
To configure LACP passthrough:
1. Configure LACP trunk parameters. (See the System Configuration and
Administration Guide.)
2. Configure link monitoring so that the ACOS device brings all trunk
interfaces down when any of its interfaces goes down. (See “Link Mon-
itoring with Automated Link Disable or Session Clear” on page 135.)
3. Configure the LACP tunnels.
USING THE GUI
The current release does not support this feature in the GUI.
USING THE CLI
To configure an LACP tunnel, use the following command at the global

[no] lacp-passthrough ethernet client-if ethernet
server-if
The client-if is the Ethernet data port connected to clients. The server-if is
the Ethernet data port connected to servers.
Displaying LACP Information

To display LACP information, use the following commands:
show lacp sys-id

This command displays the ACOS device’s LACP system ID. The LACP
system ID consists of the LACP system priority and the system MAC
address.
On ACOS devices, the system MAC address is the lowest numbered MAC
address on the device.
show lacp counter [lacp-trunk-id]

This command displays statistics.

show lacp trunk
[
admin-key-list-details |
detail |
summary |
lacp-trunk-id
]
This command shows configuration and status information for LACP.
Clearing LACP Statistics

To clear LACP statistics counters, use one of the following commands at the
Privileged EXEC level of the CLI:
clear lacp counters
clear lacp [lacp-trunk-id] counters
This example enables LACP on physical Ethernet data ports 1-3 and 6.
The following commands configure LACP parameters on the ports:

ACOS(config)#interface ethernet 1
ACOS(config-if:ethernet1)#lacp trunk 5 admin-key 10001 mode active
ACOS(config-if:ethernet1)#lacp timeout long
ACOS(config-if:ethernet1)#interface ethernet 2
ACOS(config-if:ethernet2)#lacp trunk 5 admin-key 10001 mode active
ACOS(config-if:ethernet3)#lacp trunk 10 mode active
ACOS(config-if:ethernet3)#lacp timeout short
ACOS(config-if:ethernet6)#lacp trunk 10 mode active
ACOS(config-if:ethernet6)#lacp timeout short
ACOS(config-if:ethernet6)#end

Show Commands
The following command shows the LACP system ID:
ACOS#show lacp sys-id
System 0064,00-1f-a0-01-d4-f0
The following command shows LACP statistics:

ACOS#show lacp counter
Traffic statistics
Port LACPDUs Marker Pckt err
Sent Recv Sent Recv Sent Recv
Aggregator po5 1000000
ethernet 1 81 81 0 0 0 0
ethernet 2 81 81 0 0 0 0
ethernet 6 233767 233765 0 0 0 0
In this example, LACP has dynamically created two trunks, 5 and 10.
Trunk 5 contains ports 1 and 2. Trunk 10 contains port 6.
The following command shows details about the LACP admin keys:
ACOS#show lacp trunk admin-key-list-details
% Admin Key: 1
bandwidth: 0
mtu: 1500
duplex mode: 0
hardware type: 2
type: 0
additional parameter: 10001
ref count: 2
% Admin Key: 2
bandwidth: 1
mtu: 1500
duplex mode: 0
hardware type: 2
type: 0
ref count: 451
% Admin Key: 3
bandwidth: 1
mtu: 16436
duplex mode: 0

hardware type: 1
type: 0
ref count: 14
% Admin Key: 4
bandwidth: 1
mtu: 1500
duplex mode: 0
hardware type: 2
type: 0
ref count: 6
The following command shows summary trunk information:

ACOS#show lacp trunk summary
Admin Key: 0005 - Oper Key 0005
Link: ethernet 1 (3) sync: 1
The following command shows information for trunk 5:

ACOS#show lacp trunk 5
Aggregator po5 1000000 Admin Key: 0005 - Oper Key 0005 Partner LAG: 0x0064,00-
1f-a0-01-dc-60 Partner Oper Key 0005
The following command shows detailed information for all LACP trunks:
ACOS#show lacp trunk detail
Mac address: 00:1f:a0:02:1e:48
Receive link count: 1 - Transmit link count: 0
Individual: 0 - Ready: 1
Partner LAG- 0x0064,00-1f-a0-01-dc-60

Mac address: 00:1f:a0:02:1e:4d
Receive link count: 1 - Transmit link count: 0
Individual: 0 - Ready: 1
Partner LAG- 0x8000,00-1f-a0-10-19-66
The following command shows LACP information for Ethernet data port 1:
ACOS#show lacp trunk port ethernet 1
LACP link info: ethernet 1 - 3
LAG ID: 0x8000,00-1f-a0-02-1e-48
Partner oper LAG ID: 0x8000,00-1f-a0-01-dc-60
Actor priority: 0x8000 (32768)
Admin key: 0x0005 (5) Oper key: 0x0005 (5)
Physical admin key:(1)
Receive machine state : Current
Periodic Transmission machine state : Slow periodic
Mux machine state : Collecting/Distributing
Oper state: ACT:1 TIM:0 AGG:1 SYN:1 COL:1 DIS:1 DEF:0 EXP:0
Partner oper state: ACT:1 TIM:0 AGG:1 SYN:1 COL:1 DIS:1 DEF:0 EXP:0
Partner link info: admin port 0
Partner oper port: 3
Partner admin LAG ID: 0x0000-00:00:00:00:0000
Admin state: ACT:1 TIM:0 AGG:1 SYN:0 COL:0 DIS:0 DEF:1 EXP:0
Partner admin state: ACT:0 TIM:0 AGG:1 SYN:0 COL:0 DIS:0 DEF:1 EXP:0
Partner system priority - admin:0x8000 - oper:0x0064
Aggregator ID: 1000000
Example 2 with LACP Passthrough

Here is the trunk interface configuration:
trunk 1
ethernet 6 ethernet 10
!
trunk 2
!
trunk 3
!
trunk 4

!
vlan 210
untagged ethernet 5 to 6 ethernet 9 to 10
router-interface ve 210
!
vlan 220
untagged ethernet 7 to 8 ethernet 11 to 12
Here is the link monitoring configuration:

slb template monitor 1
monitor-or
monitor link-down eth 6 sequence 1
action link-disable eth 6 sequence 1
!
slb template monitor 2
monitor-or
!
Monitor template 1 monitors for link-down events on Ethernet data inter-

faces 5, 6, 9, and 10 (the members of VLAN 210). The sequence numbers
specify the order in which to check each interface. If any of the monitored
events is detected, all the actions are performed, in the specified sequence.
In this case, if the link goes down on port 7, 8, 11, or 12, the ACOS device
disables the links on all those ports.

Monitor template 2 monitors for link-down events on Ethernet data inter-
faces 7, 8, 11, and 12 (the members of VLAN 220). The monitored events
and actions are the same as those for VLAN 210.
The following commands activate the monitor templates:

system template monitor 1
system template monitor 2
!
Here is the configuration for the LACP passthrough tunnels:

lacp-passthrough ethernet 5 ethernet 6

Link Monitoring with Automated Link Disable

or Session Clear
The ACOS device supports link monitoring with automated link disable or
session clear.
This feature monitors the link state of Ethernet data interfaces. You can
monitor Ethernet data interfaces for the following types of events:
• Link up
• Link down
The feature monitors the link state on a set of Ethernet data interfaces. If the
monitored event is detected, the ACOS device applies the specified action
to another set of interfaces.
This feature is especially useful in cases where you want to disable both
ACOS interfaces used by traffic flows through the ACOS device, if the link
on either interface goes down. (For an example, see “LACP Passthrough”
on page 126.)
Note: You can configure the feature for individual Ethernet data ports. Configu-
ration of the feature for logical interfaces such as Virtual Ethernet (VE)
interfaces is not supported.
Link Monitoring Actions

You can configure the ACOS device to take one of the following actions
when the specified event type (link up or link down) is detected on a moni-
tored Ethernet data interface:
• Clear sessions
• Disable the link on one or more other interfaces
• Enable the link on one or more other interfaces
The clear session option removes sessions from the session table. You can
configure the feature either to clear data sessions only, or to clear sessions of
all types.

Sequence Numbers
Each monitor template can contain the following types of entries:
• Monitoring entries – A monitoring entry monitors for a specific event
type (link up or link down) on a specific Ethernet data interface.
• Action entries – An action entry specifies the action to take when moni-
tored events are detected.
When you configure an entry of either type, you must specify a sequence
number, 1-16. The sequence numbers assigned to monitoring entries specify
the order in which to check the monitored ports for the specified event type.
Likewise, the sequence number assigned to action entries specify the order
in which to apply the actions.
The sequence number can be important in cases such as the following:

• The order in which link state changes take place can affect whether traf-
fic loops occur.
• The template contains action entries that clear sessions and that disable
or enable links. In this case, the sequence number controls whether the
sessions are cleared before or after the link states are changed. Nor-
mally, it is recommended to clear the sessions first, before changing the
link states.
The monitor with the lowest sequence number is performed first, then the
monitor with the next lowest sequence number is performed, and so on. For
example, monitor 1 is performed first, monitor 2 is performed second, and
so on. Likewise, if the monitored events are detected, action 1 is performed
first, then action 2, and so on.
OR and AND
Each monitor template uses one of the following logical operators:
• AND – The actions are performed only if all the monitored events are
detected. (This is the default).
• OR – The actions are performed if any of the monitored events is
detected.
The logical operator applies only to monitor entries, not to action entries.
For example, if the logical operator is OR, and at least one of the monitored
events occurs, all the actions configured in the template are applied.

You can configure the entries in any order. In the configuration, the entries
of each type are ordered based on sequence number.
Configuration
To configure link monitoring with automated link disable or session clear:
1. Configure a monitoring template. Within the template, specify the fol-
lowing parameters:
• Links (Ethernet data ports) to monitor
• Actions to perform on other links, if the monitored event is
detected:
• Clear sessions
• Disable links
• Enable links
• (Optional) Set the comparison operator for the monitoring entries:
• AND – The actions are performed only if all the monitored
events are detected.
• OR – The actions are performed if any of the monitored events is
detected.
2. Active the monitoring template.
You can configure and activate up to 16 monitor templates. A monitor tem-

plate does not take effect until you activate it.
Using the CLI
Configure the Monitor Template

To configure a monitor template, use the following commands:
[no] slb template monitor link-monitor-id
The link-monitor-id can be 1-16.
This command creates the link monitor and changes the CLI to the configu-
ration level for it, where the following commands are available.

Monitor Configuration
Use the following command to configure a monitor entry:
[no] monitor
{
link-down eth portnum [eth portnum ...]
sequence num |
link-up eth portnum [eth portnum ...]
sequence num
}
This command specifies the links (Ethernet data ports) to monitor, and the
event type for which to monitor. The sequence number can be 1-16.
Note: The ports within a given monitor entry are always ANDed. If you specify
more than one port (eth portnum option) in the same monitor entry, the
specified event must occur on all the ports in the entry. For example, if
you specify link-down eth 9 eth 11, the link must go down on ports 9 and
11, for the link-state changes to count as a monitored event.
Action Configuration
Use the following command to configure an action entry:
[no] action
{
clear sessions [all] sequence num |
link-disable eth portnum sequence num |
link-enable eth portnum sequence num
}
This command specifies the action to perform when a monitored event is

detected. (See “Link Monitoring Actions” on page 135.)
Logical Operator Configuration

Use the following command to specify the logical operator to use:
[no] {monitor-and monitor-or}
(See “OR and AND” on page 136.)
Activate the Monitor Template

To activate a monitor template, use the following command at the global
configuration level of the CLI
[no] system template monitor link-monitor-id

Sample template—CLI Example

The following commands configure monitor template 1:
ACOS(config)#slb template monitor 1
ACOS(config-monitor)#monitor link-down eth 5 sequence 1
ACOS(config-monitor)#action clear sessions sequence 1
ACOS(config-monitor)#action link-disable eth 5 sequence 2
ACOS(config-monitor)#exit
The following commands activates the template, to place it into effect:

ACOS(config)#system template monitor 1
Based on this configuration, when a link-down event is detected for Ether-

net port 5 OR 6 OR 9 OR 10, sessions are cleared first. Then the remaining
links are disabled, in the following sequence: 5 AND 6 AND 9 AND 10.
Note: The clear session command clears only data sessions. To clear all ses-
sions, use clear sessions all.
(For another example, see “LACP Passthrough” on page 126.)


Link Layer Discovery Protocol
The Link Layer Discovery Protocol (LLDP) enables network devices to

advertise their identity, capabilities, and neighbors on the network. This fea-
ture is based on the IEEE 802.1AB standard.
Overview
LLDP allows A10 devices to discover directly-connected LAN neighbors
and allows these neighbors to discover the A10 devices. Configure LLDP
only in the shared partition.
Use the LLDP protocol to assist in the following ways:

• To discover remote networks.
• To facilitate port association.
• To help identify which port a switch or a host is connected to.
• To help design and troubleshoot network topologies.
Since the LLDP protocol can transmit or receive information on system

capabilities, but cannot request specific information from an LLDP agent or
acknowledge receipt of information, it is called a “one-way protocol.”
Note: This feature does not support aXAPI.
The Link Layer Discovery Protocol Data Unit (LLDPDU) contains several
elements of variable lengths that comprise the LLCP frame. They carry
information on the type, length, and value fields (TLVs), where type identi-
fies the kind of information that is transmitted, length contains the string of
octets, and value is the actual content that is being transmitted. The manda-
tory information that is transmitted identifies the TLV for the chassis ID, the
port ID, the Time to Live, and the end of the LLDP data packet. It can also
contain zero or more optional TLVs. For the duration of an operational port,
the chassis ID and the port ID information will remain the same.
A Time to Live TLV or a non-zero TLV informs the receiving LLDP agent
to discard the LLDP data packet after the indicated time expires. A zero
TLV directs the receiving LLDP agent to discard the LLDP packet immedi-
ately. As the name suggests, the End of LLDP data packet indicates that
completion of the LLDP packet.

Configuration
This section describes how to configure LLDP.
USING THE GUI
This feature is not supported via the GUI.
USING THE CLI
Use the following configuration steps to deploy the feature:

1. To enable the LLDP feature via the CLI, enable the feature from the
global switch:
[no] lldp enable [rx] [tx]
2. To enable LLDP on the interface, issue the following command:

interface interface-number
[no] lldp enable rx tx
Note: If you do not enable LLDP from the global level, but only enable it from
the interface level, LLDP will not work as designed.
LLDP is based on the following standard MIB called “LLDP-V2-MIB.” For

more information, refer to the following URLs:
• http://www.mibdepot.com/cgi-bin/getmib3.cgi?win=mib_a&i=1&n=IP-
MIB&r=vmware&f=LLDP-V2-MIB.mib&v=v2&t=def
• http://www.ieee802.org/1/files/public/MIBs/LLDP-V2-MIB-
200906080000Z.txt

LLDP Configuration Example

1. To enable the LLDP feature via the CLI, enable the feature from the
global level:
ACOS(config)#lldp enable rx tx
2. To enable LLDB on the interface, issue the following command. In the

following example, specify ethernet 2 as the interface number:
ACOS(config-if:ethernet2)#lldp enable rx tx
The following example shows your LLDP configuration:
ACOS(config)#show run | inc lldp

lldp enable rx tx
lldp notification interval 20
lldp tx interval 10
lldp tx fast-count 2
lldp tx fast-interval 2
The following example shows your LLDP interface configuration:

ACOS(config-if:ethernet1)#show run int eth 1
interface ethernet 1
ip address 7.1.1.169 255.255.255.0
lldp enable rx tx
lldp notification enable


Bidirectional Forwarding Detection
Bidirectional Forwarding Detection (BFD) provides very fast failure detec-

tion for routing protocols. When BFD is enabled, the ACOS device periodi-
cally sends BFD control packets to the neighboring devices that are also
running BFD. If a neighbor stops sending BFD control packets, the ACOS
device quickly brings down the BFD session(s) with the neighbor, and
recalculates paths for routes affected by the down neighbor.
BFD provides a faster failure detection mechanism than the timeout values
used by routing protocols. Routing protocol timers are multiple seconds
long, whereas BFD provides sub-second failover.
The A10 implementation of BFD is based on the following RFCs:

• RFC 5880, Bidirectional Forwarding Detection (BFD)
• RFC 5881, Bidirectional Forwarding Detection (BFD) for IPv4 and

IPv6 (Single Hop)
• RFC 5882, Generic Application of Bidirectional Forwarding Detection
(BFD)
• RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop
Paths
Support in this Release

The current release has the following BFD support:
• Basic BFD protocol (packet processing, state machine, and so on)
• BGP client support
• Multihop
• BFD Asynchronous mode
• OSPFv2/v3 client support
• Static route support
• IS-IS client support
• BFD Demand mode
• Full Echo function support
• Authentication

BFD Parameters
BFD is disabled by default. You can enable it on a global basis.
BFD Echo
BFD echo enables a device to test data path to the neighbor and back. When
a device generates a BFD echo packet, the packet uses the routing link to the
neighbor device to reach the device. The neighbor device is expected to
send the packet back over the same link.
BFD Timers
You can configure BFD timers at the following configuration levels:

• Global
• Interface
If you configure the timers on an individual interface, the interface’s set-

tings are used instead of the global settings. Likewise, if the BFD timers are
not set on an interface, that interface uses the global settings. For BGP loop-
back neighbors, BFD always uses the global timer.
The DesiredMinTXInterval, RequiredMinRxInterval and DetectMult timer

fields can be configured at the interface and the global configuration level.
However, the actual timer will vary depending on the Finite State Machine
(FSM) state, through negotiation, and whether or not echo has been enabled.
BGP Support
If you run BGP on the ACOS device, you can enable BFD-based fallover
for individual BGP neighbors.

Static Route Support

A static route flap can occur when you enable BFD in global mode or when
you configure a static BFD session.
In the following example, you will see that the static routes experience a
flap when BFD is enabled. The fields to note are flagged in bold:
ACOS(config)#show ipv6 route
IPv6 Routing Table
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
i - IS-IS, B - BGP
Timers: Uptime
C 3ffe:100::/64 via ::, ve 10, 00:01:28

C 3ffe:1111::/64 via ::, loopback 1, 00:01:30
S 3ffe:2222::/64 [1/0] via 3ffe:100::20, ve 10, 00:00:25 <===value before flap
timer
ACOS(config)#bfd enable <===enable BFD
ACOS(config)#show ipv6 route
IPv6 Routing Table
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
i - IS-IS, B - BGP
Timers: Uptime
C 3ffe:100::/64 via ::, ve 10, 00:01:32

S 3ffe:2222::/64 [1/0] via 3ffe:100::20, ve 10, 00:00:01 <==value after flap
ACOS(config)#
USING THE GUI
The current release does not support BFD configuration using the GUI.
USING THE CLI
To enable BFD, use the following command at the global configuration

level of the CLI:
[no] bfd enable
To enable BFD echo, use the following command at the global configura-
tion level of the CLI:
[no] bfd echo

To configure BFD timers, use the following commands. These commands

are available at the global configuration level and at the configuration level
for individual interfaces.
[no] bfd interval ms min-rx ms multiplier num
The interval value can be 48-1000 ms, and is 800 ms by default. The min-
rx value can be 48-1000 ms, and is 800 ms by default. The multiplier value
can be 3-50 and is 4 by default.
Configuring BFD Parameters for BGP

To enable BFD-based fallover for a BGP neighbor, use the following com-
mand at the BGP configuration level:
[no] neighbor ipaddr fall-over bfd [multihop]
To display BFD information for BGP neighbors, use the following com-
mand:
show ip bgp neighbor
Displaying BFD Information

To display summarized BFD neighbor information, use the following com-
mand:
show bfd neighbors
To display detailed BFD neighbor information, use the following command:
show bfd neighbors detail
To display BFD statistics, use the following command:

show bfd statistics
To display BFD statistics, use the following command:

show bfd statistics
To clear BFD statistics, use the following command:

clear bfd statistics
Disable BFD
To disable BFD, enter the following command in global configuration

mode:
ACOS(config)#no bfd enable
Enter the command to stop processing all BFD packets.

Configure BFD with OSPF (for IPv4)

To enable BFD with OSPF on an interface, enter one of the following sets of
commands:
To enable BFD on an individual interface:
ACOS(config)# interface ethernet 1
ACOS(config-if)# ip address 20.0.0.1 255.255.255.0
ACOS(config-if)# ip ospf bfd
• To enable BFD on a virtual interface:

ACOS(config)# interface ve 100
ACOS(config-if)# ip ospf bfd
• To enable BFD on a trunk:

ACOS(config-if)#ip ospf bfd
To enable BFD for all OSPF-enabled interfaces, enter the following com-
mands:
ACOS(config)#router ospf 1
ACOS(config-router)# bfd all-interfaces
To selectively disable BFD per interface, enter the following command:

ACOS(config)#ip ospf bfd disable
To configure a multihop neighbor over a virtual-link, enter the following

command:
ACOS(config-router)# area 1 virtual-link 40.0.0.1
fall-over bfd
Sample Configuration
Your running configuration will display your current BFD with OSPF con-
figuration:
!
ipv6 router ospf area 0 tag 1
ip address 20.0.0.1 255.255.255.0
ip ospf bfd
!
ip address 30.0.0.1 255.255.255.0

!
!
router ospf 1
bfd all-interfaces
network 20.0.0.0/24 area 0
network 30.0.0.0/24 area 0
area 1 virtual-link 40.0.0.1 fall-over bfd
!
!
bfd enable
!
Configure BFD with OSPF (for IPv6)

To enable BFD with OSPF for IPv6 support on an interface, enter one of the
following sets of commands:
To enable BFD on an individual interface:
ACOS(config)# interface ethernet 1
ACOS(config-if)#ipv6 address 2001::1/64
ACOS(config-if)#ipv6 router ospf area 0 tag 1
ACOS(config-if)#ipv6 ospf bfd

ACOS(config-if)# ipv6 ospf bfd

ACOS(config-if)#ipv6 ospf bfd
To enable BFD for all OSPFv3-enabled interfaces, enter the following com-
mands:
ACOS(config)#router ipv6 ospf 1
ACOS(config-router)#bfd all-interfaces

ACOS(config-if)#ipv6 ospf bfd disable

To configure a multihop neighbor over a virtual-link, enter the following

command:
ACOS(config-router)# area 1 virtual-link 2.2.2.2
fall-over bfd
Your running configuration will display your current BFD with OSPF for
IPv6 configuration:
!
ipv6 address 2001::1/64
ipv6 ospf bfd
!
ipv6 address 3001::1/64
!
!
router ipv6 ospf 1
router-id 1.1.1.1
bfd all-interfaces
area 1 virtual-link 2.2.2.2 fall-over bfd
!
!
bfd enable
!
Configure BFD with IS-IS (for IPv4)

To enable BFD with ISIS on an interface, enter one of the following sets of
commands:
• To enable BFD on an individual interface:
ACOS(config-if)#ip address 20.0.0.1 255.255.255.0
ACOS(config-if)#ip router isis
ACOS(config-if)#isis bfd

ACOS(config)#interface ve 100


To enable BFD for all IS-IS-enabled interfaces, enter the following com-
mands:
ACOS(config)#router isis
ACOS(config-router)#net 49.0001.0000.0000.0001.00

ACOS(config-if)#isis bfd disable
Your running configuration will display your current BFD with ISIS config-
uration:
!
ip address 20.0.0.1 255.255.255.0
ip router isis
isis bfd
!
ip address 30.0.0.1 255.255.255.0
ip router isis
isis bfd
!
!
router isis
bfd all-interfaces
net 49.0001.0000.0000.0001.00
!
!
bfd enable
!

Configure BFD with IS-IS (for IPv6)

To enable BFD with ISIS for IPv6 support on an interface, enter one of the
following sets of commands:
• To enable BFD on an individual interface:
ACOS(config-if)# isis bfd

ACOS(config-if)#ipv6 address 2ffe:123::1/64
ACOS(config-if)#ipv6 router isis

To enable BFD for all IS-IS-enabled interfaces, enter the following com-
mands:
ACOS(config)#router isis
ACOS(config-router)#net 49.0001.0000.0000.0002.00

ACOS(config-if)#isis bfd disable
Your running configuration will display your current BFD with ISIS (for
IPv6 support) configuration:
!
interface ve 100
ipv6 address 2ffe:123::1/64
ipv6 router isis
isis bfd
!
router isis
bfd all-interfaces
net 49.0001.0000.0000.0002.00
!
bfd enable

Configure BFD with BGP

When BFD is configured with BGP, it is configured on a per neighbor basis.
This is different from the OSPF or ISIS configuration with BFD. Use the
following commands to configure BFD with BGP:
ACOS(config)# router bgp 1
ACOS(config-router)# neighbor 1.2.3.4 fall-over bfd
To configure a multihop BFD neighbor, use the following command:

ACOS(config-router)# neighbor 1.2.3.4 fall-over bfd
multihop
Your running configuration will display your current BFD with BGP con-
figuration:
!
router bgp 1
neighbor 1.2.3.4 remote-as 2
neighbor 1.2.3.4 fall-over bfd multihop
!
!
bfd enable
!
Configuring Static BFD

IPv4 Static BFD (Global)
From the global configuration mode, use the following command to add a
static BFD entry for the specified IPv4 nexthop:
ACOS(config)# ip route static bfd 20.0.0.1 20.0.0.2
In the above command, the first parameter is the IPv4 address of the local
interface. You can only use the IP addresses for interfaces to setup the BFD
session. The second parameter is the IPv4 address of the remote interface
that serves as the gateway for the static route.

IPv6 Static BFD (Global)
static BFD entry for the specified IPv6 nexthop:
ACOS(config)# ipv6 route static bfd 2001::1 2001::2
In the above command, the first parameter is the IPv6 address of the local
interface. You can only use the IP addresses for interfaces to setup the BFD
session. The second parameter is the IPv6 address of the remote interface
that serves as the gateway for the static route.
IPv6 Static BFD (Link-Local)
static BFD entry for the specified link-local IPv6 nexthop:
ACOS(config)# ipv6 route static bfd ve 100 fe80::1
In the above command, the first parameter is the local interface name
(Ethernet, VE, or a specified trunk), and the second parameter is the remote
link-local IPv6 address that serves as the gateway.
Configuration of BFD Intervals

Global Interval Configuration
From the global configuration mode, use the following command to modify
the global interval timer values:
ACOS(config)# bfd interval 500 min-rx 500 multi-
plier 4
This command will help configure the interval for any one of the following
three parameters and will be applied to all BFD sessions:
• DesiredMinTxInterval
• RequiredMinRxInterval
• Multiplier

Interface Interval Configuration
From the interface configuration mode, use the following command to mod-
ify the interface interval timer values:
ACOS(config-if)# bfd interval 500 min-rx 500 multi-
plier 4
Note: For a BFD session for BGP using a loopback address, for an OSPFv2 vir-
tual link, and for an OSPFv3 virtual link, the ACOS device will always
use the global timer configuration, immaterial of the timer that is config-
ured at the interface level.
Authentication
Authentication Per interface
To configure authentication per interface, from the interface configuration

mode, apply one of the following authentication schemes to OSPF,
OSPFv3, IS-IS, or static BFD neighbors.
ACOS(config-if)# bfd authentication 1 md5
password-string
You may choose an authentication method from the following available

choices:
• Simple password
• Keyed MD5
• Meticulous Keyed MD5
• Keyed SHA1
• Meticulous Keyed SHA1
Authentication Per Neighbor (for BGP only)
The following command is configured under the BGP (router bgp) con-
figuration mode:
ACOS(config-router)# neighbor 1.2.3.4 fall-over bfd authentication 1 md5
password-string

Enable Echo and Demand function

Enable the Echo Function
From the global configuration mode, enable the BFD echo:

ACOS(config)# bfd echo
Enable the Echo Function Per Interface
After you configure the global BFD echo, from the interface configuration
mode, you can enable BFD echo on a per interface basis using the following
command:
ACOS(config-if)# bfd echo
Enable Demand Mode
From the interface configuration mode, you can enable the demand mode to
work in conjunction with the echo function using the following command:
ACOS(config-if)# bfd echo demand
When demand mode is enabled, after a BFD session is established, a system

will be able to verify connectivity with another system at will instead of
routinely. Instead of constantly receiving BFD control packets, the system
will request that the other system stop sending BFD Control packets. To
verify connectivity again, the system will explicitly send a short sequence of
BFD Control packets to the other system and receive a response. Demand
mode can be configured to work either independently in each direction, or
bidirectionally at the same time.
Asynchronous Mode
The Asynchronous mode is the default mode of operation for BFD. In this
mode, systems establish connectivity and know of each other’s existence by
periodically exchanging BFD Control packets. A session between two con-
nected systems is only declared down after several packets in a row are not
received by the other system. BFD will operate in this mode if you do not
configure or enable echo or demand.

Viewing BFD Status

BFD Summary Output
To check the BFD neighbor status, from the EXEC mode, execute the show
bdf neighbors command:
ACOS# show bfd neighbors
Our Address Neighbor Address State Holddown txint mult diag
219.0.0.1 219.0.0.2 Up 150 50 3 3/0
219.0.1.1 219.0.1.2 Up 150 50 3 3/0
219.0.2.1 219.0.2.2 Up 150 50 3 0/0
219.0.3.1 219.0.3.2 Up 150 50 3 0/0
219.0.4.1 219.0.4.2 Up 150 50 3 3/0
219.0.5.1 219.0.5.2 Up 150 50 3 3/0
219.0.6.1 219.0.6.2 Up 150 50 3 0/0
219.0.7.1 219.0.7.2 Up 150 50 3 3/0
Table 4 describes the fields in the command output.
TABLE 4 show bfd neighbors fields

Field Description
Our Address Interface associated with the BFD session.
Neighbor Neighbor interface associated with the BFD session.
Address
State Shows the local state of the session.
Holdtime Maximum amount of time the ACOS device waits for a BFD
control packet from the neighbor.
txint Configured interval at which the ACOS device sends BFD
control packets to the neighbor.
mult Maximum number of consecutive times the ACOS device
will wait for a BFD control packet from the neighbor.
diag Diagnostic codes for the local and remote ends of the BFD
session. For information, contact A10 Networks.

BFD Detailed Output
To check the BFD neighbor detailed status, from the EXEC mode, execute
the show BDF neighbors detail command:
ACOS# show bfd neighbors detail
Our Address 219.0.0.1
Neighbor Address 219.0.0.2
Clients OSPFv2, IS-IS
Singlehop, Echo disabled, Demand disabled, UDP source port 53214
Asynchronous mode, Authentication None
CPU ID 2, Interface index 93
Local State Up, Remote State Up, 2h:29m:45s up
Local discriminator 0x00000fdf, Remote discriminator 0x0000006f
Config DesiredMinTxInterval 50 milliseconds, RequiredMinRxInterval 50 milli-
seconds
Local DesiredMinTxInterval 50 milliseconds, RequiredMinRxInterval 50 millisec-
onds
Remote DesiredMinTxInterval 50 milliseconds, RequiredMinRxInterval 50 milli-
seconds
Local Multiplier 3, Remote Multiplier 3
Hold Down Time 150 milliseconds, Transmit Interval 50 milliseconds
Local Diagnostic: Neighbor Signalled Session Down(3)
Remote Diagnostic: No Diagnostic(0)
Last sent echo sequence number 0x00000000
Control Packet sent 215226, received 215195
Echo Packet sent 0, received 0
TABLE 5 show bfd neighbors detail fields

Field Description
Our Address Interface associated with the BFD session.
Neighbor Neighbor interface associated with the BFD session.
Address
Clients Protocol that initiates this BFD session. It can be one or more
of the following: Static, OSPFv2, OSPFv3, IS-IS, or BGP.
Singlehop (or BFD session can be either singlehop or multihop.
Multihop)
Echo Indicates whether Echo functionality has been enabled or
disabled.
Demand Indicates whether Demand mode functionality has been
enabled or disabled.
UDP source port UDP source port used for this BFD session.

TABLE 5 show bfd neighbors detail fields (Continued)

Field Description
Asynchronous If configured and running, indicates whether BFD is operat-
mode (or ing in Asynchronous mode or Demand mode.
Demand) mode
Authentication Authentication method. This can be either “None” (if it is not
configured) or one of the following supported authentication
schemes:
• Simple password
• Keyed MD5
• Meticulous Keyed MD5
• Keyed SHA1
• Meticulous Keyed SHA1
CPU ID Since BFD traffic is distributed across multiple data CPUs,
this CPU ID refers to the one associated with the current
BFD session.
Interface index Interface index associated with the current BFD session.
This index is used mostly for debugging purposes
Local State Shows the local state the session. The state can be one of the
following:
• Init
• Up
• AdminDown
• Down
Remote State Shows the remote state the session. The state can be one of
the following:
• Init
• Up
• AdminDown
• Down
Local discrimi- The local discriminator value that the ACOS device assigns
nator for the current BFD session.
Remote discrimi- The remote discriminator value that the neighboring router
nator claims.
Config The configured timer values.
Local The configured timer values sent in the last BFD control
packet. This value is determined based on BFD package
exchange and negotiation.
Remote The timer values received in the last BFD control packet
from the BFD neighbor.
Local Multiplier The local multiplier sent in the last BFD packet.
Remote Multi- The remote multiplier received in the last BFD packet from
plier the neighbor.

TABLE 5 show bfd neighbors detail fields (Continued)

Field Description
Hold Down Time The expiration time after which the BFD session will be
brought down. This value is determined with the negotiated
interval value and the remote multiplier value.
Transmit Interval The periodic interval to send BFD control packets.
Local Diagnos- The diagnostic value sent in the last BFD control packet.
tic:
Remote Diag- The diagnostic value received in the last BFD control packet
nostic: from the neighbor.
Last sent echo A10 Network’s proprietary sequence number sent in the last
sequence number echo packet.
Control Packet Statistics of control packets for this BFD session.
sent....received
Echo Packet Statistics of echo packets received for this BFD session.
sent...received
Viewing BFD Statistics
The following command shows BFD statistics:

ACOS(config)# show bfd statistics
IP Checksum error 0
UDP Checksum error 0
No session found with your_discriminator 39958
Multihop config mismatch 0
BFD Version mismatch 0
BFD Packet length field is too small 0
BFD Packet data is short 0
BFD Packet DetectMult is invalid 0
BFD Packet Multipoint is invalid 0
BFD Packet my_discriminator is invalid 0
BFD Packet TTL/Hop Limit is invalid 0
BFD Packet auth length is invalid 0
BFD Packet auth mismatch 0
BFD Packet auth type mismatch 0
BFD Packet auth key ID mismatch 0
BFD Packet auth key mismatch 103
BFD Packet auth seq# invalid 0
BFD Packet auth failed 0
BFD local state is AdminDown 2
BFD Destination unreachable 1
BFD Other error 0

TABLE 6 show bfd statistics fields

Field Description
IP Checksum Number of BFD packets that had an invalid IP checksum.
error
UDP Checksum Number of BFD packets that had an invalid UDP checksum.
error
No session found Number of BFD packets whose Your Discriminator value
with your_ did not match a My Discriminator value on the ACOS
discriminator device.
Multihop config A multihop configuration mismatch occurs when an ACOS
mismatch device receives a BFD packet with a source or destination
that matches an existing BFD session. It can also be caused
in two other scenarios:
• Local is configured as singlehop, but the packet is
received on the UDP port for multihop.
• Local is configured as multihop, but packet is received on
the UDP port for singlehop.
BFD Version Number of BFD packets with a different BFD version than
mismatch the one in use by the ACOS device.
BFD Packet Number of BFD packets whose Length field value was
length field is too shorter than the minimum BFD packet length (24 bytes with-
small out authentication or 26 bytes with authentication).
BFD Packet data The packet payload size is smaller than the BFD length
is short value.
BFD Packet The value of the received DetectMult is “0”.
DetectMult is
invalid
BFD Packet The value of the received multipoint flag is set to “1”.
Multipoint is
invalid
BFD Packet my_ Number of BFD packets whose My Discriminator value was
discriminator is invalid.
invalid
BFD Packet In a singlehop BFD session, the IP time-to-live or IPv6 hop
TTL/Hop Limit limit value must be 255. If a value other than 255 is detected,
is invalid this field is incremented.
BFD Packet auth The BFD length without the BFD packet header does not
length is invalid match the expected authentication length byte value. The
number of BFD control packets have wrong authentication
lengths in bytes
BFD Packet auth Number of BFD packets carrying an authentication type that
type mismatch does not match the BFD authentication type configured on
the ACOS device.
BFD Packet auth This field is incremented when the key ID in the authentica-
key ID mismatch tion header does not match the one configured on the ACOS
device.

TABLE 6 show bfd statistics fields (Continued)

Field Description
BFD Packet auth This field is incremented when the received authentication
key mismatch key does not match the one configured on the ACOS device.
BFD Packet auth This field is incremented when the received authentication
seq# invalid sequence number is not equal to or greater than the sequence
number received previously.
BFD Packet auth Number of BFD packets with an incorrect authentication
failed value.
BFD local state Number of BFD packets received while the BFD session was
is AdminDown administratively down.
BFD Number of times the destination IP address for a BFD neigh-
Destination bor was unreachable while the ACOS device was attempting
unreachable to transmit a BFD packet to the neighbor.
BFD Other error Number of BFD errors not counted in any of the fields
above.


Overview
Gateway Health Monitoring
This chapter describes gateway health monitoring and how to configure it.
For information about health monitoring of servers in Server Load Balanc-

ing (SLB) configurations, see the “Health Monitoring” chapter in the
Application Delivery and Server Load Balancing Guide.
Notes
• Gateway health monitoring is useful in cases where there is more than
one route to a destination. In this case, the ACOS device can discard the
routes that use unresponsive gateways. If there is only one gateway, this
feature is not useful.
• Gateway health monitoring and SLB server health monitoring are inde-
pendent features. If a gateway fails its health check, a server reached
through the gateway is not immediately marked down. The status of the
server still depends on the result of the SLB server health check.
• If you plan to use gateway health as a failover trigger for High Avail-
ability (HA), a different configuration option is required. See “Gateway-
based Failover” on page 285 (for the older implementation of HA) or
“Dynamic Priority Reduction” on page 365 (for VRRP-A).
Overview
Gateway health monitoring uses ARP to test the availability of nexthop
gateways. When the ACOS device needs to send a packet through a gate-
way, the ACOS device begins sending ARP requests to the gateway.
• If the gateway replies to any ARP request within a configurable timeout,
the ACOS device forwards the packet to the gateway.
• The ARP requests are sent at a configurable interval. The ACOS device
waits for a configurable timeout for a reply to any request. If the gate-
way does not respond to any request before the timeout expires, the
ACOS device selects another gateway and begins the health monitoring
process again.

Overview
The following parameters are used for gateway health monitoring:
• Interval – The interval specifies the amount of time between health
check attempts (ARP requests), and can be 1-180 seconds. The default is
5 seconds.
• Retries – The retries specifies the number of seconds the ACOS device
waits for a response before re-attempting the health check (sending
another ARP request). The maximum value is 3 seconds and is not con-
figurable.
• Timeout – The timeout specifies how long the ACOS device waits for a
reply to any of the ARP requests, and can be 1-60 seconds. The default
is 15 seconds.
Using the default gateway health monitoring settings, a gateway must

respond to a gateway health check within 15 seconds. Figure 24 shows how
a gateway health check times out using the default settings.
Note: It is recommended not to use a timeout value smaller than 3 times the
interval value. This is especially true for short interval values.
FIGURE 24 Gateway Health Check Using Default Settings – Timeout

Configuration
Figure 25 shows an example in which a gateway responds before the time-
out.
FIGURE 25 Gateway Health Check Using Default Settings – Gateway

Responds
Configuration
Gateway health monitoring is disabled by default. To enable it, use either of
the following methods.
USING THE GUI

The current release does not support configuration of this feature using the
GUI.
USING THE CLI
To enable gateway health monitoring, use the following command at the

slb gateway-health-check
[interval seconds [timeout seconds]]
The interval and timeout options are described above.
To display gateway health monitoring statistics, use the following com-

mand:

Configuration
show health gateway
CLI Example
The following command enables gateway health monitoring with the
default settings:
ACOS(config)#slb gateway-health-check
The following command displays gateway health monitoring statistics:

ACOS(config)#show health gateway
Gateway health-check is enabled
Interval=5, Timeout=15
Total health-check sent : 10
Total health-check retry sent : 2
Total health-check timeout : 1

Support for Multiple OSPFv2 and OSPFv3 Processes
Open Shortest Path First (OSPF)
The ACOS device supports the following OSPF versions:

• OSPFv2 for IPv4
• OSPFv3 for IPv6
This chapter provides configuration examples. For detailed CLI syntax

information, see the CLI Reference.
Support for Multiple OSPFv2 and OSPFv3 Processes

The ACOS device supports up to 65535 OSPFv2 processes on a single
ACOS device. Only a single OSPFv2 process can run on a given interface.
Each IPv6 link can run up to 65535 OSPFv3 processes, on the same link.
Each OSPF process is completely independent of the other OSPF processes

on the device. They do not share any information directly. However, you
can configure redistribution of routes between them.
Support for OSPFv2 and OSPFv3 on the Same

Interface or Link
You can configure OSPFv2 and OSPFv3 on the same interface or link.
OSPFv2 configuration commands affect only the IPv4 routing domain,
while OSPFv3 configuration commands affect only the IPv6 routing
domain.
OSPF MIB Support

The following OSPF MIBs are supported:
• RFC 1850 – OSPFv2 Management Information Base
• draft-ietf-ospf-ospfv3-mib-08 – OSPFv3 Management Information Base

OSPF Configuration Example

The configuration excerpts in this example configure OSPFv2 and OSPFv3
on an ACOS device.
Interface Configuration
The following commands configure two physical Ethernet data interfaces.
Each interface is configured with an IPv4 address and an IPv6 address. Each
interface also is added to OSPF area 0 (the backbone area).
The link-state metric (OSPF cost) of Ethernet 2 is set to 30, which is higher
than the default, 10. Based on the cost difference, OSPF routes through
Ethernet 1 will be favored over OSPF route through Ethernet 2, because the
OSPF cost of Ethernet 1 is lower.
ip address 2.2.10.1 255.255.255.0
ipv6 address 5f00:1:2:10::1/64
!
ip address 3.3.3.1 255.255.255.0
ipv6 address 5f00:1:2:20::1/64
ip ospf cost 25
The following commands configure two Virtual Ethernet (VE) interfaces.

On VE 3, an IPv4 address is configured. On VE 4, an IPv4 address and an
IPv6 address are configured.
OSPFv2 authentication is configured on VE 3, and the OSPF cost is set to

20.
On VE 4, the OSPF cost is set to 15.

interface ve 3
ip address 1.1.1.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 abc
ip ospf cost 20
!

interface ve 4
ip address 1.1.60.2 255.255.255.0
ipv6 address 5f00:1:1:60::2/64
ip ospf cost 15
Global OSPF Parameters

The following commands configure global settings for OSPFv2 process 2.
The router ID is set to 2.2.2.2. Subnets 1.1.x.x, 2.2.10.x, and 3.3.3.x are
added to the backbone area. Redistribution is enabled for static routes,
routes to VIPs, IP source NAT addresses, and floating IP addresses (used by
HA). In addition, an extra HA cost is configured, and the SPF timer is
changed.
router ospf 2
ospf router-id 2.2.2.2
ha-standby-extra-cost 25
timers spf exp 500 50000
redistribute static metric 5 metric-type 1
redistribute vip metric 500 metric-type 1
redistribute ip-nat
redistribute floating-ip metric-type 1
network 1.1.0.0 0.0.255.255 area 0
network 2.2.10.0 0.0.0.255 area 0
network 3.3.3.0 0.0.0.255 area 0
The following commands configure global settings for OSPFv3 process 1.

The router ID is set to 3.3.3.3. A stub area is added, redistribution is
enabled, and the SPF timer is changed.
router ipv6 ospf 1
router-id 3.3.3.3
redistribute static metric 5 metric-type 1
redistribute ip-nat
redistribute floating-ip
area 1 stub
timers spf exp 500 50000

Clearing Specific OSPF Neighbors

The OSPF feature provides the option to clear all or specific OSPF neigh-
bors.
You can clear neighbors by specifying various filters:
clear ip ospf [process-id]

{
process |
neighbor
{all | neighbor-id | interface
{interface-ip-address [neighbor-ip-address]}}
}
clear ipv6 ospf [process-tag]

{
process |
neighbor
{all | neighbor-id |
interface-name [neighbor-id]}
}
The options listed in the syntax stand for following:

• process-id—The process-id specifies the IPv4 OSPFv2 pro-
cess to run on the device, and can be 1-65535.
• process-tag—The process-tag specifies the IPv6 OSPFv3 pro-
cess to run on the IPv6 link, and can be 1-65535.
• neighbor-id is the router-id of the OSPF device.
• neighbor-ip-address is the IP address of the interface for the

neighboring device.
• interface-ip-address is the IP address of the interface of the
device on which the OSPF neighbor exists.
Using OSPFv2, the CLI enables you to indicate an interface IP Address of

the ACOS device. Using OSPFv3, the CLI enables you to specify the inter-
face name for a specific neighbor.
Use the following commands to effect changes to clear OSPF neighbor

information. To clear all neighbors, issue the following command:
clear ip ospf [process-id] neighbor all

To clear all neighbors to a specific router:
clear ip ospf [process-id] neighbor neighbor-
router-id
To clear all neighbors on an IPv4 interface:

clear ip ospf [process-id] neighbor interface
interface-ip-address
To clear a neighbor on a specified interface to a specified router:

clear ip ospf [process-id] neighbor interface
interface-ip-address neighbor-router-id
To clear all neighbors:

clear ipv6 ospf [process-tag] neighbor all
To clear all neighbors to a specific router:

clear ipv6 ospf [process-tag] neighbor
neighbor-router-id
To clear all neighbors on a specified interface:

interface-name
To clear all neighbors on a specified interface to a specific router:

interface-name neighbor-router-id
The following command clears all OSPFv2 neighbors:
ACOS(config)#clear ip ospf neighbor all
The following command clears all neighbors to a specific router:

ACOS(config)#clear ip ospf neighbor 192.1.1.1
The following command clears all neighbors on an interface:

ACOS(config)#clear ip ospf neighbor interface 10.1.1.10
The following command clears a neighbor on a specified interface to a spec-

ified router:
ACOS(config)#clear ip ospf neighbor interface 10.1.1.10 192.1.1.10

The following command clears all OSPFv3 neighbors:
ACOS(config)#clear ipv6 ospf 5 neighbor all
The following command clears all neighbors to a specific router:

ACOS(config)#clear ipv6 ospf neighbor 192.1.1.1
The following command clears all OSPFv3 neighbors on a specified

interface:
ACOS(config)#clear ipv6 ospf neighbor ethernet 1
The following command clears all neighbors on a specified interface to a

specific router:
ACOS(config)#clear ipv6 ospf neighbor ethernet 1 192.1.1.1
OSPF Logging
Router logging is disabled by default. You can enable router logging to one
or more of the following destinations:
• CLI terminal (stdout)
• Local logging buffer
• Local file
• External log servers
Note: Log file settings are retained across reboots but debug settings are not.
Note: Enabling debug settings that produce lots of output, or enabling all debug
settings, is not recommend for normal operation.
Configuring Router Logging for OSPF
To configure router logging for OSPF:

1. Enable output options.
2. Set severity level and facility.
3. Enable debug options to generate output.
For additional syntax information, including show and clear commands for
router logging, see the CLI Reference.

1. Enable output options:
To enable output to the terminal, use the following command at the global
router log stdout
To enable output to the local logging buffer, use the following command at
the global configuration level of the CLI:
router log syslog
To enable output to a local file, use the following command at the global
[no] router log file
{
name string |
per-protocol |
rotate num |
size Mbytes
}
To enable output to a remote log server, use the following command at the
logging host ipaddr [ipaddr...]
[port protocol-port]
Up to 10 remote logging servers are supported.
2. Set severity level and facility:

The default severity level for router logging is 7 (debugging). The default
facility is local0.
To change set the severity level for messages output to the terminal, use the
following command at the global configuration level of the CLI:
logging monitor severity-level
The severity-level can be one of the following:

• 0 or emergency
• 1 or alert
• 2 or critical
• 3 or error
• 4 or warning
• 5 or notification

• 6 or information
• 7 or debugging
To change the severity level for messages output to the local logging buffer,
use the following command at the global configuration level of the CLI:
logging buffered severity-level
To change the severity level for messages output to external log servers, use
the following command at the global configuration level of the CLI:
logging syslog severity-level
To change the severity level for messages output to a file, use the following
command at the global configuration level of the CLI:
router log trap severity-level
To change the facility, use the following command at the global configura-
logging facility facility-name
The facility-name can be one of the following:

• local0
• local1
• local2
• local3
• local4
• local5
• local6
• local7
3. Enable debug options to generate output:

To enable debugging for OSPF, use the following commands at the global
configuration level or Privileged EXEC level of the CLI:
debug a10 [ipv6] ospf
debug [ipv6] ospf type
The ipv6 option enables debugging for OSPFv3. Without the ipv6 option,
debugging is enabled for OSPFv2.

The type specifies the types of OSPF information to log, and can be one or
more of the following:
• all – Enables debugging for all information types listed below.
• events – Enables debugging for OSPF events.
• ifsm – Enables debugging for the OSPF Interface State Machine

(IFSM).
• lsa – Enables debugging for OSPF Link State Advertisements (LSAs).
• nfsm – Enables debugging for the OSPF Neighbor State Machine

(NFSM).
• nsm – Enables debugging for the Network Services Module (NSM).
The NSM deals with use of ACLs, route maps, interfaces, and other net-
work parameters.
• packet – Enables debugging for OSPF packets.
• route – Enables debugging for OSPF routes.
For each level, both debug commands are required.
CLI Example
The following commands configure OSPFv2 logging to a local file.
ACOS(config)#router log file name ospf-log
ACOS(config)#router log file per-protocol
ACOS(config)#router log file size 100
ACOS(config)#debug a10 ospf all
ACOS(config)#debug ospf packet
These commands create a router log file named “ospf-log”. The per-proto-
col option will log messages for each routing protocol separately. The log
file will hold a maximum 100 MB of data, after which the messages will be
saved in a backup and the log file will be cleared.
The following command displays the contents of the local router log file:
ACOS(config)#show router log file ospfd
2010/04/21 09:57:20 OSPF: IFSM[ve 3:1.1.1.2]: Hello timer expire
2010/04/21 09:57:20 OSPF: SEND[Hello]: To 224.0.0.5 via ve
3:1.1.1.2,
length
64
2010/04/21 09:57:20 OSPF:
-----------------------------------------------------

2010/04/21 09:57:20 OSPF: Header
2010/04/21 09:57:20 OSPF: Version 2
2010/04/21 09:57:20 OSPF: Type 1 (Hello)
2010/04/21 09:57:20 OSPF: Packet Len 48
2010/04/21 09:57:20 OSPF: Router ID 2.2.2.2
2010/04/21 09:57:20 OSPF: Area ID 0.0.0.0
2010/04/21 09:57:20 OSPF: Checksum 0x0
2010/04/21 09:57:20 OSPF: Instance ID 0
2010/04/21 09:57:20 OSPF: AuType 2
2010/04/21 09:57:20 OSPF: Cryptographic Authentication
2010/04/21 09:57:20 OSPF: Key ID 1
2010/04/21 09:57:20 OSPF: Auth Data Len 16
2010/04/21 09:57:20 OSPF: Sequence number 1271830931
2010/04/21 09:57:20 OSPF: Hello
2010/04/21 09:57:20 OSPF: NetworkMask 255.255.255.0
2010/04/21 09:57:20 OSPF: HelloInterval 10
2010/04/21 09:57:20 OSPF: Options 0x2 (-|-|-|-|-|-|E|-)
2010/04/21 09:57:20 OSPF: RtrPriority 1
2010/04/21 09:57:20 OSPF: RtrDeadInterval 40
2010/04/21 09:57:20 OSPF: DRouter 1.1.1.200
2010/04/21 09:57:20 OSPF: BDRouter 1.1.1.2
2010/04/21 09:57:20 OSPF: # Neighbors 1
2010/04/21 09:57:20 OSPF: Neighbor 31.31.31.31
2010/04/21 09:57:20 OSPF:
-----------------------------------------------------
2010/04/21 09:57:21 OSPF: IFSM[ethernet 2:3.3.3.1]: Hello timer
expire
2010/04/21 09:57:21 OSPF: SEND[Hello]: To 224.0.0.5 via ethernet
2:3.3.3.1,
length 48
2010/04/21 09:57:21 OSPF:
-----------------------------------------------------
2010/04/21 09:57:21 OSPF: Header
2010/04/21 09:57:21 OSPF: Version 2
2010/04/21 09:57:21 OSPF: Type 1 (Hello)
2010/04/21 09:57:21 OSPF: Packet Len 48
2010/04/21 09:57:21 OSPF: Router ID 2.2.2.2
2010/04/21 09:57:21 OSPF: Area ID 0.0.0.0
2010/04/21 09:57:21 OSPF: Checksum 0x49eb
2010/04/21 09:57:21 OSPF: Instance ID 0
2010/04/21 09:57:21 OSPF: AuType 0

2010/04/21 09:57:21 OSPF: Hello
2010/04/21 09:57:21 OSPF: NetworkMask 255.255.255.0
2010/04/21 09:57:21 OSPF: HelloInterval 10
2010/04/21 09:57:21 OSPF: Options 0x2 (-|-|-|-|-|-|E|-)
2010/04/21 09:57:21 OSPF: RtrPriority 1
2010/04/21 09:57:21 OSPF: RtrDeadInterval 40
2010/04/21 09:57:21 OSPF: DRouter 3.3.3.2
2010/04/21 09:57:21 OSPF: BDRouter 3.3.3.1
2010/04/21 09:57:21 OSPF: # Neighbors 1
2010/04/21 09:57:21 OSPF: Neighbor 81.81.81.81
...


DHCP Overview
DHCP and DHCP Relay
DHCP Overview
Dynamic Host Configuration Protocol (DHCP) is a mechanism commonly
used by clients to auto-discover their addressing and other configuration
information when connected to a network. You can enable use of DHCP to
dynamically configure IP addresses on the following types of interfaces:
• Management interface – A single IP address can be assigned.
• Ethernet data interfaces – Multiple IP addresses can be assigned.
Likewise, a new configuration option for VIPs and IP NAT pools enables
the VIP or pool to use the DHCP-assigned address of a given data interface.
If this option is enabled, ACOS updates the VIP or pool address any time
the specified data interface’s IP address is changed by DHCP.
Notes
• DHCP can be enabled on an interface only if that interface does not
already have any statically assigned IP addresses.
• On ACOS devices deployed in gateway (Layer 3) mode, Ethernet data
interfaces can have multiple IP addresses. An interface can have a com-
bination of dynamically assigned addresses (by DHCP) and statically
configured addresses. However, if you plan to use both methods of
address configuration, static addresses can be configured only after you
finish using DHCP to dynamically configure addresses. To use DHCP in
this case, you must first delete all the statically configured IP addresses
from the interface.
• On SoftAX models, if single-IP mode is used, DHCP can be enabled
only at the physical interface level.
• On devices deployed in Transparent (Layer 2) mode:
• you can enable DHCP on the management interface and at the
global level.
• The VIP address and pool NAT address (if used) should match the
global data IP address of the device. Make sure to enable this option
when configuring the VIP or pool.

DHCP Relay Overview
Configuring DHCP
USING THE CLI
To enable DHCP on an interface, use the following command at the config-

uration level for the interface:
[no] ip address dhcp
DHCP Relay Overview

This section describes DHCP relay support and how to configure it.
You can configure the ACOS device to relay DHCP traffic between DHCP
clients and DHCP servers located in different VLANs or subnets.
DHCP relay is supported only for the standard DHCP protocol ports:
• Boot protocol server (BOOTPS) – UDP port 67
• Boot protocol client (BOOTPC) – UDP port 68
DHCP relay service is supported for IPv4 and IPv6.
DHCP is a Client-Server protocol and relies on broadcast communication

between the client and server for packet exchanges. Accordingly, the clients
and the servers must be in the same broadcast domain (Layer 2 VLAN) for
this to work, since Layer 3 routers typically do not forward broadcasts.
However, in most deployments it is not practical to have a DHCP server in
each Layer 2 VLAN. Instead, it is typical to use a common DHCP server for
all VLANs and subnets in the network.
To enable DHCP communication between different VLANs or subnets, you

can use a DHCP relay. A DHCP relay acts as a mediator between the DHCP
client and the DHCP server when they are not in the same broadcast
domain.
To configure the ACOS device as a DHCP relay, configure the DHCP

server IP address as a helper address on the IP interface connected to DHCP
clients. The ACOS device intercepts broadcast DHCP packets sent by cli-
ents on the interface configured with the helper address.
The ACOS device then places the receiving interface’s IP address (not the
helper address) in the relay gateway address field, and forwards the DHCP

DHCP Relay Overview
packet to the server. When the DHCP server replies, the ACOS device for-
wards the response to the client.
Notes
• In the current release, the helper-address feature provides service for
DHCP packets only.
• The interface on which the helper address is configured must have an IP
address.
• The helper address can not be the same as the IP address on any inter-
face or an IP address used for SLB.
Configuring DHCP Relay

To configure DHCP relay, use the CLI.
USING THE GUI
The current release does not support this feature in the GUI.
USING THE CLI
To configure a helper address, use the following command at the configura-

tion level for the IP interface connected to the DHCP clients:
[no] ip helper-address ipaddr
Note: ACOS 2.7.1 provides support for 2 IP helper addresses per Ethernet inter-
face. Previous releases supported only one. The configuration syntax is
unchanged.
To display DHCP relay information, use the following command:

show ip helper-address [detail]
To clear statistics counters for DHCP relay, use the following command:
clear ip helper-address statistics
CLI Example
The following commands configure two helper addresses. The helper
address for DHCP server 100.100.100.1 is configured on Ethernet interface
1 and on Virtual Ethernet (VE) interfaces 5 and 7. The helper address for
DHCP server 20.20.20.102 is configured on VE 9.

DHCP Relay Overview
ACOS(config-if:ethernet1)#ip helper-address 100.100.100.1
ACOS(config-if:ethernet1)#interface ve 5
ACOS(config-if:ve5)#ip helper-address 100.100.100.1
ACOS(config-if:ve5)#interface ve 7
ACOS(config-if:ve7)#interface ve 9
The following command shows summary DHCP relay information:

ACOS(config)#show ip helper-address
Interface Helper-Address RX TX No-Relay Drops
--------- -------------- ------------ ------------ ------------ ------------
eth1 100.100.100.1 0 0 0 0
ve5 100.100.100.1 1669 1668 0 1
ve7 1668 1668 0 0
ve8 100.100.100.1 0 0 0 0
ve9 20.20.20.102 0 0 0 0
TABLE 7 show ip helper-address fields

Field Description
Interface Interface on the device. Interfaces appear in the output in
either of the following cases:
• A helper address is configured on the interface.
• DHCP packets are sent or received on the interface.
Helper-Address Helper address configured on the interface.
RX Number of DHCP packets received on the interface.
TX Number of DHCP packets sent on the interface.
No-Relay Number of packets that were examined for DHCP relay but
were not relayed, and instead received regular Layer 2/3 pro-
cessing.
Generally, this counter increments in the following cases:
• DHCP packets are received on an interface that does not
have a helper address and the packets are not destined to
the relay.
• DHCP packets are received on an interface that does have
a helper address, but the packets are unicast directly from
the client to the server and do not need relay intervention.
Drops Number of packets that were ineligible for relay and were
dropped.

DHCP Relay Overview
The following command shows detailed DHCP relay information:
ACOS#show ip helper-address detail
IP Interface: eth1
------------
Helper-Address: 100.100.100.1
Packets:
RX: 0
BootRequest Packets : 0
BootReply Packets : 0
TX: 0
No-Relay: 0
Drops:
Invalid BOOTP Port : 0
Invalid IP/UDP Len : 0
Invalid DHCP Oper : 0
Exceeded DHCP Hops : 0
Invalid Dest IP : 0
Exceeded TTL : 0
No Route to Dest : 0
Dest Processing Err : 0
IP Interface: ve5
------------
Helper-Address: 100.100.100.1
Packets:
RX: 16
TX: 14
No-Relay: 0
Drops:
Invalid Dest IP : 0
Exceeded TTL : 0

DHCP Relay Overview
IP Interface: ve7
------------
Helper-Address: None
Packets:
RX: 14
TX: 14
No-Relay: 0
Drops:
Invalid Dest IP : 0
Exceeded TTL : 0
TABLE 8 show ip helper-address detail fields

Field Description
IP Interface Interface on your device.
Helper-Address IP address configured on the interface as the DHCP helper
address.

DHCP Relay Overview
TABLE 8 show ip helper-address detail fields (Continued)
Field Description
Packets DHCP packet statistics:
• RX – Total number of DHCP packets received on the
interface.
• BootRequest Packets – Number of DHCP boot request
packets (Op = BOOTREQUEST) received on the inter-
face.
• BootReply Packets – Number of DHCP boot reply
packets (Op = BOOTREPLY) received on the interface.
• TX – Total number of DHCP packets sent on the interface.
• BootRequest Packets – Number of DHCP boot request
packets (Op = BOOTREQUEST) sent on the interface.
• BootReply Packets – Number of DHCP boot reply
packets (Op = BOOTREPLY) sent on the interface.
No-Relay Number of packets that were examined for DHCP relay but
were not relayed, and instead received regular Layer 2/3 pro-
cessing.
Generally, this counter increments in the following cases:
• DHCP packets are received on an interface that does not
have a helper address and the packets are not destined to
the relay.
• DHCP packets are received on an interface that does have
a helper address, but the packets are unicast directly from
the client to the server and do not need relay intervention.

DHCP Relay Overview
TABLE 8 show ip helper-address detail fields (Continued)
Field Description
Drops Lists the following counters for packets dropped on the inter-
face:
• Invalid BOOTP Port – Number of packets dropped
because they had UDP destination port 68 (BOOTPC).
• Invalid IP/UDP Len – Number of packets dropped because
the IP or UDP length of the packet was shorter than the
minimum required length for DHCP headers.
• Invalid DHCP Oper – Number of packets dropped because
the Op field in the packet header did not contain
BOOTREQUEST or BOOTREPLY.
• Exceeded DHCP Hops – Number of packets dropped
because the number in the Hops field was higher than 16.
• Invalid Dest IP – Number of packets dropped because the
destination was invalid for relay.
• Exceeded TTL – Number of packets dropped because the
TTL value was too low (less than or equal to 1).
• No Route to Dest – Number of packets dropped because
the relay agent (ACOS device) did not have a valid for-
warding entry towards the destination.
• Dest Processing Err – Number of packets dropped because
the relay agent experienced an error in sending the packet
towards the destination.
The following command clears the DHCP relay counters:

ACOS#clear ip helper-address statistics

Internet Group Multicast Protocol Queries
The current implementation of the ACOS software supports the generation

of generic Internet Group Multicast Protocol version 2 (IGMPv2) member-
ship query requests. The A10 Thunder™ and ACOS devices will now gen-
erate IGMP membership queries and facilitate multicast deployments.
Note: The ACOS software does not support the complete IGMP protocol or the
generation of generic membership queries for IGMPv3 or Multicast Lis-
tener Discovery (MLDv2).
Previous releases of the ACOS software did not provide support for the
IGMPv2 protocol at all, hence it did not provide IGMP membership query
support.
IGMPv2 provides the following capabilities:

• IGMP membership queries are only generated when IPv4 addresses are
configured. If any IPv6 interface addresses are recognized, no queries
will be generated.
• Generates generic IGMPv2 membership query request packets.
• The devices will not process any responses for this query request.
• Uses the default values for membership query request wherever possi-
ble.
• Provides the ability to configure the time interval for generation of these
membership queries per interface using the CLI.
• Provides support for this feature with Layer 3 Virtualization (L3V).
IGMP membership queries are supported in routed mode only and will not
be supported in non-routed mode.
FIGURE 26 IGMP Membership Queries (Routed and Non-Routed Mode)
In Routed Mode
In Figure 26, the interface for devices 1 and 2 are acting in routed mode,
that is, the IP address has been configured on the interface. When the inter-

face is in routed mode, the device can be configured to generate IGMPv2

membership queries out of this interface. However, when an IGMP mem-
bership query is received on an interface in routed mode, it will be ignored.
In Non-Routed Mode
In Figure 26, the Device 2 device is acting as a switch and both Eth 11 and
Eth12 on the Device 2 device are in non-routed mode. Eth1 on the Device 1
device and Eth2 on the Device 2 device are configured in routed mode.
Hence Eth1 interface on the Device 1 device and Eth2 on the Device 3
device can be configured to generate IGMP Membership Queries.
In this case, when the Device 2 device receives IGMP Membership Queries
on Eth11 (generated by the Device 1 device) and Eth 12 (generated by the
Device 3 device) it will accept these packets and just switch them as it
would any other packet. More importantly, it will not drop these packets
since Eth11 and Eth12 on Device 2 are acting in non-routed (switched)
mode.
Configuring IGMP Membership Queries

The CLI provides a way to configure IGMPv2 membership request queries
from the physical, virtual or trunk interface configuration level. Use the fol-
lowing command to configure this feature:
ip igmp generate-membership-query query-timer

max-resp-time response-timer
The query-timer represents the time interval (1-255 seconds) after which
your device (using the interface under which you are configuring this fea-
ture) will initiate an IGMP membership query request. Since this timer is
valid only per interface and it must be configured per interface. The default
query timer is 125 seconds. This means that IGMP membership queries will
be sent every 125 seconds from the configured interface.
The response-timer represents the time interval (in 1/10 of a second) before
which receiving devices will send an ICMP query message response to indi-
cate intention to join the IGMP group or not. Since this timer is valid only
for a particular interface, it must be configured per interface. The default
response timer is 100. This means that receiving devices have 10 seconds in
which to indicate if they will join the IGMP membership group or not.

To configure IGMP membership request queries on a physical interface, do
the following:
AX(config-if)#interface ethernet 2
AX(config-if:ethernet2)#ip address 192.168.1.1 /24
AX(config-if:ethernet2)#ip igmp generate-membership-query 10 max-resp-time
50
To view your IGMP membership request query configuration for a a physi-

cal interface, do the following:
AX(config)#show interfaces ethernet 2
Ethernet 2 is up, line protocol is up
Configured Speed auto, Actual 1Gbit, Configured Duplex auto, Actual fdx
IGMP Membership Query is enabled, IGMP Membership Queries sent 3
0 runts 0 giants
To configure IGMP membership request queries on an virtual Ethernet

interface, do the following:
AX(config)#vlan 50
AX(config-vlan:50)#tagged ethernet 1
AX(config-vlan:50)#router-interface ve 50
AX(config)#interface ve 50
AX(config-if:ve50)#ip address 10.10.10.219 /24
AX(config-if:ve50)#ip igmp generate-membership-query 10 max-resp-time 50

To view your IGMP membership request query configuration for a virtual

Ethernet interface, do the following:
AX(config)#show interfaces ve 50
VirtualEthernet 50 is up, line protocol is up
Hardware is VirtualEthernet, Address is 001f.a004.2e72
Router Interface for L2 Vlan 50
0 packets input 0 bytes
Transmitted 0 broadcasts, Transmitted 0 multicasts, Transmitted 0 unicasts
300 second input rate: 0 bits/sec, 0 packets/sec
300 second output rate: 0 bits/sec, 0 packets/sec
To configure IGMP membership request queries on a trunk, do the follow-

ing:
AX(config)#trunk 2
AX(config-trunk:2)#ethernet 2
AX(config-trunk:2)#exit
AX(config)#interface trunk 2
AX(config-if:trunk2)#enable
AX(config-if:trunk2)#ip address 11.11.11.219 /24
AX(config-if:trunk2)#ip igmp generate-membership-query 20 max-resp-time
80
AX(config-if:trunk2)#exit
To view your IGMP membership request query configuration for a trunk, do

the following:
AX(config)#show interfaces trunk 2
Trunk 2 is up, line protocol is up
Hardware is TrunkGroup, Address is 001f.a004.2e71

Overview
Application Delivery Partitions
Overview
Application Delivery Partitions (ADPs) provide aggregated services that
include networking, system, and application resources. In addition, they also
provide a mechanism to administer any given partition.
The ACOS device can be logically segmented in one of two ways:

• Using Role Based Administration (RBA) partitions
(non-network-enabled partition). For details refer to “Role Based
Administration Private Partition” on page 219.
• Using Layer 3 Virtualization (L3V) partitions (network-enabled parti-
tion). For details refer to “Layer 3 Virtualization of Private Partitions”
on page 227.
By default, an ACOS device comes with a shared partition. As a partition

administrator, you can elect to create and configure private partitions or
merely to configure the existing shared partition (provided you have the
appropriate administrative privileges).
Root admins can modify any partition, regardless of the partition being a
shared, RBA, or L3V partition.
Admins can be created with any of the following:

1. Root Access: Root admins will also have the ability to create other
admins. If an admin is created with write access, the admin will be able
to configure anything just like root admins.
2. Per Partition Access: If an admin is created with partition-write parti-

tion name access, then depending on the specified partition, the admin

Overview
will only be able to configure that particular partition, regardless of
whether the partition is an RBA or L3V partition. This depends upon the
specified name of the partition.
If you do not wish to logically segment the shared partition, you do not need
to do so. You can configure the shared partition and do not need to create or
administer either an RBA or an L3V user-created private partition. In other
words, creation of user-partitions are completely optional.
Partition Benefits
Understanding the benefits of partitioning will help you determine whether
or not partitioning is meaningful or necessary in your environment. Parti-
tioning allows the ACOS device to be logically segmented to support sepa-
rate configurations for different customers. For example, separate
companies or separate departments within an enterprise may prefer to have
their content isolated from other departments.
Within each ADP partition, you can have several different types of
resources:
VIPs, Servers, Templates, aFleX
Administrative Access Capabilities VLANs, VEs, IP Addresses
Capacity Controls and Maximum Limits

Overview
Figure 27 shows an example of an ACOS device with multiple partitions.
FIGURE 27 Multiple Partitions
In this example, a service provider hosts an ACOS device shared by two

companies: A.com and B.com. Each company has its own dedicated servers
that they want to manage in entirety. The partition for A.com contains
A.com's SLB resources. Likewise, the partition for B.com contains B.com's
SLB resources.
Admins assigned to the partition for A.com can add, modify, delete and save
only those resources contained in A.com's partition. Likewise, B.com's
admins can add, modify, delete and save only the resources in B.com's parti-
tion. For a better understanding of administrative roles, refer to “Adminis-
trative Roles” on page 200.

Overview
Types of Partitions
The ACOS device has a single shared partition and can have multiple pri-
vate partitions. By default, the ACOS device does not have any private par-
titions. An ACOS device can contain the following types of resource
partitions:
• Shared partition – The shared partition contains system and network-
ing resources. There is one shared partition for an ACOS device and it is
the default partition. The shared partition cannot be deleted.
• Private RBA partitions – Partitions that provide Layer 4-7 support are
referred to as RBA partitions. The RBA partition contains application
(SLB) resources only. System or networking resources reside in the
shared partition and not in the individual RBA private partitions. Creat-
ing an RBA partition is optional, not mandatory. An RBA partition can
be created, configured and deleted by a root admin and configured by
the partition administrator. The partition admin has access to configure
all applications within the partition. For system and network resources,
the partition admin will depend on the root admin for configuration
help. For details on RBA partitions and supported resources, refer to
“Role Based Administration Private Partition” on page 219.
• Private L3V partitions – Partitions that provide Layer 2-7 support are
referred to as L3V partitions. An L3V private partition contains applica-
tion (SLB) resources, networking resources, and the system resources.
In essence, each L3V partition can operate as an independent ACOS
device. Creating an L3V partition is optional, not mandatory. An L3V
partition can be created, configured and deleted by a root admin and
configured by the partition administrator. The partition admin has access
to configure all applications, network, and system resources within the
partition. For system and network resources, the partition admin will
depend on the root admin for configuration help. For details on L3V
partitions and supported resources, refer to “Layer 3 Virtualization of
Private Partitions” on page 227.
Hardware-Supported Number of Partitions

You can create RBA partitions on any ACOS device.
L3V can be enabled on AX 2500 series, AX 3000 series, or the AX 5000

series, with hardware-enabled multi-tenancy support for a maximum of 32,
64, 127, or 1K private partitions respectively. The number of partitions are
dependent on the hardware. Refer to Table 9.

Overview
Supported RBA and L3V Partitions Per ACOS Device

The current release provides support for up to 1 K partitions for the follow-
ing models: Thunder 6430, Thunder 5430, and AX 5630.
Table 9 lists the A10 Thunder and AX models that support RBA and L3V
partitions. The following table displays the maximum number of private
partitions that can run RBA or L3V.
The ADPs in A10 Thunder or ACOS devices can be configured in one of

possible three ways:
• Configure a maximum of 128 RBA partitions only, without any L3V
partitions.
• Configure L3V partitions only, without any RBA partitions. Ensure that
you do not exceed the maximum number of configurable L3V partitions
allowed per device, as listed in Table 9.
• Configure a combination of RBA and L3V partitions. Make sure RBA
and L3V partitions do not exceed the maximum number allowed per
A10 Thunder or ACOS device, as listed in Table 9.
TABLE 9 RBA and L3V Supported Partitions

Maximum Number of RBA Maximum Number of Layer 2/3
Device Partitions Supported Virtualization-enabled Partitions
A10 Thunder 6430
A10 Thunder 5430 128 1023
AX 5630
AX 3530 255 127
AX 5200
AX 5200-11 128 127
AX 5100
AX 3400
AX 3200-12
AX 3030
128 64
AX 3000-11-GCF
AX 3000
AX 2600
AX 3200
AX 2500 128 32
AX 1030

Overview
TABLE 9 RBA and L3V Supported Partitions (Continued)
Maximum Number of RBA Maximum Number of Layer 2/3
Device Partitions Supported Virtualization-enabled Partitions
AX 3200-11
AX 2200 Layer 2/3 virtualization
128
AX 1000-11 not supported
AX 1000
SoftAX 32 32
The total number of partitions in which Layer 2/3 virtualization can be

enabled is included in the total number of partitions supported on the
device. For example, on model AX 2500, if 32 partitions have L3V enabled,
an additional 96 partitions still can be configured as RBA partitions. How-
ever, those partitions must share network resources. They cannot run L3V.
Partition Logos
Each private partition has a logo file associated with it. The logo appears in
the upper left corner of the Web GUI. By default, the A10 Networks logo is
used. Partition admins can replace the A10 Networks logo with a company
logo. The recommended logo size is 180x60 pixels.
The following examples show Web GUI pages for two private partitions. A
company-specific logo has been uploaded for each partition.
FIGURE 28 Configurable Partition Logos

Overview
Partition-Based Logging
Note: You can configure either dedicated logging within private partition or use
the partition shared to use shared partition logging capabilities.
On ACOS devices that do not support Layer 2/3 virtualization, the output of
the log command in aFleX scripts is written into the log of the shared par-
tition, even if the aFleX script is active in a private partition.
Admins with the proper privilege level can configure local and remote log-
ging for the partition. Partition-based logging applies to the following types
of log messages:
• Admin session open/close
• Health state changes (Up/Down) to the following SLB resources: real

servers, service groups, virtual servers, and virtual ports
To configure logging for a private partition, access the configuration level

for the partition, then configure the logging parameters.
• The logging buffer for the shared partition holds a maximum of 30,000
logs by default. The maximum number of logs can be changed to
10,000-50,000 logs.
• Each private partition’s logging buffer holds a maximum of 3,000 logs
by default. The maximum number of logs can be changed to
1,000-5,000 logs.
Note: If the private partition is running from compact flash instead of the hard
drive, the default is 600 logs. The configurable range is 200-1000 logs.
Partition-Based Banners
Admins with the “write” or “write partition” access privilege level can con-
figure the banner message displayed when the Privileged EXEC level of the
CLI is accessed by a partition admin.
You may configure the default as a single or multiple lines. For details on
configuring banners using the CLI or GUI, refer to the “Basic Setup” on
page 43.

Overview
Limiting Resources for Partitions Using Templates

Resource templates will help establish resource limits per partition. In this
way, no one partition will be monopolize all available resources. For details,
refer to “Resource Templates for L3V Partitions” on page 247.
Administering Private Partitions

To administer a private partition, you must have the appropriate administra-
tive “role” and “privilege level” assigned to your role. Only a “root adminis-
trator” can assign the roles and privileges to the private partition admins.
For details on configuring roles, refer to “Configuring a Custom GUI
Access Role” on page 204. For details on admin accounts, refer to “Config-
uring Partition Admin Accounts” on page 204. For additional security-
related questions, refer to “Management Security Features” on page 459.
Once within a private partition, access GUI pages based on your privilege
level. If you only have read access, you will not be able to enter the config
mode. You can use show commands only. For example:
AX2500>enable
Password:
AX2500#
AX2500#config
Permission denied: Insufficient privilege
You cannot configure neither the shared nor any other private partition apart
from your own.
Administrative Roles
Admins with Read Write privileges (also known as root admins) can config-
ure other admin accounts, including partition admin accounts. Each account
includes a GUI access role, a CLI privilege level, or both.
The following GUI access roles and privilege levels are supported:
• GUI access roles for private partition admins:
• PartitionReadWrite

Overview
• PartitionNetworkOperator
• PartitionSlbServiceAdmin
• PartitionSlbServiceOperator
• PartitionReadOnly
• CLI privilege levels for private partition admins:

• Partition-write
• Partition-enable-disable
• Partition-read
Each private partition admin can have one GUI access role and one CLI
privilege level.
Table 10 describes the GUI access roles and CLI privilege levels.
TABLE 10 Private Partition Admin Privilege Levels

Access to
Shared
GUI Access Role CLI Privilege Level Partition Access to the Private Partition
PartitionReadWrite Partition-write Read-only Read-write for all resources.
PartitionNetworkOperator No equivalent CLI privilege None Read-only for network resources,
level. Use Partition-write. with permission to enable or disable
interfaces.
PartitionSlbServiceAdmin No equivalent CLI privilege None Read-write for SLB resources.
level. Use Partition-write.
PartitionSlbServiceOperator Partition-enable-disable None Read-only for real servers, with per-
mission to view service port statis-
tics, and to disable or enable real
servers and real server ports.
No other read-only or read-write
privileges are granted.
All access is restricted to the parti-
tion to which the admin is assigned.
PartitionReadOnly Partition-read Read-only Read-only.
In addition to the pre-configured GUI access roles described here, admins

with global read-write access can configure additional GUI access roles or
customize the preconfigured ones. (See “GUI Access Roles” on page 462.)
Administering the Shared Partition

The following GUI access roles and privilege levels are supported for root
admins. As the root admin, you will have access to read and write privileges

Overview
and will be able to administer both the shared and private RBA or L3V par-
titions:
• GUI access roles for shared and private partition admins:
• ReadWriteAdmin
• ReadOnlyAdmin
• SystemAdmin
• NetworkAdmin
• SlbServiceAdmin
• SlbServiceOperator
• PartitionReadWrite
• PartitionNetworkOperator
• PartitionSlbServiceAdmin
• PartitionSlbServiceOperator
• PartitionReadOnly
• CLI privilege levels for shared and private partition admins:

• Read
• Write
• Partition-write
• Partition-enable-disable
• Partition-read
Table 11 describes the GUI access roles and CLI privilege levels for shared
partition administrators.
TABLE 11 Shared and Private Partition Root Admin Privilege Level
GUI Access Role CLI Privilege Level Access to Shared Access to Private
Partition Partition
ReadWriteAdmin Write Read-write Read-write for all

resources (for all private
partitions)
ReadOnlyAdmin Read Read-only Read-only for all
resources (for all private
partitions)
SystemAdmin No equivalent CLI privi- Read-write for System Read-write for System
lege level. Use Write. resources only resources only (for all
private partitions)
NetworkAdmin No equivalent CLI privi- Read-write for Network Read-write for Network
lege level. Use Write. resources only resources only (for all
private partitions)

Overview
TABLE 11 Shared and Private Partition Root Admin Privilege Level
SlbServiceAdmin No equivalent CLI priv- Read-write for SLB Ser- Read-write for SLB Ser-
ilege level. Use Write. vice resources only vice resources only (for
all private partitions)
SlbServiceOperator No equivalent CLI priv- Read-only for SLB Ser- Read-only for SLB Ser-
ilege level. Use Write. vice resources, with per- vice resources, with per-
mission to enable or mission to enable or
disable servers/services disable servers/services
(for all private partitions)
PartitionReadWrite Partition-write Read-only Read-write for all
resources.
PartitionNetworkOperator No equivalent CLI privi- None Read-only for network
lege level. Use Partition- resources, with permis-
write. sion to enable or disable
interfaces.
PartitionSlbServiceAdmin No equivalent CLI privi- None Read-write for SLB
lege level. Use Partition- resources.
write.
PartitionSlbServiceOperator Partition-enable-disable None Read-only for real serv-
ers, with permission to
view service port statis-
tics, and to disable or
enable real servers and
real server ports.
No other read-only or
read-write privileges are
granted.
All access is restricted to
the partition to which the
admin is assigned.
PartitionReadOnly Partition-read Read-only Read-only.
Note: For the PartitionSlbServiceOperator role under the Access to Private Par-
tition section, it says: “All access is restricted to the partition to which the
admin is assigned”. This applies to all partition roles.
Additional Administrative Capabilities

The following information highlights what administrators can or cannot do
within a private partition:
• System and networking resources can be configured only by admins
with Read Write privileges. An admin with read/write privileges can
configure all system and networking resources for shared, l3v, or rba.
Keep in mind however that if an admin with read & write privileges
changes network resources while inside the rba partition, it basically
takes effect on the shared partition.

Overview
• A private partition can be configured and accessed only by the admins
who are assigned to it, and by admins with Read Write or Read Only
privileges.
• Admins assigned to a partition can manage only the resources inside that
partition.
Configuring a Custom GUI Access Role

The CLI does not provide a means to configure a GUI access role. It can
only be configured using the GUI.
1. Select Config Mode > System > Admin > Role.
2. Click Add.
3. Enter the role name in the Role Name field.
4. Select the access privileges for each page.

• Hide – The page cannot be viewed by admins with this role.
• RO – Read-only access.
• RW – Read-write access.
The filter options hide or display all pages of the selected access levels.
For example, to display only the pages that are hidden, select Hide next
to Filter Options.
To select individual pages under Monitor or Config, click to remove the
checkbox, expand the page list, and select the access levels for the indi-
vidual pages.
Configuring Partition Admin Accounts

To configure admin accounts and assign them to partitions, use either of the
following methods.
Note: To delete an admin account, see “Deleting an Admin Account” on

page 467.
USING THE GUI
To configure an admin account for a private partition:

1. Select Config Mode > System > Admin > Administrator.
2. Click Add. The Administrator section appears.

Overview
3. Enter the name in the Administrator Name field.
4. Enter the password for the new admin account in the Password and Con-
firm Password fields.
5. To restrict login access by the admin to a specific host or subnet:

a. Enter the address in the Trusted Host IP Address field.
b. To restrict access to just a single host, edit the value in the Netmask
field to 255.255.255.255.
c. To restrict access to a subnet, edit the value in the Netmask field to
the subnet mask for the subnet.
Note: To allow access from any host, leave the Trusted Host IP Address and
Netmask fields blank.
6. Select the role from the Role drop-down list. The role defines the read or
write access allowed to the admin for each GUI page. (See “GUI Access
Roles” on page 462.)
7. To restrict access to specific management interfaces, click the check-

boxes next to Access Type.
8. If you are configuring an admin for a private RBA or L3V partition,

select the partition from the Partition drop-down list.
9. Leave the Status enabled.
10. Click OK. The new admin appears in the Admin table.
Note: For information about the SSH Key File section, see “SSH Public Key
Authentication for SSH Management Access” on page 476.
11. Click OK. The new admin appears in the admin list.
USING THE CLI
To configure an admin account for a private partition, use the following

commands:
[no] admin admin-username password string
[no] privilege
{partition-write | partition-read |
partition-enable-disable}
partition-name

Overview
The admin command creates the admin account and changes the CLI to the
configuration level for the account. The command syntax shown here
includes the password option. You can specify the password with the
admin command, or with the separate password command at the configu-
ration level for the account. The default password is “a10”.
The default login is “admin” and the password “a10” (this is what it is
shipped with). An admin can be created without specifying a password. In
this case, the ACOS will give that admin the default password of “a10”.
For example, to create an admin called “xyz,” enter the following com-
mands:
AX2500(config)#admin xyz
AX2500(config-admin:xyz)#exit
By default, admin “xyz” will now have a default password of “a10,”

because none was specified.
To specify password:
AX2500(config)#admin xyz password xyzpw
The privilege command specifies the privilege level for the account and
assigns the account to a partition.
Note: The other admin configuration commands do not apply specifically to

role-based administration. For information about these other commands,
see “Configuring Additional Admin Accounts” on page 460.
Disabling Private Partition Admin Access to the Shared Partition

Admins of the shared partition can prevent private partition admins from
changing their active partition to the shared partition.
By default, a private partition admin is allowed to change the active parti-

tion to the shared partition. You can disable this access on a global basis, for
all private partition admins.
Note: The option takes affect immediately, even for private partition admins
who have active sessions. However, if a private partition admin is already
in the shared partition, this option does not force the admin to leave the
partition.

Overview
USING THE GUI
The current release does not support configuration of this option in the GUI.
USING THE CLI
To disable all private partitions admins from accessing the shared partition,
use the following command at the global configuration level of the CLI:
[no] partition no-sharing

Overview
Configuring Private Partitions

To configure an RBA or L3V private partitions, log in using an admin
account with Read Write privileges, and perform the steps described in See
“Role Based Administration Private Partition” on page 219.and “Layer 3
Virtualization of Private Partitions” on page 227.
Deleting a Partition
Only an admin with Read Write privileges can delete a partition. When a
partition is deleted, all resources within the partition also are deleted.
Note: When you delete a partition, resources associated with the partition are
permanently deleted. This includes SSL certificates and keys, and aFleX
scripts. These resources are deleted even if you reload or reboot without
saving the configuration. In this case, the partition configuration is
restored but the resources are still gone.
USING THE GUI

1. Select Config Mode > System > Admin.
2. On the menu bar, select Partition.
3. Select the partition. (Click the checkbox next to the partition name.)
4. Click Delete.
USING THE CLI
To delete a partition, use the following command at the global configuration

level of the CLI:
no partition [partition-name]
If you do not specify a partition name, the CLI displays a prompt to verify
whether you want to delete all partitions and the resources within them.
Enter “y” to confirm or “n” to cancel the request.

Viewing and Saving the Configuration

Admins with Read Write or Read Only privileges can view resources in any
partition. Admins assigned to a partition can view the resources in the
shared partition and in their own private partition but not in any other pri-
vate partition.
Admins with Read Write privileges can save resources in any partition.
Admins with Partition-write privileges can save only the resources within
their own partition.
Viewing the Configuration

To view configuration information on an ACOS device configured with pri-
vate partitions, use either of the following methods.
USING THE GUI
See “Switching To Another Partition” on page 211.
USING THE CLI
To view the configuration, use the following commands:
show running-config
[all-partitions | partition partition-name]
show startup-config
If you enter the command without either option, the command shows only
the resources that are in the shared partition.
The all-partitions option shows all resources in all partitions. In this case,
the resources in the shared partition are listed first. Then the resources in
each private partition are listed, organized by partition.
If you specify a private partition-name, only the resources in that partition

are listed.
Note: If an admin assigned to a private partition uses the all-partitions option,

the option does not list resources in any other private partitions. Similarly,
if a partition admin enters the name of another private partition for parti-

tion-name, an “Insufficient privilege” warning message appears. The
resources of the other partition are not displayed.
Saving the Configuration

To save the configuration on an ACOS device configured with private parti-
tions, use either of the following methods.
USING THE GUI
To save the configuration in the GUI, click the Save button on the title bar.
The GUI automatically saves only the resources that are in the current parti-
tion view. For example, if the partition view is set to the “companyB” pri-
vate partition, only the resources in that partition are saved.
USING THE CLI
To save the configuration, use the following command:
write memory
If you enter the command without either option, the command saves only
the changes for resources that are in the current partition.
The all-partitions option saves changes for all resources in all partitions.
If you specify a private partition-name, only the changes for the resources
in that partition are saved.
Caution: Before saving all partitions or before a reload, reboot, or shutdown

operation, a Read Write admin should notify all partition admins to
save their configurations if they wish to. Saving all partitions without
consent from the partition admins is not recommended.
Note: The all-partitions and partition partition-name options are not applica-
ble for admins with Partition-write privileges. Partition admins can only
save their respective partitions. For these admins, the command syntax is
the same as in previous releases. The options are available only to admins
with Read Write privileges.
Note: A configuration can be saved to a different configuration profile name

(rather than being written to “startup-config”), as supported in previous
releases. In this case, the resources that are saved depend on the parti-
tion(s) to which the write memory command is applied. Unless the

Switching To Another Partition
resources in the shared partition are being saved, the configuration profile
name used with the write memory command must already exist. The
command does not create new configuration profiles for private parti-
tions.
Switching To Another Partition

Admins with Read Write or Read Only privileges can select the partition to
view. When an admin with one of these privilege levels logs in, the view is
set to the shared partition by default, which means all resources are visible.
To change the view to a private partition, use either of the following meth-
ods.
USING THE GUI

1. On the title bar, select the partition from the Partition drop-down list.
A dialog appears, asking you to confirm your partition selection.
2. Click Yes.
3. Click the Refresh button next to the Partition drop-down list. You must
refresh the page in order for the view change to take effect.
USING THE CLI
Use the following command at the Privileged EXEC level of the CLI:
active-partition {partition-name | shared}
To change the view to a private partition, specify the partition name. To

change the view to the shared partition, specify shared.
The following command changes the view to private partition “companyA”:

ACOS#active-partition companyA
Currently active partition: companyA
ACOS[companyA]#
The name of the partition is shown in the CLI prompt.

Synchronizing the Configuration

In High Availability (HA) deployments, either VRRP-A or the older imple-
mentation of HA, partition resources can be synchronized to the backup
ACOS device.
If the ACOS device uses the ACOS Virtual Chassis System (aVCS) feature,
configuration synchronization is automatic. (See “Automated Configuration
Synchronization” on page 463.) Otherwise, the configuration must be syn-
chronized manually.
Manual Synchronization
When an admin assigned to a private partition manually synchronizes the
configuration to the other ACOS device in a High-Availability (HA) pair,
the resources in the private partition are synchronized for that partition. No
other resources are synchronized.
An admin with Read Write privileges can specify any partitions(s) to syn-
chronize.
Note: If you plan to synchronize the Active ACOS device’s running-config to

the Standby ACOS device’s running-config, make sure to use one of the
following synchronization options. Performing any one of these options
ensures that new private partitions appear correctly in the Standby ACOS
device’s configuration.
– Synchronize all partitions
– Synchronize the shared partition to the startup-config first, then syn-
chronize the private partition to the running-config.
– On the Active ACOS device, synchronize the shared partition to the
running-config first. Log onto the Standby ACOS device and save the
shared partition (write memory partition shared). Then, on the Active
ACOS device, synchronize the private partition to the running-config.
Note: In the current release, HA config-sync to a partition is supported only for

Active-Standby HA configurations.
USING THE GUI
In the GUI, the synchronization applies only to the current partition.

USING THE CLI
The ha sync commands enable you to specify the partition and the IP
address of the target device. For admins with Read Write privileges, here is
the syntax for the ha sync commands:
ha sync all
{to-startup-config [with-reload] |
to-running-config}
[all-partitions | partition partition-name] ipaddr
ha sync startup-config
to-running-config}
ha sync running-config
to-running-config}
ha sync data-files
To synchronize the configuration for all partitions, use the all-partitions

option. To synchronize only a specific private partition, use the partition
partition-name option. By default, the synchronization applies only to the
current partition.
If you plan to use the ha sync running-config to-running-config com-

mand, see the note at the beginning of this section first.
For admins logged on with Partition Write privileges, the following syntax
is available:
ha sync all to-startup-config ipaddr
ha sync startup-config to-startup-config ipaddr
ha sync running-config to-startup-config ipaddr
ha sync data-files ipaddr
Admins with Partition Write privileges are not allowed to synchronize to the
running-config or to reload the other ACOS device.

Operator Management of Real Servers

This section is for admins with Partition Real Server Operator privileges.
The procedures in this section explain how to view service port statistics,
and how to disable or re-enable real servers and individual service ports on
the servers.
Note: Service port statistics are not available in the GUI. To display service port
statistics, use the CLI instead.
USING THE GUI

This section describes how to enable or disable real servers and service
ports using the GUI.
To Disable or Re-Enable Servers

1. Log in with your Partition-enable-disable account.
2. Select the checkbox next to each server you want to disable or re-enable,
or click Select All to select all of the servers.
3. Click Disable or Enable.
FIGURE 29 Real Server Management in Operator Mode
Note: Although the GUI displays the Delete and New buttons, these buttons are
not supported for admins with Partition Real Server Operator privileges.
To Disable or Re-Enable Individual Real Server Ports

1. Log in with your Partition Real Server Operator account.
2. Select the checkbox next to each server for which you want to disable or
re-enable service ports, or click Select All to select all of the servers.
3. Click Edit.
4. A list of all the service ports on the selected servers is displayed.

5. Select the port numbers you want to disable or re-enable.
A single row appears for each port number. Selecting a row selects the
port number on each of the real servers you selected in step 2.
6. Click Disable or Enable.
7. Click OK.
FIGURE 30 Disabling Service Ports – Selecting the Servers
FIGURE 31 Disabling Service Ports – Selecting the Ports
USING THE CLI
To View Service Statistics

To view configuration information and statistics for real servers used by the
partition, log in with your Partition-enable-disable account and use the fol-
lowing command:
show slb server [server-name] [config]

CLI Example
login as:compAoper
Welcome to ACOS
Password:********
Last login: Wed Aug 20 08:58:45 2008 from 192.168.1.130
[type ? for help]

ACOS[companyA]>show slb server
Total Number of Services configured: 2
Current = Current Connections, Total = Total Connections
Fwd-pkt = Forward packets, Rev-pkt = Reverse packets
Service Current Total Fwd-pkt Rev-pkt Peak-conn State
---------------------------------------------------------------------------------------
compArs1:80/tcp 23 320543 1732383 1263164 7771 Up
compArs1: Total 23 321024 1732383 1263164 88421 Up
ACOS[companyA]>show slb server config
Total Number of Services configured: 2
H-check = Health check Max conn = Max. Connection Wgt = Weight
Service Address H-check Status Max conn Wgt
------------------------------------------------------------------------------
compArs1:80/tcp 7.7.7.7 Default Enable 1000000 1
compArs1 7.7.7.7 Default Disable 1000000 1

compArs2 8.8.8.8 Default Enable 1000000 1
To Disable or Re-Enable Servers

Use the following commands to access the configuration level of the CLI:
enable
config
The enable command accesses the Privileged EXEC level. The end of the
command prompt changes from > to #. If you are prompted for a password,
enter the enable password assigned by the Read Write administrator. The
config command accesses the configuration level.
At the configuration level, use the following command to access the opera-
tion level for the real server:
slb server server-name [ipaddr]

Use one of the following commands to change the state of the server:
{disable | enable}
To verify the state change, use the show slb server command.
To Disable or Re-Enable Real Service Ports

Access the configuration level, then use the following command to access
the operation level for the server:
slb server server-name [ipaddr]
Use the following command to access the operation level for the service
port:
port port-num {tcp | udp}
Use one of the following commands to change the state of the service port:
{disable | enable}
To verify the state change, use the show slb server command.
CLI Example
The following commands access the configuration level and disable real
server “compArs1” and verify the change:
ACOS[companyA]>enable
Password:********
ACOS[companyA]#config
ACOS[companyA](config)#slb server compArs1
ACOS[companyA](config-real server)#disable
ACOS[companyA](config)#show slb server compArs1
Total Number of Services configured on Server compArs1: 1
Current = Current Connections, Total = Total Connections
Fwd-pkt = Forward packets, Rev-pkt = Reverse packets
Service Current Total Fwd-pkt Rev-pkt Peak-conn State
---------------------------------------------------------------------------------
compArs1:80/tcp 0 0 0 0 0 Down
compArs1: Total 0 0 0 0 0 Disabled
ACOS[companyA](config)#show slb server compArs1 config
Total Number of Services configured on Server compArs1: 1
H-check = Health check Max conn = Max. Connection Wgt = Weight
Service Address H-check Status Max conn Wgt
------------------------------------------------------------------------------
compArs1 7.7.7.7 Default Disable 1000000 1


Overview
Role Based Administration Private Partition
Overview
Role Based Administration (RBA) partitions provide Layer 4-7 support and
no direct access to system and networking resources. RBA partitions are
dependent on the shared partition’s network resources. If an administrator
has read and write privileges to all partitions, the admin can add VLANs,
VEs, and assign IP addresses to the RBA partition. However, the configura-
tion will be visible as part of the shared partition, and not the RBA partition.
If an administrator only has access to an RBA partition, the admin cannot

add or remove any VLANs, VEs, and, IP addresses. The CLI blocks private
RBA-only privileged administrators from creating any network resources.
(This also applies to the GUI.) They must use the shared partition’s already
defined network configurations to create VIPs, servers, and service-groups.
These created servers, VIPs, service-groups, templates, and aFleX tem-
plates will still be independent of the shared partition, but will be on the
same network. Since the RBA partitions do not display the network
resources, partition administrators cannot remove them.
The following graphic represents how an ACOS device can be carved into
separate RBA partitions.

Overview
Resources Contained in RBA Private Partitions

The following types of resources can be contained in RBA private parti-
tions:
• Layer 4-7 (Application/SLB) resources:
• Real servers
• Virtual servers
• Service groups
• Templates
• Health monitors
• Certificates and keys
• aFleX policies
Resource names must be unique within a partition. However, the same name
can be used for resources in different partitions. For example, partitions
“A.com” and “B.com” can each have a real server named “rs1”. The ACOS
device is able to distinguish between them.
All RBA partitions depend on the shared partition for the following net-
working and system resources. The resources in the shared partition are not
configurable by admins assigned to the RBA private partitions. However, as
the “root admin” who has read and write privileges, you can configure net-
working and system resources in the shared partition (that may be tweaked
by a root or an ‘all partition’ admin).
The ACOS device will automatically assign an ID when you create a parti-
tion. This ID will be chronological in order. For example, when you create
two partitions, the first RBA partition will be called “rba1” and the second
one will be called “rba2.”
• Layer 2 (System) resources:
• VLANs
• Virtual Ethernet (VE) interfaces
• Static MAC entries
• Layer 3 (Network) resources:

• IP addresses
• ARP entries
• Routing tables
• ACLs

Simple RBA Partition Configuration
An ADP that is partitioned with RBA partitions provides the following
capabilities as shown in the following graphic:
Direct Access to configure

IPs, Servers, Templates, aFleX
Administrative Access Capabilities Requires “root admin” access to configure

“root admin” and RBA Partition Admin VLANs, VEs, IP Addresses
Requires “root admin access” to configure

Migrating Resources Between Partitions

Resources cannot be moved directly from one partition to another. To move
resources, a root admin with read and write privileges to all partitions must
delete the resources from the partition they are in, then recreate the
resources in the new partition.

To configure an RBA private partitions, log in using an admin account with
Read Write privileges, and perform the steps described below:
1. Configure partitions.
2. Configure admin accounts and assign them to partitions.
3. Configure any SLB shared resources that you want to make available to
multiple private partitions. (For information about configuring SLB
resources, see the SLB configuration chapters in this guide.)
Configuration of SLB resources within a private partition can be per-

formed by an admin with Partition-write privileges who is assigned to
the partition. For details on administrative roles and privileges, refer to
“Application Delivery Partitions” on page 193.
Note: This document shows how to set up partitions and assign admins to them.
The partition admins will be able to configure their own SLB resources.
However, you will need to configure connectivity resources such as inter-
faces, VLANs, routing, and so on. You also will need to configure any
additional admin accounts for the partition.

Creating Private Partitions
To create a private partition, use either of the following methods.
USING THE GUI

3. Click Add.
The Partition section appears.
FIGURE 32 Config Mode > System > Admin > Partition
4. Enter a name for the partition. This is similar to using the partition
name command.
5. Disable the Network Partition option (default)
6. To upload a logo for the partition, click Browse and navigate to the logo
file.
7. If a partition logo is not uploaded, the A10 Networks logo is used by

default.
8. Click OK. The new partition appears in the partition list.
FIGURE 33 Config Mode > System > Admin > Partition - List

USING THE CLI
To configure a private partition, use the following command at the global

[no] partition partition-name

[[max-aflex-file num]] id num]
The partition-name can be 1-14 characters.
The max-aflex-file option specifies the maximum number of aFleX policies

the partition can have. You can specify 1-128. The default is 32.
The id option assigns an ID to the partition. The partition ID ensures that a

partition’s configuration remains consistent across devices in multi-device
deployments (HA). The partition ID can be 1-128. The ACOS device does
not automatically assign an ID.
Note: In show partition output, the ID is listed in the Index column. The Index
column also lists potential IDs for partitions to which IDs have not been
assigned. However, these potential IDs do not appear in the configuration
(running-config or startup-config). Information on all user-created private
RBA or L3V partitions will also be displayed.
The following subsections show additional RBA configuration examples.

1. Create the RBA partition:
AX3400(config)#partition rba1
2. Create the admin and assign privileges:

AX3400(config)#admin admin-rba1 password test
AX3400(config-admin:admin-rba1)#privilege partition-write rba1
Modify Admin User successful!
AX3400(config-admin:admin-rba1)#access axapi web cli
The above command denotes that the rba admin created will have read and
write access for axapi, webui, and cli.
AX3400(config-admin:admin-rba1)#exit

3. Now that the admin has been successfully created, login to the partition
using admin account. Opening a new session by typing in information
for the IP address will get to the login prompt:
login as: admin-rba1
Password:
Last login: Thu Aug 30 19:46:54 2012 from 192.168.33.157
ACOS system is ready now.
[type ? for help]
AX3400[rba1]>enable
Password:
AX3400[rba1]#
AX3400[rba1]#config
AX3400[rba1](config)#
4. Configure the RBA partition. In a RBA partition you can configure

servers, service groups, and VIPs.
a. Configure a server:
AX3400[rba1](config)#slb server s1 20.20.20.25
AX3400[rba1](config-real server)#port 80 tcp
AX3400[rba1](config-real server-node port)#exit
AX3400[rba1](config-real server)#exit
b. Create service-groups:
AX3400[rba1](config)#slb service-group s1-80 tcp
AX3400[rba1](config-slb svc group)#member s1:80
AX3400[rba1](config-slb svc group)#exit
c. Create VIPs:
AX3400[rba1](config)#slb virtual-server vip1 10.10.10.15
AX3400[rba1](config-slb vserver)#port 80 http
AX3400[rba1](config-slb vserver-vport)#service-group s1-80
5. Display your RBA partition configuration using the show running com-
mand. RBA partitions will only show Layer 4-7 configuration such as
configuration of servers, service-groups, and VIPs. It will not display
any network resources, such as VLANs, VEs, or interfaces, since RBA
partitions do not provide configurable network resources.
AX3400[rba1](config)#show running
!Current configuration: 543 bytes
!

!Configuration last updated at 19:51:05 PDT Thu Aug 30 2012
!
active-partition rba1
!
slb server s1 20.20.20.25
port 80 tcp
!
slb service-group s1-80 tcp
member s1:80
!
slb virtual-server vip1 10.10.10.15
port 80 http
name _10.10.10.15_HTTP_80
service-group s1-80
!
Example 2: Multiple RBA Partition Configuration

The following commands configure two private partitions, “companyA”
and “companyB”, and verify that they have been created.
ACOS(config)#partition companyA id 1
ACOS(config)#partition companyB id 2
ACOS(config)#show partition
Max Number allowed: 128
Total Number of partitions configured: 2
Partition Name L3V Index Max. Aflex Admin Count
--------------------------------------------------
companyA No 1 32 0
companyB No 2 32 0
The following commands configure an admin account for each partition:

ACOS(config)#admin compAadmin password compApwd
ACOS(config-admin:compAadmin)#privilege partition-write companyA
Modify Admin User successful !
ACOS(config-admin:compAadmin)#exit
ACOS(config)#admin compBadmin password compBpwd
ACOS(config-admin:compBadmin)#privilege partition-write companyB
ACOS(config-admin:compBadmin)#exit

The following command displays the admin accounts:
ACOS(config)#show admin
UserName Status Privilege Partition
-------------------------------------------------------
admin Enabled R/W
compAadmin Enabled P.R/W companyA
compBadmin Enabled P.R/W companyB
The show admin command shows privilege information for CLI access as
follows:
• R/W – The admin has Read-Write privileges.
• R – The admin has Read-Only privileges.
• P.R/W – The admin is assigned to a private partition and has Partition-

write (read-write) privileges within that partition.
• P.R – The admin is assigned to a private partition and has Partition-read
(read-only) privileges within that partition.
• P.RS Op – The admin is assigned to a private partition but has permis-
sion only to view service port statistics for real servers in the partition,
and to disable or re-enable the real servers.

Overview
Layer 3 Virtualization of Private Partitions
Overview
The A10 Thunder Series and AX Series provide Virtualized Management
through Layer 3 Virtualization (L3V). L3V allows administrators
(“admins”) to configure and view network and SLB resources based on
administrative domains (“partitions”). In addition to providing separate par-
titions for these types of resources, L3V partitions support direct access to
networking resources per partition. Layer 2/3 virtualization can be enabled
on individual partitions, allowing partitions to own their own network
resources.
L3V partitions are part of the Application Delivery Partitions (ADP) feature
providing aggregated services that include networking, system, and applica-
tion resources. In addition, they also provide a mechanism to administer any
given partition. For details on partitioning, refer to “Application Delivery
Partitions” on page 193. L3V partitions provide a mechanism to segment a
single ACOS device into multiple instances that behave independent of
each other.
The following graphic represents how an ACOS device can be carved into
separate L3Vpartitions (network-enabled partition).
Layer 3 Virtualization (L3V) allows the ACOS device to split layer 2, 3, and
4-7 resources in multi-instance architecture enabling virtual segmentation
for multi-client organizations. Specifically, in a corporation or at a service
provider where many clients use the same load balancer, an administrator
can create multiple private partitions and then control access to each organi-
zation’s configuration or space. Each organization then can authenticate
their own partition and configure their own devices as if they were a com-
pletely, separate organization.

Overview
ACOS devices provide support for multiple L3V partitions, and the number
of partitions they support are platform dependent. For information on a
maximum number of supported partitions that can run L3V, refer to “Sup-
ported RBA and L3V Partitions Per ACOS Device” on page 197.
Every configured device has one shared partition. By default, all partitions
will have access to the shared partition unless the administrator restricts
access to the shared partition. For example, when a user logs into a device,
the user will also have access, although limited, to the shared partition. For
instance, the limited access will include access to templates.
Nothing within partitions is shared, unless an administrator allows users to

share interfaces. When creating partitions, an administrator may allow users
to share partitions or leave the shared partition blank. Users too can share
interfaces, but are not required to.
The administrator may create partitions using CLI or GUI. For details on
configuring partitions, refer to “L3V Partition Configuration” on page 236.
Within an L3V partition, access the resource usage templates to create a

template where you can specify preferred limits for application, system, and
network resources to prevent any one partition from other partitions from
monopolizing all the available resources. For details, refer to See “Resource
Templates for L3V Partitions” on page 247.
L3V Advantages
Content Isolation—A partition administrator will be able to create
servers, service-groups, VIPs, templates, and aFleX scripts per parti-
tion. However, everything will be in a network that is totally indepen-
dent from that of a shared or any other L3V partition.
Multi-tenancy—L3V within ADPs provides a space saving multi-

tenant solution. ADP role-based management allows configuration
and monitoring capabilities within individual partitions.
Resource Usage Templates—Via resource usage templates, L3V parti-
tions can ensure that no partition is starved of any network, system, or appli-
cation resources. These templates can contain preconfigured new limits for
these values from their prior default values. For details, refer to See
“Resource Templates for L3V Partitions” on page 247.

Overview
Resources Contained in L3V Private Partitions

Within each L3V partition, you can have several different types of
resources:
An ADP that is an L3V partition provides the following capabilities as
shown in the following graphic:
VIPs, Servers, Templates,aFleX
Administrative Access Capabilities L3V VLANs, VEs, IP Addresses
Without these capabilities, each partition will not have direct access to net-
working resources. For details on L3V, refer to “Layer 2/3 Virtualization”
on page 230.
For example, the administrator, as a root user, can access partition 1, assign
a particular interface, configure the interface, tag a VLAN, assign a VLAN
to that interface, and control access to the VLAN against unauthorized use.
VLANs in particular, can only belong to one partition.
Within an L3V partition, access the resource usage templates to create a

template where you can specify preferred limits for application, system, and
network resources. For details, refer to See “Resource Templates for L3V
Partitions” on page 247.
The following types of resources can be contained in an L3V private parti-

tion:
• Layer 2 (System) resources:
• VLANs
• Virtual Ethernet (VE) interfaces
• Static MAC entries
• Layer 3 (Network) resources:

• IP addresses
• ARP entries
• Routing tables
• ACLs

Overview
• Layer 4-7 (Application/SLB) resources:
• Real servers
• Virtual servers
• Service groups
• Templates
• Health monitors
• Certificates and keys
• aFleX policies
All other types of resources can reside only in the shared partition and are
not configurable by admins assigned to private partitions but can be
tweaked by a root or ‘all partition’ admin.
Resource names must be unique within an L3Vpartition. However, the same

name can be used for resources in different partitions. For example, parti-
tions “A.com” and “B.com” can each have a real server named “rs1”. The
ACOS device is able to distinguish between them.
After creating and assigning users to a partition, the administrator may then
configure all resources to the partition.
Layer 2/3 Virtualization

Layer 2/3 virtualization allows a private partition to have its own network
resources. You can enable Layer 2/3 virtualization on an individual partition
basis.
Admins with the proper privilege level for a private partition on which
Layer 2/3 virtualization is enabled can configure network resources for
exclusive use by the individual partition:
Each partition has its own MAC table and ARP table, and its own IPv4 and
IPv6 route tables. They are completely separate from the MAC, ARP, and IP
route tables in other partitions.
After a network resource belongs to a partition, the resource does not appear
in show command output except for the L3V partition and the partition to
which the interface belongs. Likewise, statistics for the resource are not
included in the statistics counters for other private partitions.
Note: An exception is tagged VLAN ports. A port that is a tagged member of

any VLAN is available to all partitions. The VLAN tag ensures that a
given partition’s traffic remains within that partition’s Layer 2 broadcast
domain.

Overview
Jumbo Frame Support
The current release adds support for jumbo frames. A jumbo frame is an
Ethernet frame that is more than 1522 bytes long. For details, refer to
“Jumbo Frames” on page 101.
Requirements
Layer 2/3 resources must be unique within a given partition. However, some
types of Layer 2/3 resources can be the same in multiple partitions, as long
as they remain unique within a given partition:
• VE number
Note: VE numbers must be unique and must match the VLAN ID in an L3V
partition. If a VLAN ID already belongs to a shared or another L3V parti-
tion, do not re-use it.
• NAT pool
• Interface IP addresses
• IP addresses in source NAT pools
• Virtual server IP addresses (VIPs)
For example, multiple partitions can use a real server that has IP address
10.10.10.10, but a given partition can have only one instance of the server.
Each private partition in which Layer 2/3 virtualization is enabled supports

a maximum of 2 loopback interfaces, with IDs 1-2. Loopback interface IDs
1-10 are valid in the shared partition.
Table 12 lists the operational differences between partitions in which Layer

2/3 virtualization is enabled or disabled.

Overview
.
TABLE 12 Operational Comparison Between Layer 2/3 Virtualization Enabled and Disabled
Layer 2/3 Virtualization Enabled Layer 2/3 Virtualization Disabled
Resource Private Partition Shared Partition Private Partition Shared Partition
Port state Enabling and Enabling and Enabling and Enabling and
disabling allowed disabling of any disabling allowed disabling allowed
port allowed from
shared partition
Untagged VLAN Visible only in the Visible in the shared Visible in all the Visible in the shared
ports partition they partition private partitions partitions
belong to Cannot be config- Can be configured, Can be configured,
Cannot be configured if it belongs to disabled, enabled disabled, enabled
ured from a some partition other from all the from the shared par-
partition which they than shared partitions tition
do not belong to
Tagged VLAN ports Visible in all the Visible in all the Visible in all the Visible in all the
partitions partitions partitions partitions
Disabling or Disabling or Disabling or Disabling or
enabling a tagged enabling a tagged enabling a tagged enabling a tagged
port within a parti- port within the port within a parti- port in the shared
tion does not dis- shared partition also tion also disables or partition also dis-
able the port in disables the port in enables the port in ables or enables the
other partitions all other partitions other partitions port in all private
partitions
Trunks Allowed Allowed Allowed Allowed
Note: The trunk can
be configured only
in the shared parti-
tion.
VLANs Same VLAN ID Same VLAN ID Same VLAN ID Same VLAN ID
cannot be config- cannot be config- cannot be config- cannot be config-
ured in different ured in shared parti- ured in different ured in shared parti-
partitions tion partitions tion
VEs Same VE numbers Same VE numbers Same VE numbers Same VE numbers
are not allowed in are not allowed in not allowed in dif- not allowed in dif-
different partitions. the shared partition. ferent partitions ferent partitions
The VE must match The VE must match
the VLAN ID, so the VLAN ID, so
cannot be re-used. cannot be re-used.

Overview
TABLE 12 Operational Comparison Between Layer 2/3 Virtualization Enabled and Disabled (Continued)
Layer 2/3 Virtualization Enabled Layer 2/3 Virtualization Disabled
Resource Private Partition Shared Partition Private Partition Shared Partition
IP addresses Same subnet Same subnet with Same subnets not Same subnets not
allowed in different regard to different allowed in different allowed in shared
partitions partitions allowed private partition partition
A tagged port can in shared partition A tagged port is not A tagged port is not
have same subnet A tagged port can allowed to have allowed to have
across different par- have same subnet as same subnets even same subnets even
titions under differ- other partitions but with different with different
ent VLANs with different VLAN IDs VLAN IDs in
Note: Duplicate IP VLAN ID shared partition
addresses are sup-
ported in L3V parti-
tions. In this case,
both partitions can
have same IP
address but must be
on separate VE
interfaces.
ACLs Supported Supported Not supported Supported
NAT pools Same NAT pools Same NAT pools Same NAT pools Same NAT pools
allowed across allowed in shared not allowed not allowed
different partitions partition
Static routing Supported Supported Not supported Supported
Dynamic routing Supported Supported Not supported Supported
VIPs VIPs with same VIPs with same VIPs with same VIPs with same
name or same sub- name or same sub- name or same sub- name or same sub-
net not allowed in net not allowed in net not allowed in net not allowed in
different partitions different partitions different partitions different partitions
VIPs from other VIPs from shared
partitions allowed partition can be
used by any other
partition
Real servers Servers with same Servers with same Servers with same Servers with same
name or same IP name or same IP name or same sub- name or same sub-
address allowed in address allowed in net not allowed in net not allowed in
different partitions different partitions different partitions different partitions
Servers from other Servers from shared
partitions allowed partition can be
used by any other
partition

Overview
Per-partition Feature Support for Layer 2/3 Virtualization
The following features can be configured in private partitions on which

Layer 2/3 virtualization is enabled.
The CLI and GUI syntax for configuring and monitoring these features is
the same as in previous releases. Configuration of these features takes effect
in the partition where the configuration is performed.
Note: This enhancement applies only to partitions in which Layer 2/3 virtualiza-
tion is enabled. If Layer 2/3 virtualization is disabled, these features can
not be configured within the partition.
Features that can be configured at the global configuration level

within a private partition:
• Hardware-based SYN cookies
• BGP instances per private partition
• Disable of Layer 3 forwarding between VLANs
• Source-IP connection-rate limiting
• DNS caching
• ICMP rate limiting
• Session filtering
• Global SLB options:

• SLB peak-connection statistics (extended-stats)
• SLB graceful shutdown
• Default compression block size for SLB
• Transparent TCP template
• Source NAT gateway for Layer 3
• Source NAT on VIP
• Reset stale session
• Application templates:
• TCP
• Source-IP persistence
• Destination-IP persistence
(Also see “Per-partition Default SLB Templates for Layer 2/3 Virtu-
alization” on page 235.)

Overview
Features that can be configured at the interface configuration
level within a private partition:
• IPv6 router advertisement and discovery
Per-partition Default SLB Templates for Layer 2/3 Virtualization
Layer 2/3 Virtualization supports partition-specific default server and port

templates.
By default, after creating an L3V partition, (if desired) change these

default templates without affecting the shared partition:
• Real server
• Real port
• Virtual server
• Virtual port
Changes to a default server or port template in a private partition do not

affect the default server or port templates in the shared partition or any other
private partition. Likewise, changes to a default server or port template in
the shared partition do not affect the default server or port templates in pri-
vate partitions.
Note: This behavior applies only to partitions on which Layer 2/3 virtualization
is enabled. This behavior does not apply to feature templates such as
HTTP, TCP, or source-IP persistence templates.
This behavior is available only if access to the shared partition by private
partition admins is disabled. This access is enabled by default. (See “Con-
figuration Examples” on page 239.)
Limitations
Firewall Load Balancing (FWLB) is not supported in individual private par-

titions. This feature can be configured only in the shared partition.
Link Load Balancing (LLB) is supported in private partitions only if the

feature is configured using a wildcard VIP.

L3V Partition Configuration

To configure an RBA or L3V private partitions, log in using an admin
account with Read Write privileges, and perform the steps described in
“Role Based Administration Private Partition” on page 219 and “Layer 3
Virtualization of Private Partitions” on page 227:
1. Configure partitions.
2. Configure admin accounts and assign them to partitions.
3. Configure any SLB shared resources that you want to make available to
multiple private partitions. (For information about configuring SLB
resources, see the SLB configuration chapters in this guide.)
Configuration of SLB resources within a private partition can be per-

formed by an admin with Partition-write privileges who is assigned to
the partition. For details on administrative roles and privileges, refer to
“Application Delivery Partitions” on page 193.
4. Configure network and system connectivity resources such as inter-

faces, VLANs, routing, and so on for L3V partitions. You also will need
to configure any additional admin accounts for the partition. (Note that
for RBA you would not go through the step of configuring network and
system connectivity.)
Note: This document shows how to set up partitions and assign admins to them.
The partition admins will be able to configure their own SLB, network,
and system resources.
5. Configure resource usage templates to prevent one resource starvation

amongst partitions.
Creating Private Partitions
To create a private partition, use either of the following methods.
USING THE GUI

3. Click Add. The Partition section appears.
4. Enter a name for the network partition. (This is similar to the partition
name network-partition ID CLI command).

FIGURE 34 Config Mode > System > Admin > Partition
5. Enable the Network Partition button.
6. To upload a logo for the partition, click Browse and navigate to the logo
file.
7. If a partition logo is not uploaded, the A10 Networks logo is used by

default.
8. Click OK. The new partition appears in the partition list.
FIGURE 35 Config Mode > System > Admin > Partition - List
USING THE CLI
To configure a private partition, use the following command at the global

[no] partition partition-name

[[max-aflex-file num [network-partition]] id num]
The partition-name can be 1-14 characters.

The max-aflex-file option specifies the maximum number of aFleX policies
the partition can have. You can specify 1-128. The default is 32.
The network-partition option enables Layer 2/3 virtualization, which

allows the partition to have its own network resources, separate from the
shared partition and other private partitions.
The id option assigns an ID to the partition. The partition ID ensures that a

partition’s configuration remains consistent across devices in multi-device
deployments (HA, VRRP-A, aVCS). The partition ID can be 1-128. The
ACOS device does not automatically assign an ID.
Note: In show partition output, the ID is listed in the Index column. The Index
column also lists potential IDs for partitions to which IDs have not been
assigned. However, these potential IDs do not appear in the configuration
(running-config or startup-config). Information on user-created private
RBA or L3V partitions will also be displayed.
USING THE CLI

Use the following steps to create an L3V partition;
1. Create an L3V partition:
partition partition-name network-partition
2. Create the admin role:

admin admin-partition-name password test
3. Assign privileges for that role and identify if the admin can write to the
axapi, web, or CLI:
privilege partition-write partition-name
access axapi web cli
4. Now that the admin has been successfully created, login to the partition
using the admin account:
login as: admin-partition-name
5. Configure the desired network and system resources:

a. Configure a VLAN and its interfaces:
Note: The vlan-id must match the ve-id.
vlan vlan-id
tagged interface-type interface-number
router-interface ve ve-id

b. Configure the VEs:
interface ve ve-id
ip address ipv6-address
c. Configure a server and the real server port:
slb server real-server server-ip-address
port port-number port-type
Note: UDP or TCP are the only available options.

d. Configure a service-group and its members:
slb service-group service-group-name-port-num
port-type
member service-group-name:port-type
e. Configure a VIP, its port, and the service group:
slb virtual-server vip1 vip-ip-address
port port-num port-type
service-group service-group-name:port-type
6. View your running configuration using the show running. Since you
have created an L3V partition, you can see and configure Layer 3 net-
work resources, such as VLANs, VEs, and IP Addresses.
Example 1: Simple L3V Partition Configuration
The following example shows how to create an L3V partition:

1. Create an L3V partition:
AX3400(config)#partition l3v1 network-partition
2. Create the admin and assign privileges:

AX3400(config)#admin admin-l3v1 password test
(config-admin:admin-rba1)#privilege partition-write l3v1
Modify Admin User successful!
AX3400(config-admin:admin-l3v1)#access axapi web cli
AX3400(config-admin:admin-l3v1)#exit

3. Now that the admin has been successfully created, login the partition
using admin account:
login as: admin-l3v1
Password:
Last login: Thu Aug 30 19:47:08 2012 from 192.168.33.157
ACOS system is ready now.
[type ? for help]
AX3400-Active[l3v1]>enable
Password:
AX3400-Active[l3v1]#config
AX3400-Active[l3v1](config)#
4. Configure the desired network and system resources:

For details, refer to “Resource Templates for L3V Partitions” on
page 247.
a. Configure a VLAN:
AX3400-Active[l3v1](config)#vlan 50
AX3400-Active[l3v1](config-vlan:50)#tagged ethernet 1
AX3400-Active[l3v1](config-vlan:60)#router-interface ve 50
AX3400-Active[l3v1](config)#vlan 60
AX3400-Active[l3v1](config-vlan:60)#tagged ethernet 1
AX3400-Active[l3v1](config-vlan:60)#router-interface ve 60
b. Configure VEs:
AX3400-Active[l3v1](config)#interface ve 50
AX3400-Active[l3v1](config-if:ve50)#ip address 50.50.50.1 /24
AX3400-Active[l3v1](config)#interface ve 60
AX3400-Active[l3v1](config-if:ve60)#ip address 60.60.60.1 /24
AX3400-Active[l3v1](config-if:ve60)#exit
c. Configure a server:
AX3400-Active[l3v1](config)#slb server s1-l3v 60.60.60.20
AX3400-Active[l3v1](config-real server)#port 80 tcp
AX3400-Active[l3v1](config-real server-node port)#exit
d. Configure a service-group:
AX3400-Active[l3v1](config)#slb service-group s1-80 tcp
AX3400-Active[l3v1](config-slb svc group)#member s1-l3v:80

e. Configure a VIP:
AX3400-Active[l3v1](config)#slb virtual-server vip1 50.50.50.15
AX3400-Active[l3v1](config-slb vserver)#port 80 tcp
AX3400-Active[l3v1](config-slb vserver-vport)#service-group s1-80
AX3400-Active[l3v1](config-slb vserver-vport)#exit
AX3400-Active[l3v1](config-slb vserver)#exit
5. View your running configuration. Since you have created an L3V parti-
tion, you can see and configure Layer 3 network resources, such as
VLANs, VEs, and IP Addresses:
AX3400-Active[l3v1](config)#show running
!Current configuration: 596 bytes
!
!Configuration last updated at 20:03:00 PDT Thu Aug 30 2012
!
active-partition l3v1
vlan 50
tagged ethernet 1
!
vlan 60
tagged ethernet 1
!
!
mtu 9216
!
interface ve 50
ip address 50.50.50.1 255.255.255.0
!
interface ve 60
ip address 60.60.60.1 255.255.255.0
!
slb server s1-l3v 60.60.60.20
port 80 tcp
!
slb service-group s1-80 tcp

member s1-l3v:80
!
slb virtual-server vip1 50.50.50.15
port 80 tcp
name _50.50.50.15_TCP_80
service-group s1-80
Example 2: Enabling Layer2/3 Virtualization

The following commands log onto the CLI with Read Write admin access,
and enable Layer 2/3 virtualization for partitions dmz1 and dmz2:
login as: admin
Welcome to ACOS
Password:***
[type ? for help]
ACOS>enable
ACOS#configure
ACOS(config)#partition dmz1 network-partition id 3
ACOS(config)#partition dmz2 network-partition id 4
The following commands configure an admin account for each partition:

ACOS(config)#admin dmz1admin password dmz1pwd
ACOS(config-admin:dmz1admin)#privilege partition-write dmz1
ACOS(config-admin:dmz1admin)#exit
ACOS(config)#admin dmz2admin password dmz2pwd
ACOS(config-admin:dmz2admin)#privilege partition-write dmz2
ACOS(config-admin:dmz2admin)#exit
Example 3: Configuring Partition-Specific Layer 2/3 Resources

The following commands log onto the CLI and access partition dmz1:
login as: admin-dmz1
Welcome to ACOS
Password:***
[type ? for help]
ACOS[dmz1]>enable
ACOS[dmz1]#configure
ACOS[dmz1](config)#

The following commands configure Layer 2/3 resources for the partition:
ACOS[dmz1](config)#vlan 100
ACOS[dmz1](config-vlan:100)#tagged ethernet 1
ACOS[dmz1](config-vlan:100)#untagged ethernet 2
ACOS[dmz1](config-vlan:100)#router-interface ve 100
ACOS[dmz1](config-vlan:100)#exit
ACOS[dmz1](config)#interface ve 100
ACOS[dmz1](config-if:ve100)#ip address 20.20.1.1 255.255.255.0
ACOS[dmz1](config-if:ve100)#exit
ACOS[dmz1](config)#ip route 0.0.0.0 /0 20.20.101.50
The following command saves the configuration.

ACOS[dmz1](config)#write memory
Building configuration...
[OK]
The following commands log onto the CLI and access partition dmz2:
Welcome to ACOS
Password:***
[type ? for help]
ACOS[dmz2]>enable
ACOS[dmz2]#configure
ACOS[dmz2](config)#
The following command displays the list of Ethernet interfaces. The inter-
faces that belong exclusively to partition dmz1 are not included. Interface 1
is listed, since it is a tagged member of dmz1’s VLAN. However, interface 2
is not listed, since it is an untagged member of dmz1’s VLAN. Likewise,
dmz1’s VE is not listed.
ACOS[dmz2]#show interfaces brief
Port Link Dupl Speed Trunk Vlan MAC IP Address IPs Name
------------------------------------------------------------------------------------
mgmt Up Full 100 N/A N/A 001f.a001.d020 192.168.20.10/24 1
1 Up Full 1000 N/A Tag 001f.a002.0870 0.0.0.0/0 0
3 Disb None None None 1 001f.a002.0872 0.0.0.0/0 0
9 Disb None None None 1 001f.a002.78ec 0.0.0.0/0 0

10 Disb None None None 1 001f.a002.78ed 0.0.0.0/0 0
11 Disb None None None 1 001f.a002.78ee 0.0.0.0/0 0
12 Disb None None None 1 001f.a002.78ef 0.0.0.0/0 0
The following commands configure Layer 2/3 resources for partition dmz2,
and list the interfaces:
ACOS[dmz2](config)#vlan 200
ACOS[dmz2](config-vlan:200)#tagged ethernet 1
ACOS[dmz2](config-vlan:200)#untagged ethernet 3
ACOS[dmz2](config-vlan:200)#router-interface ve 200
ACOS[dmz2](config-vlan:200)#exit
ACOS[dmz2](config)#interface ve 200
ACOS[dmz2](config-if:ve200)#ip address 20.20.2.1 255.255.255.0
ACOS[dmz2](config-if:ve200)#exit
ACOS[dmz2](config)#ip route 0.0.0.0 /0 20.20.102.50
------------------------------------------------------------------------------------
1 Up Full 1000 N/A Tag 001f.a002.0870 0.0.0.0/0 0
3 Up Full 1000 None 200 001f.a002.0871 0.0.0.0/0 0
ve1 Up N/A N/A N/A 200 001f.a002.0870 20.20.2.1/24 1
The following command saves the configuration.

ACOS[dmz2](config)#write memory
[OK]
The following commands again log onto the CLI and access partition dmz1,
and display the list of Ethernet interfaces. Ethernet 3 is not listed since it
now belongs exclusively to partition dmz2.
Welcome to ACOS
Password:***

[type ? for help]
ACOS[dmz1]>enable
------------------------------------------------------------------------------------
1 Up Full 1000 N/A Tag 001f.a002.0870 0.0.0.0/0 0
2 Up Full 1000 None 100 001f.a002.0871 0.0.0.0/0 0
ve1 Up N/A N/A N/A 100 001f.a002.0870 20.20.1.1/24 1
The following commands log onto the CLI with Read Write admin access,
and display the list of Ethernet interfaces in the shared partition. All physi-
cal Ethernet interfaces are listed, including those belonging to individual
partitions. The VEs belonging to other partitions are not listed.
login as: admin
Welcome to ACOS
Password:***
[type ? for help]
ACOS>enable
ACOS#show interfaces brief
------------------------------------------------------------------------------------
1 Up Full 1000 None Tag 001f.a002.0870 0.0.0.0/0 0
2 Up Full 1000 None 100 001f.a002.0871 0.0.0.0/0 0
3 Up Full 1000 None 200 001f.a002.0872 0.0.0.0/0 0


Overview
Resource Templates for L3V Partitions
Overview
Resource templates help you to define limits for application, network, and
system resources in partitions enabled for Layer 2/3 virtualization. Once
defined, you can bind or unbind a resource template to a particular partition.
You can also apply a sample template to multiple partitions. By default,
Layer 2/3 partitions have the same resource limits as the shared partition.
Note: If the maximum number of real servers you specify is configured (no
additional real servers can be configured), the ACOS device does not
allow any additional GSLB service-IPs to be configured.
The current release allows you to ration resources to Layer 2/3 partitions.
For example, you can specify the number of real servers a partition can
access.
By configuring resource limits for individual Layer 2/3 partitions, you can
ensure that no partition starves another partition of resources by monopoliz-
ing the available system resource quotas.
Resource Template Parameters

You can configure the following types of resource templates for Layer 2/3
partitions:
• Application Resources – Contains configuration parameters for applica-
tion resources such as the number of health monitors, real servers, ser-
vice groups, virtual servers, as well as a number of GSLB parameters,
such as GSLB devices, GSLB sites, and GSLB zones.*
• Network Resources – Contains configuration parameters for available
network resources such as static ARPs, static IPv4 routes, static IPv6
routes, MAC addresses, and static neighbors.
• System Resources – Contains configuration parameters for system
resources such as limits for bandwidth, concurrent sessions, Layer 4
Connections Per Second (CPS), Layer 7 CPS, NAT CPS, SSL through-
put, and SSL CPS.
*.
GSLB parameters are configurable on a per-partition basis hard-coded (and thus non-con-
figurable) at the system level.

Overview
Note: The valid ranges and defaults for resource-usage parameters differ
depending on ACOS device model. To view this information, enter the
following command at the configuration level of the CLI:
show system resource-usage
Application Resource Parameters
At the template configuration level, set the application resource parameters

discussed in Table 13.
TABLE 13 Application Resource Usage Template Parameters

GUI Parameter CLI Parameter Description
Virtual Server virtual-server-count Enter the number of virtual-servers allowed.
Service Group service-group-count Enter the number of service groups allowed.
Server real-server-count Enter the number of real-servers allowed.
Health Monitor health-monitor-count Enter the number of health monitor checks a
server uses.
GSLB Device gslb-device-count Enter the number of GSLB devices allowed.
GSLB Geo-location gslb-geo-location-count Enter the number of GSLB geo-locations
allowed.
GSLB IP List gslb-ip-list-count Enter the number of GSLB IP lists allowed.
GSLB Policy gslb-policy-count Enter the number of GSLB policies allowed.
GSLB Service gslb-service-count Enter the number of GSLB services allowed.
GSLB Service IP gslb-service-ip-count Enter the number of GSLB service IPs allowed.
GSLB Service Port gslb-service-port-count Enter the number of GSLB service-ports allowed.
GSLB Site gslb-site-count Enter the number of GSLB sites allowed.
GSLB Template gslb-template-count Enter the number of GSLB templates allowed.
GSLB Zone gslb-zone-count Enter the number of GSLB zones allowed.
Network Resource Parameters
At the template configuration level, set the network resource parameters

discussed in Table 14.
TABLE 14 Network Resource Usage Template Parameters

Static MAC static-mac-count Enter the number of static MAC addresses
allowed.
Static ARP static-arp-count Enter the number of static IPv4 ARPs or IPv6
neighbors allowed.
Static Neighbor static-neighbor-count Enter the number of static neighbors allowed.
Static IPv4 Route static-ipv4-route-count Enter the number of static IPv4 routes allowed.
Static IPv6 Route static-ipv6-route-count Enter the number of static IPv6 routes allowed.

Overview
System Resource Parameters

At the template configuration level, set the system resource parameters dis-
cussed in Table 15.
TABLE 15 System Resource Usage Template Parameters

Bandwidth bw-limit Enter the bandwidth limit in Mbps. Right after you
indicate a bandwidth limit in Mbps, optionally, dis-
able a watermark using a watermark-disable
keyword. A watermark is enabled by default. This
means that when the bandwidth approaches the 90%
mark, existing sessions will be maintained, but any
new sessions will be dropped. Indicating the
watermark-disable keyword will turn off the
watermark option and result in accepting new con-
nections until 100% of the bandwidth in that second
is utilized.
Concurrent Session concurrent-session- Enter the concurrent session limit. Configure a con-
limit current session limit when you have no active ses-
sions running on the ACOS device. If you indicate
the concurrent session limit when there are active
sessions (on the L3V partition where you are config-
uring a resource template), your concurrent session
limit configuration will also take into account the
number of active sessions. This situation will result
in more concurrent sessions than configured. For
example, if you have 50 active sessions on your L3V
partition, and you configure a concurrent session
limit of 100 sessions, your ACOS device will allow
150 concurrent sessions as opposed to the configured
100 concurrent sessions in your L3V partition.
L4 CPS l4cps-limit Enter the Layer 4 CPS limit.
L7 CPS l7cps-limit Enter the Layer 7 CPS limit.
NAT CPS natcps-limit Enter the NAT CPS limit.
SSL CPS sslcps-limit Enter the SSL CPS limit.
SSL Throughput ssl-throughput-limit Enter the SSL throughput limit in Mbps. Right after
you indicate a bandwidth limit in Mbps, optionally,
disable a watermark using a watermark-dis-
able keyword. A watermark is enabled by default.
This means that when the bandwidth approaches the
90% mark, existing sessions will be maintained, but
any new sessions will be dropped. Indicating the
watermark-disable keyword will turn off the
watermark option and result in accepting new con-
nections until 100% of the bandwidth in that second
is utilized.

Overview
USING THE GUI
To create a System Resource Template:

1. Select Config Mode > System > Settings > General > Resource Usage >
Template.
2. Click Add.
Note: You may also access this page from Config Mode > System >
Admin > Partition. Select the System Resource Template checkbox, and
click ‘create ...’ from the drop-down menu.
3. In the name field, specify the name that will uniquely identify the tem-
plate.
4. Configure the application, network, and system resource options. (See

Table 13 on page 248, Table 14 on page 248, and Table 15 on page 249.)
5. Click OK.
To delete a System Resource Template:

1. Unbind the template from network partitions. See “Removing a
Resource Template from a Partition” on page 256.
2. Select Config Mode > System > Settings > General > Resource Usage >
Template.
3. This page displays a table of existing system resource templates. Select

the checkbox of one or more system resource templates to delete.
4. Click Delete.
USING THE CLI
The system resource limits that you configure in a default template are
applied to all partitions, unless you explicitly apply a custom template
(where you may choose to change some default values) to a partition. Create
a custom template to modify the limits for any application, network, or sys-
tem resources from their default values.

Overview
The following steps will help you create, use, or remove a custom resource
template:
1. To modify the default template, specify default. To create or modify a
custom template instead, specify a unique name other than “default”.
2. Within the template, specify the application, network, and system

parameters you want to define from the appropriate sub-level.
3. To use your custom template, apply the template to a particular parti-

tion.
Note: Though partitions need to bound to a template one at a time, several parti-
tions may be bound to the same custom template.
4. Unbind a template to revert to the default values for resources per parti-
tion. This step assumes that you have created a default template.
Creating a System Resource Template

Use the following command to create a custom resource template, where
template-name refers to a unique name you assign to the template:
[no] system resource-usage template
{default | template-name}
To view your customized template containing the values for application,

network, and system resources, use the following command:
show system resource-usage template
Note: If no custom template is created, if you have created a default template

with the values for all resources, those values will be applied to all parti-
tions unless a partition is already bound to another custom template.
Create a resource template using the following command:

AX(config)#system resource-usage template ru-tmplt

Overview
Assigning Resource Limits
From the template configuration mode, you can modify any application,
network, or system resource limits.
Application Resources
Use the following command to enter the application resource limit
configuration mode:
app-resources
Configuring application resource parameters allows you to assign values for

parameters listed in Table 13 on page 248:
AX(config-resource template)#app-resources
AX(config-resource template-app)#
The following example shows you how to enter the application resources
configuration mode. From this location, you can set values for the available
application resources:
AX(config-resource template)#app-resources
AX(config-resource template-node app)#gslb-zone-count 10
AX(config-resource template-node app)#health-monitor-count 50
AX(config-resource template-node app)#real-server-count 100
AX(config-resource template-node app)#service-group-count 150
AX(config-resource template-node app)#virtual-server-count 250
Use the show running command to verify the configured application

resource values:
AX(config-resource template-node app)#show running
...
system resource-usage template ru-tmplt
app-resources
gslb-zone-count 10
real-server-count 100
service-group-count 150
virtual-server-count 250
health-monitor-count 50

Overview
Network Resources
Use the following command to enter the network resource limit
configuration mode:
network-resources
Configuring network resource parameters allows you to assign values for

AX(config-resource template)#network-resources
The following example shows you how to enter the network resources
network resources:
AX(config-resource template)#network-resources
AX(config-resource template-node network)#static-arp-count 100
AX(config-resource template-node network)#static-ipv4-route-count 1000
AX(config-resource template-node network)#static-ipv6-route-count 2000
AX(config-resource template-node network)#static-mac-count 200
AX(config-resource template-node network)#static-neighbor-count 128
Use the show running command to verify the configured network resource
values:
AX(config-resource template-node network)#show running
...
network-resources
static-mac-count 200
static-arp-count 100
static-ipv4-route-count 1000
static-ipv6-route-count 2000
static-neighbor-count 128
System Resources
Use the following command to enter the system resource limit configuration
mode:
system-resources
Configuring system resource parameters allows you to assign values for

Overview
The following example shows you how to enter the system resources
system resources. Note that the watermark-disable optional keyword is
used to disable the automatically-enabled watermark. However, the optional
keyword, though available, is not used with the SSL throughput limit
resource:
AX(config-resource template)#system-resources
AX(config-resource template-node system)#bw-limit 500 watermark-disable
AX(config-resource template-node system)#concurrent-session-limit 3200
AX(config-resource template-node system)#l4cps-limit 2000
AX(config-resource template-node system)#l7cps-limit 4000
AX(config-resource template-node system)#natcps-limit 100000
AX(config-resource template-node system)#ssl-throughput-limit 1000
AX(config-resource template-node system)#sslcps-limit 10000
Use the show running command to verify the configured network resource
values:
AX(config-resource template-node system)#show running
...
system-resources
bw-limit 500
ssl-throughput-limit 1000
l4cps-limit 2000
natcps-limit 100000
l7cps-limit 4000
sslcps-limit 10000
concurrent-session-limit 3200
Applying a System Resource Template to a Partition

If you create a custom system template, the template takes effect only after
you attach it to a partition. Attach the template to any partition to override
the parameter values specified in the existing default template (if you have
created one).
Note: The values from the default resource template will be automatically
applied to any partition that is not bound to a custom system template.
Though partitions need to bound to a template one at a time, several parti-
tions may be bound to the same custom template.

Overview
USING THE GUI
To apply a system resource template to a partition:

1. Navigate to Config Mode > System > Admin > Partition.
2. The table of this page displays existing network partitions. From here,
click the name of a partition to access the configuration page.
3. Select the System Resource Template checkbox to display a drop-down

list of system resource templates.
4. Select an existing template to apply, or ‘create ...’ to be directed to the

template configuration page. For information about configuration
parameters, see “Creating a System Resource Template” on page 251.
5. Click OK.
USING THE CLI
Enter the following command at the configuration level for the partition:
[no] template template-name
A template can be applied to a partition. The software will automatically

check for the existence of the partition and template before the template is
successfully attached to a partition.
CLI Example
Use the following commands to apply a template to a partition. In this
example, the template called “ru-tmplt” is being applied to a partition called
“p55”:
AX(config)#partition p55 network-partition
AX(config-partition)#template ru-tmplt

Overview
To verify that your template is applied to the partition called “p55”, use the
show running command:
AX(config-partition)#show running
...
partition p55 network-partition
template ru-tmplt
Removing a Resource Template from a Partition

To remove a link to a custom template from an existing partition, from the
partition configuration level, issue the no form of the template command
CLI Example
To stop applying a template to a particular partition, issue the following

commands, where “p55” refers to the name of the partition and “ru-tmplt”
refers to the name of the custom template:
AX(config-partition)#partition p55 network-partition
AX(config-partition)#no template ru-tmplt
When the custom template is removed from a partition, the default template
values (from the default template that you have created) will be applied to
the partition.
USING THE GUI

To unbind a System Resource Template:
1. Navigate to Config Mode > System > Admin > Partition.
2. This page displays a table of existing network partitions. Select an

enabled partition from which to remove the system resource template.
3. Deselect the System Resource Template checkbox.

Overview
4. Click OK.
Contradictory Resource Usage Scenario

Configuration of resource usages may fail in the event of contradictory
resource limit conditions. Some scenarios are outlined below:
1. When attempting to bind a template to a partition, the software checks
to see if the resources currently configured in the partition are within the
new limits defined in the template, before it is bound to that partition.
For example, if you have a partition called “p1” with 20 real servers,
and a template called “t1” that has a limit of 10 real servers, when you
attempt to bind template “t1” to partition “p1,” an error claiming that
this is an invalid configuration will be displayed.
2. When a particular resource limit is changed for a template which is

already bound to a partition, the software performs a check for a contra-
dictory configuration scenario before the change is allowed. In this case,
if template “t1” has a limit of 10 real servers and is bound to a partition
“p1” with 8 real servers (which is within limits), when you attempt to
change the limit in template “t1” to 5 real servers, you will not be
allowed to do so because it contradicts the current configuration.
3. When a default template is defined, it gets applied to all the partitions

that are not bound to a custom template. However, before the software
assigns any values in the default template, it checks to make sure that
the values in default template do not contradict any existing partition
resource limits.
4. When you unbind a template from a partition, if a default template is

configured, it gets applied to the partition. Before this happens, the soft-
ware again checks for contradictory resource limits prior to unbinding
the template.

Overview

Inter-Partition Routing
In ACOS 2.7.1, you can configure static routes directly between a private
partition and the shared partition. This capability is meaningful in case you
use Advanced Delivery Partitions (ADPs) to lease different partitions to
various customers. Traffic can now be routed from the shared partition to
the VIP configured in a private partition and vice versa.
Prior to ACOS 2.7.1, to route traffic from one partition to another traffic,
traffic had to be sent out of the device to an external router, which then for-
warded the traffic to the destination partition of the devices. In addition, par-
tition-awareness was accomplished by using VLAN tags only.
Note: Inter-partition routing is only provided for IPv4 addresses. Also, hair pin-
ning across private partitions is not supported.
Reasons for enabling inter-partition routing capabilities:

• To allow traffic to be redirected upstream from a private partition.
• To allow the shared partition to route traffic downstream to the real serv-
ers via the private partitions.
• To allow incoming traffic destined for a private partition with SLB
information to bypass the shared partition (since it does not contain SLB
configuration) and to be redirected to the private partition that is speci-
fied.
• To provide multiple private partitions, containing independent routing
tables, with the ability to look up routing entries in the shared partition’s
routing table (by treating the shared partition as the next hop within the
device.)
• To operate in conjunction with VRRP-A for route lookups in the For-
warding Information Base (FIB) tables.
This feature can be enabled successfully to route traffic between the shared
and private partitions provided the following requirements are met:
• Inter-partition routing is only provided for IPv4 addresses. Currently, no
IPv6 address support is provided.
• Private partitions do not have duplicate IP Addresses across all parti-
tions. If duplicate addresses are discovered, they will not be logged.
• If there are any overlapping real servers across partitions, NAT must be
configured.

• Traffic must be received on the physical ingress port in the shared parti-
tion only.
• Static routes can forward traffic from the shared partition to VIP in a pri-
vate partition.
Note: Hairpinning across private partitions is not supported.
Configuration
The current release supports use of the CLI to configure this feature.
USING THE CLI
To configure the feature, you will need to do the following:

1. Enable the support on the ingress Ethernet data port that will receive the
traffic addressed to the VIP in the private partition:
[no] ip slb-partition-redirect
2. Add static route, whose destination is the network address configured in

the private partition:
[no] ip route network-address partition partition-name
3. Change to the CLI session to the private partition, and configure a static
default route back to the shared partition:
active-partition partition-name
[no] ip route 0.0.0.0 /24 partition shared
Note: You can use a specific IP address as the destination if preferred.
ACOS(config-if:ethernet4)#ip slb-partition-redirect
ACOS(config-if:ethernet4)#exit
ACOS(config)#ip route 10.2.4.0 /24 partition p69
ACOS(config)#active-partition p69
ACOS(config)#ip route 0.0.0.0 /24 partition shared

Configuration in the Shared Partition
To enable inter-partition routing capabilities, there are two tasks that must
be configured in the shared partition:
• Configure the specific route to the downstream real server via a private
partition or to the VIPs in the private partition.
• Optionally, If you wish to enable forwarding of pass through (non-SLB)
traffic, configure the ability to redirect traffic arriving on an incoming
interface to be redirected to a private partition, bypassing the shared par-
tition.
Specific Route/VIPs—Shared Partition to Private Partition

Configured on the shared partition at the interface configuration level, the ip
route command helps configure the specific route that will be used by the
shared partition to communicate to the real server via a private partition or
to the VIP in a private partition.
Packets destined for the downstream real server will be forwarded using this
route:
[no] ip route network-address

partition partition-name
The options indicate the following:
network-address—The address to which the real server or VIP belong.
partition-name—Unique name of the partition.
To verify that your configuration is valid, use either the show ip route
or the show ip fib command.
In the following example, the default route to reach the real server
(10.15.0.0) from the shared partition will traverse via a partition (in this
example, partition a). Packets destined for the downstream real server will
be directed using this route:
AX(config)#ip route 10.15.0.0 /24 partition a

Verify your configuration using the show ip route command. In this output,
you can see that the real server 10.15.0.0/24 is accessible via partition a:
ax1(config)#show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
C 1.1.1.1/32 is directly connected, loopback 1

S 10.15.0.0/24 [1/0] via partition a
C 219.247.8.0/24 is directly connected, ethernet 8
You can also verify your configuration using the show ip fib command. In
this command, you see that partition a is the nexthop to the network
address to which the VIP belongs, 10.15.0.0.
ax1(config)#show ip fib
Prefix Next Hop Interface Distance
------------------------------------------------------------------------
1.1.1.1 /32 0.0.0.0 loopback1 0
10.15.0.0 /24 partition a loopback1 0
219.247.8.0 /24 0.0.0.0 ethernet8 0
Total Routes = 3
IP SLB Partition Redirect Configuration

The ip slb-partition-redirect command is issued in the shared partition at
the interface configuration level for traffic on the specified incoming inter-
face. This traffic will be successfully redirected to the specified private par-
tition that will process the packets. This command is meaningful for
downstream routing of traffic:
[no] ip slb-partition-redirect
The configuration is applied to the specified physical interface, virtual inter-

face, or trunk at the interface configuration level.

In the following example, the ip slb-partition-redirect command will
apply to the virtual interface (ve 21) in the shared partition. The IP Address
10.11.0.1 /24 indicates the IP Address of the incoming virtual interface.
ax1(config)#interface ve 21
ax1(config-if:ve21)#ip address 10.11.0.1 /24
ax1(config-if:ve21)#ip slb-partition-redirect
Verify your virtual interface configuration to see if you have successfully

redirected traffic destined for the specified incoming interface downstream:
ax1#show running interface ve 21
interface ve 21
ip address 10.11.0.1 255.255.255.0
ip slb-partition-redirect
Configuration in the Private Partition
To enable inter-partition routing capabilities, there is one mandatory task

and another optional ones that must be configured in the private partition:
• Configure the static default route to the shared partition.
• Optionally, configure SLB in the private partition, if you have not

already done so.
Note: The current release does not provide support for outbound source NAT for
pass through traffic.
Default Route—Private Partition to the Shared Partition

Configured on the private partition at the interface configuration level, the
ip route command helps configure the static route that will be used by the
private partition to communicate with the shared partition.
Change the CLI session to the private partition, and configure a static
default route back to the shared partition:
active-partition partition-name
[no] ip route network-

address partition partition-name
The options represent the following:
network-address—Specify the network address to reach outside of the

network (typically the default route is configured)..

partition-name—In this case, specify the shared partition.

Packets destined upstream from the private partition will use the configured
static route and will be sent out the specified outgoing interface:
Ensure that you have SLB running and VIPs configured in your private par-
tition before you configure a static route to the VIP. Configure the default
route to the shared partition from the private partition:
ax1[a](config)#ip route 0.0.0.0 /0 partition shared
Verify your configuration using the show ip route command. Look at the
route that shows that 0.0.0.0/0 is accessible via partition shared:
ax1[a](config)#show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
Gateway of last resort is 127.1.0.0 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via partition shared

C 10.15.0.0/24 is directly connected, ve 22
Verify your configuration using the show ip fib command:

ax1[a](config)#show ip fib
Prefix Next Hop Interface Distance
------------------------------------------------------------------------
0.0.0.0 /0 partition shared loopback1 0
10.15.0.0 /24 0.0.0.0 ve 22 0
Total Routes = 2
Verify your virtual interface configuration on ve22:

ax1[a](config)#show running interface ve 22
interface ve 22
ip address 10.15.0.1 255.255.255.0

SLB configuration within a Private Partition
Optionally, if you do not have SLB configured in your private partition,

here are straightforward steps to configure SLB in a private partition:
To configure SLB in your private partition, use the following commands,

configure the server, the associated port and protocol, the SLB service
group, and the members of the group, the SLB virtual server, the associated
port and protocol, the IP Address of the VIP, and service group for the vir-
tual server.
ax1[a](config)#slb server abc 10.15.0.15
ax1[a](config-real server)#port 80 tcp
ax1[a](config-real server-node port)#slb service-group abc tcp
ax1[a](config-slb svc group)#member abc:80
ax1[a](config-slb svc group)#slb virtual-server v1 10.15.0.101
ax1[a](config-slb vserver)#port 80 http
ax1[a](config-slb vserver-vport)#service-group abc
ax1[a](config-slb vserver-vport)#slb virtual-server v2 10.15.0.102
ax1[a](config-slb vserver)#port 80 tcp
ax1[a](config-slb vserver-vport)# service-group abc
Verify your private partition SLB configuration using the show running
command and display the SLB configuration section:
ax1[a](config)#show run | sec slb
slb server abc 10.15.0.15
port 80 tcp
slb service-group abc tcp
member abc:80
slb virtual-server v1 10.15.0.101
port 80 http
service-group abc
slb virtual-server v2 10.15.0.102
port 80 tcp
service-group abc
Having configured the static route in the private partition and the shared
partition, and having configured SLB redirect capabilities on the shared
partition, the inter-partition routing feature is now functional.


Overview
High Availability
This chapter describes High Availability (HA) and how to configure it.
Note: The version of HA described in this chapter is the version that is also sup-
ported in previous releases. For information about the new HA, VRRP-A,
see “VRRP-A High Availability” on page 355.
Note: The implementation of HA described in this chapter is not supported with

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

deployments are sent in unicast packets with the unicast MAC address and uni-
cast IP address of the peer ACOS device in the HA pair. They no longer are sent
in IP multicast packets addressed to IP multicast destination MAC and IP
addresses. Like previous releases, they also are not sent as broadcasts.
This applies to all ACOS device models. This change does not require any con-
figuration changes and should not affect the operation of your HA deployment.
Overview
High Availability (HA) is an ACOS feature that provides ACOS-level
redundancy to ensure continuity of service to clients. In HA configurations,
ACOS devices are deployed in pairs. If one ACOS device in the HA pair
becomes unavailable, the other ACOS device takes over.
You can configure either of the following types of HA:

• Active-Standby – One ACOS device is the primary SLB device for all
virtual services on which HA is enabled. The other ACOS device is a
hot Standby for the virtual services.

Overview
• Active-Active – Each ACOS device is the primary SLB device for some
of the configured virtual services, and is a hot Standby for the other con-
figured virtual services.
Active-Active is supported only on ACOS devices that are deployed in

route mode. Active-Standby is supported on ACOS devices deployed in
transparent mode or route mode.
Note: In High Availability (HA) deployments, the ACOS devices must be the
same model and must be running the same software version. For example,
if one of the ACOS devices in an HA deployment is model AX 3200-11
running 2.6.1, the other device also must be model AX 3200-11 running
2.6.1. The other device in this example can not be AX 3200 or any other
model except AX 3200-11.

Overview
Layer 3 Active-Standby HA
Figure 36 shows an example of an Active-Standby configuration.
FIGURE 36 Active-Standby HA

Overview
In this example, each ACOS device provides SLB for two virtual servers,
VIP1 and VIP2.
Each ACOS device has the following HA configuration elements:

• HA ID – The HA ID of AX1 is 1 and the HA ID of AX2 is 2. Each
ACOS device in an HA deployment must have a unique HA ID. The ID
must be different on each ACOS device. The ID can be used as a tie
breaker to select the Active ACOS device. (See “How the Active ACOS
Device Is Selected” on page 288.)
• HA group – HA group 1 is configured on each ACOS device. An ACOS
device can have up to 31 HA groups.
Both VIPs on each ACOS device are members of the HA group.
Each HA group must be configured with a priority. The priority can be
used as a tie breaker to select the Active ACOS device for a VIP.
Each HA group has a shared MAC address, 021f.a0000.00xx. The 02
portion of the address indicates this is an HA virtual MAC address,
instead of a system MAC address (00). The xx portion of the address is
unique to the HA group. The shared MAC address is used for all IP
addresses for which HA is provided (SLB VIPs, source NAT addresses,
floating IP addresses, and so on).
• Session synchronization – Also called connection mirroring, session
synchronization sends information about active client sessions to the
Standby ACOS device. If a failover occurs, the client sessions are main-
tained without interruption.
(For a complete list of configurable HA parameters, see “HA Configuration

Parameters” on page 292.)
Maximum Number of Supported HA Floating IP Addresses

• For all FPGA models: 256 floating IPs
• For non-FPGA models: 64 floating IPs
• For private partitions enabled for Layer 2/3 virtualization (both FPGA
and non-FPGA models): 64 floating IPs

Overview
Layer 3 Active-Active HA
Figure 37 shows an example of an Active-Active configuration.
FIGURE 37 Active-Active HA
In the Active-Active configuration, as in the Active-standby configuration.

only one ACOS device is active for a given VIP. But unlike the Active-
Standby configuration, the same ACOS device does not need to be the
Active ACOS device for all the VIPs. Instead, each of the ACOS devices
can be the Active ACOS device for some VIPs. In this example, AX1 is
Active for VIP2 and AX2 is Active for VIP1.

Overview
This configuration is similar to the configuration for Active-Standby shown
in Figure 36, with the following exceptions:
• Both HA groups are configured on each of the ACOS devices. In
Active-Standby, only a single HA group is configured.
• The priority values have been set so that each HA group has a higher
priority on one ACOS device than it does on the other ACOS device. In
this example, HA group 1 has a higher priority on AX2, whereas HA
group 2 has a higher priority on AX1.
• On each ACOS device, one of the VIPs is assigned to HA group 1 and
the other VIP is assigned to HA group 2.
• On both ACOS devices, HA pre-emption is enabled. HA pre-emption
enables the devices to use the HA group priority values to select the
Active and Standby ACOS device for each VIP. Without HA pre-emp-
tion, the device selection is based on which of the ACOS devices comes
up first.

Overview
Layer 2 Active-Standby HA (Inline Deployment)

ACOS devices support Layer 2 hot standby inline deployment. Inline
deployment allows you to insert a pair of ACOS devices into an existing
network without the need to reconfigure other devices in the network.
Inline support applies specifically to network topologies where inserting a

pair of ACOS switches would cause a Layer 2 loop, as shown in this exam-
ple.
FIGURE 38 Topology Supported for Layer 2 Inline HA Deployment
In this example, a pair of routers configured as a redundant pair route traffic

between clients and servers. The redundant router pair can be implemented
using Virtual Router Redundancy Protocol (VRRP-A), Extreme Standby
Router Protocol (ESRP), or another equivalent router redundancy protocol.

Overview
Each real server is connected to the router pair through a Layer 2 switch.
Neither the Layer 2 switches nor the routers are running Spanning Tree Pro-
tocol (STP). The network does not have any Layer 2 loops because the
Layer 2 switches are not connected directly together, and the routers do not
forward Layer 2 traffic.
If a pair of ACOS switches in transparent mode are added, the ACOS

switches can add redundant Layer 2 paths, which cause Layer 2 loops. To
prevent loops in this deployment, without making any configuration
changes on the other devices in the network, you can enable HA inline
mode on the ACOS devices. Inline mode automatically blocks redundant
paths through the Standby ACOS device, without the need to enable STP on
any devices.
FIGURE 39 Layer 2 Inline HA Deployment

Overview
Mandatory Connection-mirror IP Requirement for Layer 2 Inline Mode HA
ACOS devices require a connection mirror IP address to be configured in
Layer 2 inline mode HA deployments. A connection mirror interface is a
unicast IP address on the peer ACOS device in the HA pair. This peer IP
address is optional in earlier releases but usually is configured anyway for
session synchronization purposes. Beginning in AX Release 2.7.0, specify-
ing a connection mirror IP address is mandatory for proper operation of
ACOS devices in Layer 2 Inline mode HA.
The connection mirror IP address is used for session synchronization (also

called “connection mirroring”). Until a connection mirror IP address is
specified, the ACOS device remains in Standby state.
If a connection mirror IP address is not configured, a log message such as

the following is generated every 5 minutes:
Sep 01 2012 03:01:30 Warning [HA]:HA Peer IP is not configured. Peer IP is
required in Inline Mode.
Restrictions
• Supported for Active-Standby HA deployments only. Not supported for
Active-Active HA.
• Inline mode is designed for one HA group in Hot-Standby mode. Do not
configure more than one HA group on a device running in inline mode.
• In order to prevent Layer 2 loops in a Layer 2 host-standby environ-
ment, the Standby ACOS device does not forward traffic. In addition,
the Active ACOS device in the HA pair is designed to not forward pack-
ets destined for the Standby ACOS device. Depending on the network
topology, certain traffic to the Standby ACOS device might be dropped
if it must first pass through the Active ACOS device.
Preferred HA Port
When you enable inline mode on an ACOS device, the ACOS device uses a
preferred HA port for session synchronization and for management traffic
between the ACOS devices in the HA pair. For example, if you use the CLI
on one ACOS device to ping the other ACOS device, the ping packets are
sent only on the preferred HA port. Likewise, the other ACOS device sends
the ping reply only on its preferred HA port.
Management traffic between ACOS devices includes any of the following

types of traffic:
• Telnet

Overview
• SSH
• Ping
Optionally, you can designate the preferred HA port when you enable inline
mode. In Figure 39 on page 274, Ethernet interface 5 on each ACOS device
has been configured as the preferred HA port.
The ACOS device selects the Active ACOS device’s preferred HA port as
follows:
1. Is a preferred port specified with the inline configuration, and is the port
up? If so, use the port.
2. If no preferred HA port is specified in the configuration or that port is

down, the first HA interface that comes up on the ACOS device is used
as the preferred HA port.
3. If the preferred HA port selected by 1. or 2. above goes down, the HA

interface with the lowest port number is used. If that port also goes
down, the HA interface with the next-lowest port number is used, and so
on.
HA heartbeat messages are not restricted to the preferred HA port. Heart-

beat messages are sent out all HA interfaces unless you disable the mes-
sages on specific interfaces.
Note: The preferred port must be added as an HA interface and heartbeat mes-
sages must be enabled on the interface.
Port Restart
When a transition from Standby to Active occurs because the formerly

Active ACOS device becomes unavailable, the other devices that are
directly connected to the unavailable ACOS device detect that their links to
the ACOS device have gone down. The devices then flush their cached
MAC entries on the down links.
For example, in Figure 39 on page 274, while AX1 is still Active, the active
router (the one on the left) uses the MAC entries it has learned on its link
with AX1 to reach downstream devices. If the link with AX1 goes down,
the router flushes the MAC entries. The router then relearns the MAC
addresses on the link with AX2 when it becomes the Active ACOS device.
This mechanism is applicable when the link with AX1 goes down. How-
ever, if the transition from Active to Standby does not involve failure of the
router's link with AX1, the router does not flush its learned MAC entries on
the link. As a result, the router might continue to send traffic for down-

Overview
stream devices through the router's link with AX1. Since AX1 is now the
Standby, it drops the traffic, thereby causing reachability issues.
For example, if you administratively force a failover by changing the HA

configurations of the ACOS devices and enabling HA pre-emption, the link
between the router and AX1 remains up. In this case, the router continues to
have MAC addresses through this link.
To ensure that devices connected to the formerly Active ACOS device flush
their learned MAC entries on their links with AX1, you can enable HA port
restart.
HA port restart toggles a specified set of ports on the formerly Active

ACOS device by disabling the ports, waiting for a specified number of mil-
liseconds, then re-enabling the ports. Toggling the ports causes the links to
go down, which in turn causes the devices on the other ends of the links to
flush their learned MAC entries on the links. The devices then can relearn
MACs through links with the newly Active ACOS device.
Note: You must omit at least one port connecting the ACOS devices from the
restart port-list. This is so that heartbeat messages between the ACOS
devices are maintained; otherwise, flapping might occur.
Note: On model AX 2000 or AX 2100, A10 recommends that you do not

include Fiber ports in the restart port list.

Overview
Layer 3 Active-Standby HA (Inline Deployment)

Inline mode HA is also supported for ACOS devices deployed in route
mode (Layer 3).
Layer 3 HA for inline mode is beneficial in network topologies where the

ACOS device interfaces with the clients and real servers are in the same
subnet. Figure 40 shows an example.
FIGURE 40 Inline Mode for Layer 3 HA
In this example, each ACOS device has multiple Ethernet ports connected
to the clients, and multiple Ethernet ports connected to the servers. On each
ACOS device, all these Ethernet interfaces are configured as a single Virtual
Ethernet (VE) interface with a single IP address. The routers, both ACOS
devices, and the servers are all in the same subnet.

Overview
Normally, this topology would introduce a traffic loop. However, the HA
inline mode prevents loops by logically blocking through traffic on the
standby ACOS device. Spanning Tree Protocol (STP) is not required in
order to prevent loops.
A dedicated link between the ACOS devices is used for HA management

traffic. In this example, the dedicated link is in another subnet.
Comparison to Layer 2 Inline Mode

Layer 3 inline configuration is similar to Layer 2 inline mode configuration,
with the following exceptions:
• Layer 3 inline mode does not require designation of a preferred port or
configuration of port restart.
• CPU processing must be enabled on the Ethernet interfaces that will
receive server replies to client requests. CPU processing is required on
these interfaces in order to change the source IP address from the
server’s real IP address back into the VIP address.
Restrictions
• Supported for Active-Standby HA deployments only. Not supported for
Active-Active HA.
• Inline mode is designed for one HA group in Hot-Standby mode. Do not
configure more than one HA group on an ACOS device running in
inline mode.
• In order to prevent Layer 2 loops in a Layer 2 host-standby environ-
ment, the Standby ACOS device does not forward traffic. In addition,
the Active ACOS device in the HA pair is designed to not forward pack-
ets destined for the Standby ACOS device. Depending on the network
topology, certain traffic to the Standby ACOS device might be dropped
if it must first pass through the Active ACOS device.
HA Messages
The ACOS devices in an HA pair communicate their HA status with the fol-
lowing types of messages:
• HA heartbeat messages
• Gratuitous ARP requests and replies

Overview
HA Heartbeat Messages
Each of the ACOS devices regularly sends HA heartbeat messages out its
HA interfaces. The Standby ACOS device listens for the heartbeat mes-
sages. If the Standby ACOS device stops receiving heartbeat messages from
the Active ACOS device, the Standby ACOS device transitions to Active
and takes over networking and SLB operations from the other ACOS
device.
By default, heartbeat messages are sent every 200 milliseconds. If the

Standby ACOS device does not receive a heartbeat message for 1 second
(5 times the heartbeat interval), the Standby ACOS device transitions to
Active.
The heartbeat interval and retry count are configurable. (See “HA Configu-
ration Parameters” on page 292.)
If the heartbeat messages from one ACOS device to the other will pass
through a Layer 2 switch, the switch must be able to pass UDP IP multicast
packets. (This requirement does not apply to Layer 2 inline HA because it
uses unicast to transmit the heartbeat.)
Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6)
For IPv4, when an ACOS device transitions from Standby to Active, the
newly Active ACOS device sends gratuitous ARP requests and replies
(ARPs) for the IPv4 address under HA control.
Similarly, for IPv6, when an ACOS device transitions from Standby to

Active, the newly Active ACOS device sends ICMPv6 neighbor advertise-
ment for the IPv6 address under HA control.
Gratuitous ARPs or ICMPv6 neighbor advertisements are sent for the fol-
lowing types of addresses:
• Virtual server IP addresses, for the VIPs that are assigned to an HA
group.
• Floating IP address, if configured
• NAT pool IP addresses, for NAT pools assigned to an HA group
Devices that receive the ARPs or ICMPv6 neighbor advertisements learn

that the MAC address for the HA pair has moved, and update their forward-
ing tables accordingly.

Overview
The Active ACOS device sends the gratuitous ARPs or ICMPv6 neighbor
advertisements immediately upon becoming the Active ACOS device. To
make sure ARPs or ICMPv6 neighbor advertisements are being received by
the target addresses, the ACOS device re-sends them 4 additional times, at
500-millisecond intervals.
After this, the ACOS device sends gratuitous ARPs or ICMPv6 neighbor
advertisements every 30 seconds to keep its IP information current.
The retry count is configurable. (See “HA Configuration Parameters” on

page 292.)
HA Interfaces
When configuring HA, you specify each of the interfaces that are HA inter-
faces. An HA interface is an interface that is connected to an upstream
router, a real server, or the other ACOS device in the HA pair.
HA heartbeat messages can be sent only on HA interfaces. Optionally, you

can disable the messages on individual interfaces. When you configure an
HA interface that is a tagged member of one or more VLANs, you must
specify the VLAN on which to send the heartbeat messages.
Changes to the state of an HA interface can trigger a failover. By default,

the HA state of an interface can be Up or Down. Optionally, you can specify
the HA interface type as one of the following:
• Server interface – A real server can be reached through the interface.
• Router interface – An upstream router (and ultimately, clients) can be

reached through the interface.
• Both – Both a server and upstream router can be reached through the
interface.
If you specify the HA interface type, the HA status of the ACOS device is
based on the status of the link with the real server and/or upstream router.
The HA status can be one of the following:
• Up – All configured HA router and server interfaces are up.
• Partially Up – Some HA router or server interfaces are down but at least

one server link and one router link are up.
• Down – All router interfaces, or all server interfaces, or both are down.
The status also is Down if both router interfaces and server interfaces
are not configured and an HA interface goes down.

Overview
If both types of interfaces (router interfaces and server interfaces) are con-
figured, the HA interfaces for which a type has not been configured are not
included in the HA interface status determination.
During selection of the active ACOS device, the ACOS device with the
highest state becomes the active ACOS device and all HA interfaces on that
ACOS device become active. For example, if one ACOS device is UP and
the other ACOS device is only Partially Up, the ACOS device that is UP
becomes the active ACOS device.
If each ACOS device has the same state, the active ACOS device is selected
as follows:
• If HA pre-emption is disabled (the default), the first ACOS device to
come up is the active ACOS device.
• If HA pre-emption is enabled, the ACOS device with the higher HA
group priority becomes active for that group. If the group priorities on
the two ACOS devices are also the same, the ACOS device that has the
lowest HA ID (1 or 2) becomes active.
Note: You can configure up to 31 HA groups on an ACOS device, and assign a

separate HA priority to each. For Active-Standby configurations, use only
one group ID. For Active-Active configurations, use multiple groups IDs
and assign VIPs to different groups.
Notes
• The maximum number of HA interfaces you can configure is the same
as the number of Ethernet data ports on the ACOS device.
• If the heartbeat messages from one ACOS device to the other will pass
through a Layer 2 switch, the switch must be able to pass UDP IP multi-
cast packets. (This requirement does not apply to Layer 2 inline HA
because it uses unicast to transmit the heartbeat.)
• If a tracked interface is a member of a trunk, only the lead port in the
trunk is shown in the tracking configuration and in statistics. For exam-
ple, if a trunk contains ports 1-3 and you configure tracking of port 3,
the configuration will show that tracking is enabled on port 1. Likewise,
tracking statistics will show port 1, not port 3. Similarly, if port 1 goes
down but port 3 is still up, statistics still will show that port 1 is up since
it is the lead port for the trunk.
• In non-Layer 2 inline deployments, if the heartbeat messages from one
ACOS device to the other will pass though a Layer 2 switch, the switch
must be able to pass UDP IP multicast packets. Layer 2 inline mode
does not have this requirement.

Overview
VLAN ID Requirement
Beginning in AX Release 2.7.0, in deployments that use the older imple-

mentation of High Availability (HA), if an HA interface is a tagged member
of one or more VLANs, it is required to specify one of the member VLAN
IDs when configuring the interface to be an HA interface.
If the VLAN ID is not specified, the ACOS device does not transmit any
heartbeat packets on the interface. This is an invalid configuration. Previous
releases incorrectly allowed the invalid configuration but current releases
do not.
For example, the following command is valid, if Ethernet port 5 is a tagged

interface:
ha interface ethernet 5 vlan 2
The following command is invalid:

ha interface ethernet 5
If you are upgrading a device whose configuration has an invalid command

such as the one shown above, you will need to re-enter the command with
valid syntax after the upgrade.
Note: If you do not want heartbeat messages to be sent on a tagged interface,

you still can use the no-heartbeat option. For example:
ha interface ethernet 5 no-heartbeat
Session Synchronization
HA session synchronization sends information about active client sessions
to the Standby ACOS device. If a failover occurs, the client sessions are
maintained without interruption. Session synchronization is optional. With-
out it, a failover causes client sessions to be terminated. Session synchroni-
zation can be enabled on individual virtual ports.
Session synchronization applies primarily to Layer 4 sessions. Session syn-

chronization does not apply to DNS sessions. Since these sessions are typi-
cally very short lived, there is no benefit to synchronizing them. Likewise,
session synchronization does not apply to NATted ICMP sessions or to any
static NAT sessions. Synchronization of these sessions is not needed since
the newly Active ACOS device will create a new flow for the session fol-
lowing failover.

Overview
To enable session synchronization, see “Enabling Session Synchronization”
on page 332.
Session synchronization is required for config sync. Config sync uses the
session synchronization link. (For more information, “Manually Synchro-
nizing Configuration Information” on page 335.)
Note: Session synchronization is also called “connection mirroring”.
Optional Failover Triggers

In addition to HA interface-based failover, you can configure failover based
one any of the following:
• Inactive VLAN (VLAN-based failover)
• Unresponsive gateway router (gateway-based failover)
• Unresponsive real servers (VIP-based failover)
VLAN-based Failover
You can enable HA checking for individual VLANs. When HA checking is

enabled for a VLAN, the active ACOS device in the HA pair monitors traf-
fic activity on the VLAN. If there is no traffic on the VLAN for half the
duration of a configurable timeout, the ACOS device attempts to generate
traffic by issuing ping requests to servers if configured, or broadcast ARP
requests through the VLAN.
If the ACOS device does not receive any traffic on the VLAN before the
timeout expires, a failover occurs. The timeout can be 2-600 seconds. You
must specify the timeout. Although there is no default, A10 recommends
trying 30 seconds.
This HA checking method provides a passive means to detect network

health, whereas heartbeat messages are an active mechanism. You can use
either or both methods to check VLAN health. If you use both methods on a
VLAN, A10 recommends that you specify an HA checking interval (time-
out) that is much longer than the heartbeat interval.
For a configuration example, see “VLAN-Based Failover Example” on

page 325.

Overview
Gateway-based Failover
Gateway-based failover uses ICMP health monitors to check the availability

of the gateways. If any of the active ACOS device’s gateways fails a health
check, the ACOS device changes its HA status to Down. If the HA status of
the other ACOS device is higher than Down, a failover occurs.
Likewise, if the gateway becomes available again and all gateways pass
their health checks, the ACOS device recalculates its HA status according to
the HA interface counts. If the new HA status of the ACOS device is higher
than the other ACOS device’s HA status, a failover occurs.
Configuration of gateway-based failover requires the following steps:

1. Configure a health monitor that uses the ICMP method.
2. Configure the gateway as an SLB real server and apply the ICMP health
monitor to the server.
3. Enable HA checking for the gateway.
For a configuration example, see “Gateway-Based Failover Example” on

page 326.
Route-based Failover
Route-based failover reduces the HA priority of all HA groups on the
ACOS device, if a specific route is missing from the IPv4 or IPv6 route
table.
You can configure this feature for individual IP routes. When you configure
this feature for a route, you also specify the value to subtract from the HA
priority of all HA groups, if the route is missing from the route table.
You can configure this option for up to 100 IPv4 routes and up to 100 IPv6
routes. This option is valid for all types of IP routes supported in this release
(static and OSPF).
If the priority of an HA group falls below the priority for the same group on
the other ACOS device in an HA pair, a failover can be triggered.
Notes
• This feature applies only to routes in the data route table. The feature
does not apply to routes in the management route table.
• For failover to occur due to HA priority changes, the HA pre-emption
option must be enabled.

Overview
For a configuration example, see “Route-Based Failover Example” on
page 327.
Real Server or Port Health-based Failover
You can configure the ACOS device to decrease the HA priority of an HA

group, if a real server or port’s health status changes to Down.
You can configure this feature on individual real servers and ports. The fea-
ture is disabled by default. To enable the feature, assign an HA weight to the
server or port. If the server or port’s health status changes to Down, the
weight value is subtracted from the priority value of the HA group. You can
specify a single HA group or allow the priority change to apply to all HA
groups.
If the server or port’s status changes back to Up, the weight value is added
back to the HA group’s priority value.
If the HA priority of a group falls below the priority of the same group on
the other ACOS device, HA failover can be triggered.
Notes
• The lowest HA priority value a server or port can have is 1.
• If HA weights for an HA group are assigned to both the server and an

individual port, and both health checks are unsuccessful, only the server
weight is subtracted from the HA group’s priority.
• For failover to occur due to HA priority changes, the HA pre-emption
option must be enabled.
VIP-based Failover
VIP-based failover allows service for a VIP to be transferred from one

ACOS device in an HA pair to the other ACOS device based on HA status
changes of the real servers.
When you configure an HA group ID, you also specify its priority. If HA
pre-emption is enabled, the HA group’s priority can be used to determine
which ACOS device in the HA pair becomes the Active ACOS device for
the HA group. In this case, the ACOS device that has a higher value for the
group’s priority becomes the Active ACOS device for the group.

Overview
If you enable the dynamic HA option on a virtual server, the ACOS device
reduces the HA priority of the group assigned to the virtual server, if a real
server becomes unavailable. (A real server is unavailable if it is marked
Down by the ACOS device because the server failed its health check.) If the
priority value is reduced to a value that is lower than the group’s priority
value on the other ACOS device in the HA pair, and HA pre-emption is
enabled, service of the virtual serve is failed over to the other ACOS device.
When a real server becomes available again, the weight value that was sub-
tracted from the HA group’s priority is re-added. If this results in the prior-
ity value being higher than on the other ACOS device, the virtual server is
failed over again to the ACOS device with the higher priority value for the
group.
Note: Configure the same HA group ID on any floating IP addresses or Source

IP NAT pools used by the virtual server. For example, if you assign a vir-
tual server to HA group 31, also assign any floating IP addresses and IP
Source NAT pools used by the virtual server to HA group 31.
For a configuration example, see “VIP-Based Failover Example” on

page 329.

Overview
How the Active ACOS Device Is Selected

In Active-Standby configurations, only one ACOS device is Active and the
other is the Standby. After you configure HA, the Active ACOS device is
selected using the process shown in Figure 41.
FIGURE 41 Initial Selection of Active ACOS Device
After initial selection of the Active ACOS device, that device remains the
Active ACOS device unless one of the following events occurs:
• The Standby ACOS device stops receiving HA heartbeat messages from
the Active ACOS device.
• The HA interface status of the Active ACOS device becomes lower than
the HA interface status of the Standby ACOS device.
• VLAN-based failover is configured and the VLAN becomes inactive.

Overview
• Gateway-based failover is configured and the gateway becomes unavail-
able.
• HA pre-emption is enabled, and the configured HA priority is changed
to be higher on the Standby ACOS device.
Figure 42 shows the events that can cause an HA failover.
FIGURE 42 HA Failover

Overview
HA Pre-Emption
By default, a failover occurs only in the following cases:
• The Standby ACOS device stops receiving HA heartbeat messages form
the other ACOS device in the HA pair.
• HA interface state changes give the Standby ACOS device a better HA
state than the Active ACOS device. (See “HA Interfaces” on page 281.)
• VLAN-based failover is configured and the VLAN becomes inactive.
(See “VLAN-based Failover” on page 284.)
• Gateway-based failover is configured and the gateway becomes unavail-
able. (See “Gateway-based Failover” on page 285.)
• VIP-based failover is configured and the unavailability of real servers
causes the Standby ACOS device to have the greater HA priority for the
VIP’s HA group. (See “VIP-based Failover” on page 286.)
By default, failover does not occur due to HA configuration changes to the

HA priority.
To enable the ACOS devices to failover in response to changes in priority,

enable HA pre-emption. When pre-emption is enabled, the ACOS device
with the higher HA priority becomes the Active ACOS device. If the HA
priority is equal on both ACOS devices, then the ACOS device with the
lower HA ID (1) becomes the Active ACOS device.
Note: To force Active groups to change to Standby status, without changing HA

group priorities and enabling pre-emption, see “Forcing Active Groups to
Change to Standby Status” on page 331.

Overview
HA Sets
Optionally, you can provide even more redundancy by configuring multiple
sets of HA pairs.
FIGURE 43 Multiple HA Pairs
In this example, two HA pairs are configured. Each pair is distinguished by

an HA set ID. Each HA pair can be used to handle a different set of real
servers.
You can configure up to 7 HA sets. This feature is supported for Layer 2 and
Layer 3 HA configurations. The set ID can be specified along with the HA
ID. (For syntax information, see Table 16 on page 292.)

Overview
HA Configuration Parameters
Table 16 lists the HA parameters.
TABLE 16 HA Parameters
Parameter Description and Syntax Supported Values
Global HA Parameters
HA ID HA ID of the ACOS device, and HA set to which HA ID: 1 or 2
and the ACOS device belongs. HA set ID: 1-7
HA set ID The HA ID uniquely identifies the ACOS device Default: Neither parameter is set
within the HA pair.
The HA set ID specifies the HA set to which the
ACOS device belongs. This parameter is applicable
to configurations that use multiple ACOS device
pairs.
[no] ha id {1 | 2} [set-id num]
Config Mode > System > HA > HA Global - Gen-
eral
HA group ID Uniquely identifies the HA group on an individual HA group ID: 1-31
ACOS device. Priority: 1 (low priority) to 255 (high
The priority value can be used during selection of priority
the Active ACOS device. (See“How the Active Default: not set
ACOS Device Is Selected” on page 288.)
[no] ha group group-id priority num
Config Mode > System > HA > HA Global - Group
Floating IP IP address that downstream devices should use as Default: not set
address their default gateway. The same address is shared by
both ACOS devices in the HA pair. Regardless of
which device is Active, downstream devices can
reach their default gateway at this IP address.
Note: A floating IP address can not be the same as
an address that already belongs to a device. For
example, the IP address of an interface can not be a
floating IP address.
[no] floating-ip ipaddr
ha-group group-id
Config Mode > System > HA > HA Global - Float-
ing IP Address

Overview
TABLE 16 HA Parameters (Continued)
HA interfaces Interfaces used for HA management. Ethernet interfaces
HA heartbeat messages are sent on HA interfaces, Default: not set
unless you use the option to disable the messages.
At least one HA interface must be specified. If the
interface is tagged, then a VLAN ID must be speci-
fied if heartbeat messages are enabled on the inter-
face.
If you specify the interface type (server, router, or
both), changes to the interface state can control
failover. (See “HA Interfaces” on page 281 and
“How the Active ACOS Device Is Selected” on
page 288.)
[no] ha interface ethernet port-num
[router-interface |
server-interface | both]
[no-heartbeat | vlan vlan-id]
Config Mode > Network > Interface > LAN - Select
the interface and then click HA.
VLAN-based Enables the ACOS device to change its HA status Valid VLAN ID
HA based on the health of a VLAN. Default: not set
When HA checking is enabled for a VLAN, the The timeout can be 2-600 seconds.
active ACOS device in the HA pair monitors traffic
Although there is no default timeout,
activity on the VLAN. If there is no traffic on the
A10 recommends trying 30 seconds.
VLAN for half the duration of a configurable time-
out, the ACOS device attempts to generate traffic by
issuing ping requests to servers if configured, or
broadcast ARP requests through the VLAN.
If the ACOS device does not receive any traffic on
the VLAN before the timeout expires, a failover
occurs.
[no] ha check vlan vlan-id timeout
seconds
Config Mode > System > HA > HA Global - Status
Check
Gateway-based Enables the ACOS device to change its HA status IP address of the gateway
HA based on the health of a gateway router. Default: not set
If the gateway fails a Layer 3 (ICMP) health check, Additional configuration is required.
the ACOS device changes its HA status to Down. If (See “Gateway-based Failover” on
the HA status of the other ACOS device is higher page 285.)
than Down, a failover occurs.
[no] ha check gateway ipaddr
Config Mode > System > HA > HA Global - Status
Check

Overview
Session synchro- Enables the ACOS devices to share information IP address of the other ACOS device
nization about active client sessions. If a failover occurs, cli- Default: not set
(Also called ent sessions continue uninterrupted. The Standby
“connection mir- ACOS device, when it becomes Active, uses the
roring”) session information it received from the Active
ACOS device before the failover to continue the
sessions without terminating them.
To enable session synchronization, specify the IP
address of the other ACOS device in the HA pair.
Session synchronization does not apply to DNS ses-
sions. Since these sessions are typically very short
lived, there is no benefit to synchronizing them.
Note: This option also requires session synchroni-
zation to be enabled on the individual virtual service
ports. (See “HA Parameters for Virtual Service
Ports” below.)
[no] ha conn-mirror ip ipaddr
eral
Pre-emption Controls whether failovers can be caused by config- Enabled or disabled
uration changes to HA priority or HA ID. Default: disabled
[no] ha preemption-enable
Config Mode > System> HA > HA Global - Gen-
eral
HA heartbeat Interval at which the ACOS device sends HA heart- 1-255 units of 100 milliseconds
interval beat messages on its HA interfaces. (ms) each
[no] ha time-interval Default: 200 ms
100-msec-units
eral
Retry count Number of HA heartbeat intervals the Standby 2-255
device will wait for a heartbeat message from the Default: 5
Active ACOS device before failing over to become
the Active ACOS device.
[no] ha timeout-retry-count num
eral
ARP repeat Number of additional gratuitous ARPs, in addition 1-255
count to the first ones, an ACOS device sends after tran- Default: 4 additional gratuitous
sitioning from Standby to Active in an HA configu- ARPs, for a total of 5
ration.
[no] ha arp-retry num
eral

Overview
Forced failover Forces HA groups to change from Active to Valid HA group ID.
Standby status. If you do not specify a group ID, all
[no] ha force-self-standby Active groups are forced to change
[group-id] from Active to Standby status.
Note: This option provides a simple method to force
a failover, without the need to change HA group pri-
orities and enable pre-emption. The option is not
added to the configuration and does not persist
across reboots.
Note: The current release does not support configu-
ration of this parameter using the GUI.
Layer 2/3 Enables Layer 2/3 forwarding of Layer 4 traffic on Enabled or disabled
forwarding of the Standby ACOS device. Default: Disabled. Layer 4 traffic is
Layer 4 traffic on [no] ha forward-l4-packet-on- dropped by the Standby ACOS device.
the Standby standby
ACOS device
ration of this parameter using the GUI.
Global HA Parameters for Layer 2 Inline Mode
Inline mode state Enables Layer 2 inline mode and, optionally, speci- Enabled or disabled
fies the HA interface to use for session synchroniza- Default: disabled
tion and for management traffic between the ACOS
When inline mode is enabled, the pre-
devices.
ferred port is selected as described in
[no] ha inline-mode “Preferred HA Port” on page 275.
[preferred-port port-num]
Config Mode > System> HA > HA Inline Mode
Restart port list List of Ethernet interfaces on the previously Active Ethernet interfaces
ACOS device to toggle (shut down and restart) fol- Default: not set
lowing HA failover.
[no] ha restart-port-list ethernet
port-list
Port restart time Amount of time interfaces in the restart port list 1-100 units of 100 milliseconds (ms)
remain disabled following a failover. Default: 20 units of 100 ms (2 sec-
[no] ha restart-time 100-msec-units onds)
Global HA Parameters for Layer 3 Inline Mode
Inline mode state Enables Layer 3 inline mode. Enabled or disabled
[no] ha l3-inline-mode Default: disabled

Overview
OSPF on Leaves OSPF enabled on the Standby ACOS Enabled or disabled
Standby ACOS device. Default for all HA modes except
device [no] ha ospf-inline vlan vlan-id Layer 3 inline: disabled. OSPF is dis-
Note: This option is not configurable using the abled on the Standby ACOS device.
GUI. Default for Layer 3 inline mode:
enabled. OSPF is allowed to run on all
VLANs by default.
Link event delay Change the delay waited by the ACOS device 100 milliseconds (ms) to 10000 ms, in
before changing the HA state (Up, Partially Up, or increments of 100 ms
Down) in response to link-state changes on HA Default: 3000 ms (3 seconds)
interfaces.
[no] ha link-event-delay
100-ms-unit
HA Parameters for Virtual Servers
HA group ID HA group ID for a virtual server. 1-31
This is required to enable HA for the VIP. Default: not set
[no] ha-group group-id
Config Mode > SLB > Service > Virtual Server
Server weight Weight value assigned to real servers bound to the 1-255
virtual server. Not set
The weight is used for VIP-based failover. (See
“VIP-based Failover” on page 286.)
[no] ha-dynamic server-weight
Config Mode > SLB > Service > Virtual Server -
Select the HA group, then select the Dynamic
Server Weight.
Link event delay Change the delay waited by the ACOS device 100 milliseconds (ms) to 10000 ms, in
before changing the HA state (Up, Partially Up, or increments of 100 ms
Down) in response to link-state changes on HA Default: 3000 ms (3 seconds)
interfaces.
[no] ha link-event-delay
100-ms-unit
Config Mode > HA > Setting - HA Inline Mode

Overview
HA Parameters for Virtual Service Ports
Session Enables active client sessions on this virtual port to Enabled or disabled
synchronization continue uninterrupted following a failover. Default: disabled
(Also called Note: This option also requires session synchroni-
“connection mir- zation to be enabled globally. (See “Global HA
roring”) Parameters” above.)
[no] ha-conn-mirror
Config Mode > SLB > Service > Virtual Server -
Port
HA Parameters for Real Servers
Priority cost Decreases the HA priority of an HA group, if the Weight: 1-255
real server’s health status changes to Down. HA group: 1-31. If no group is speci-
[no] ha-priority-cost weight fied, the weight applies to all HA
[ha-group group-id] groups.
Note: The current release does not support configu- Default: not set
ration of this option using the GUI.
HA Parameters for Real Ports
Priority cost Decreases the HA priority of an HA group, if the Weight: 1-255
real port’s health status changes to Down. HA group: 1-31. If no group is speci-
[no] ha-priority-cost weight fied, the weight applies to all HA
[ha-group group-id] groups.
Note: The current release does not support configu- Default: not set
HA Parameters for Firewall Load Balancing (FWLB)
HA group ID When using the HA group ID with a DNS firewall. 1-31
[no] ha-group group-id Default: not set
Config Mode > Security> Template > DNS Firewall
Session Enables active client sessions on this port to con- Enabled or disabled
synchronization tinue uninterrupted following a failover. Default: disabled
Note: This option also requires session synchroni-
zation to be enabled globally. (See “Global HA
Parameters” above.)
[no] ha-conn-mirror

Overview
HA Parameters for IP Network Address Translation (NAT) Pools
HA group ID HA group ID for IP NAT. 1-31
Option with ip nat pool, ipv6 nat pool, or ip nat Default: not set
inside command: ha-group group-id
Config Mode > IP Source NAT > IPv4 Pool
Config Mode > IP Source NAT > IPv6 Pool
Config Mode > IP Source NAT > NAT Range
HA Parameters for IP Routes
Priority cost Reduces the HA priority of all HA groups on the Default: not set
ACOS device, if the specified route is missing from
the IPv4 or IPv6 route table.
For IPv4 routes:

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

[no] ha check route
destination-ipv6addr/mask-length
[gateway ipv6addr]
[distance num]


HA Status Indicators
The HA status of an ACOS device is displayed in the GUI and CLI. The HA
status indicators provide the following information:
• Current HA status of the ACOS device: Active or Standby
• Configuration status:
• Most recent configuration update – The system time and date when
the most recent configuration change was made.
• Most recent configuration save – The system time and date when
the configuration was saved to the startup-config.
• Most recent config-sync – The system time and date when the most
recent configuration change was made.
If the ACOS device is configured with multiple Role-Based Administra-
tion (RBA) partitions, separate configuration status information is
shown for each partition.
In the GUI
The current HA status is shown as one of the following:
• Active
• Standby
• Not Configured
The config-sync status is shown as one of the following:

• Sync
• Not-Sync
The GUI does not indicate when the most recent configuration update or
save occurred. This information is available in the CLI. (See below.)
Note: In the current release, the configuration synchronization status is not

updated from Not-Sync to Sync if the synchronization target is the run-
ning-config.
ACOS 2.7.1 provides the user with the ability to configure the prompt. It
allows you to add or remove the device hostname, the aVCS chassis device
ID, the aVCS status, the VRRP-A status, or the HA status. Configuring a
prompt is optional. If all the five options are configured, an example of a
prompt may say AX1030-vMaster[7/1](config)#.

Use the following command to change your terminal prompt:
[no] terminal prompt {ha-status | hostname | chassis-device-id | vcs-sta-
tus}
To display the HA or VRRP-A status in the prompt, specify the ha-status

keyword. For example, this can be Active, Standby, or ForcedStandby.
When you configure ha-status, the VRRP-A or HA states of a device will be
displayed in the prompt. ForcedStandby will be displayed when you issue
the terminal prompt ha-status command and the device is in a forced
standby state.
USING THE GUI
USING THE CLI
To configure the terminal prompt, issue the following command:

ACOS(config)#terminal prompt hostname ha-status vcs-status chassis-
device-id
If your device is running aVCS and HA, you can configure the following
commands. With each configuration entry, see how the terminal prompt
changes. The prompt additions appear in bold font:
ACOS(config)#terminal prompt hostname vcs-status
AX1030-vMaster(config)#show run | sec prompt
terminal prompt hostname vcs-status
If the device is in a forced standby state, you will see the following prompt:
AX1030(config)#terminal prompt ha-status
ForcedStandby(config)#
Use the show terminal command to view the terminal prompt format.
By default, all prompts are displayed. So, if you revert from a configured
prompt to a default prompt, you will see the following results:
AX1030-vMaster(config)#no terminal prompt
AX1030-Active-vMaster[1/1](config)#show terminal
Terminal prompt format: hostname ha-status vcs-status

chassis-device-id
For details on all configurable prompts and how they work in conjunction
with one another, refer to “Configurable aVCS Prompts” on page 501.

Configuring Layer 3 HA
To configure Layer 3 HA:
1. Configure the following global HA parameters:
• HA ID
• HA group ID and priority. For an Active-Standby configuration,
configure one group ID. For Active-Active, configure multiple HA
group IDs.
• Floating IP address (optional)
• Session synchronization (optional)
• HA pre-emption (optional)
2. Configure the HA interfaces.
3. Add each virtual server to an HA group.
4. If session synchronization is globally enabled, enable it on the individ-

ual virtual ports whose client sessions you want to synchronize.
5. If IP NAT pools are configured, add each pool to an HA group.
USING THE GUI
Configuring Global HA Parameters

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

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

Repeat for each additional group used in the configuration.
3. In the Floating IP Address section, configure the floating IP addresses

for the HA groups.
a. Select an HA group from the Group Name drop-down list.
b. Select the address type (IPv4 or IPv6).
c. Enter the floating IP address for the group.
d. Click Add.
e. If you are configuring Active-Active, select the next HA group from
the Group Name drop-down list, and repeat the previous steps.
4. Click OK.
Configuring HA Interfaces
1. Select Config Mode > Network > Interface.
2. On the menu bar, select LAN. The list of the ACOS device’s physical
Ethernet data interfaces appears.
3. Perform the following steps for each HA interface. (For information, see
“HA Interfaces” on page 281.)
a. Click on the interface number.
b. In the HA section, select Enabled next to HA Enabled.
c. To specify the interface type, select one of the following or leave the
setting None:
• Router-Interface
• Server-Interface
• Both
d. To enable HA heartbeat messages, select Enabled next to Heartbeat.
e. To restrict the HA heartbeat messages to a specific VLAN, enter the
VLAN ID in the VLAN field.
f. Click OK.
Configuring HA Parameters on a Virtual Server

1. Select Config Mode > SLB > Service > Virtual Server.
2. Click on the virtual server name or click Add to add a new one.
3. In the General section, select the HA group ID from the HA Group

drop-down list.

Note: The Dynamic Server Weight option is used for VIP-based failover. For
information, see “VIP-based Failover” on page 286.
4. Configure other general settings, not related to HA, if needed.
5. If you plan to use session synchronization (connection mirroring) for a

service port:
a. In the Port section, click Add to add a new virtual service port or
select an existing port and click Edit. The Virtual Server Port sec-
tion appears.
b. Select enabled next to HA Connection Mirror.
c. Click OK. The service port list re-appears.
Note: The GUI does not support enabling connection mirroring on some types
of service ports. However, you can enable connection mirroring for these
service types using the CLI.
6. Click OK to complete configuration of the virtual server.

HA Configuration of AX1
FIGURE 44 Config Mode > HA > Setting > HA Global

FIGURE 45 Config Mode > Network > Interface> LAN (Ethernet interface 1)
Note: This example shows HA configuration of a single interface. Make sure to

configure HA settings on the other HA interfaces too.
FIGURE 46 Config Mode > SLB > Service > Virtual Server (VIP1)

HA Configuration of AX2
FIGURE 48 Config Mode > HA > HA Global

USING THE CLI

1. To configure the global HA parameters, use the following commands at
ha id {1 | 2} [set-id num]
ha group group-id priority num
floating-ip ipaddr ha-group group-id

ha interface ethernet port-num
[router-interface | server-interface | both]
ha conn-mirror ip ipaddr
ha preemption-enable
2. To add a virtual server to an HA group, use the following command at

the configuration level for the virtual server:
ha-group group-id
Use the same HA group ID for the same virtual server, on both ACOS
devices.
3. If session synchronization is globally enabled, use the following com-

mand at the configuration level for the virtual port to enable session syn-
chronization for the port:
ha-conn-mirror
4. If IP NAT will be used, use the following option with the ip nat pool or
ipv6 nat pool command when configuring the pool.
ha-group group-id
(For the complete command syntax, see Table 16 on page 292.)
Commands on AX1
This examples shows the CLI commands to implement the Active-Active
configuration shown in Figure 37 on page 271.
The following commands configure the HA ID and HA groups. Since this is

an Active-Active configuration, both HA groups are configured. The prior-
ity for group 1 is set to a low value. The same group will be set to a higher
priority value on the other ACOS device. Likewise, the priority of group 2
is set to a high value on this ACOS device but will be set to a lower value on
the other ACOS device.
Later in the configuration, each virtual server will need to be added to one
or the other of the HA groups.
AX1(config)#ha id 1
AX1(config)#ha group 1 priority 1
The following commands configure the floating IP addresses for each HA

group. The real servers and the Layer 2 switches connected to them will
need to be configured to use the floating IP addresses as their default gate-
ways.

AX1(config)#floating-ip 10.10.10.1 ha-group 1
The following commands configure the HA interfaces. The interface types

are specified, so that the HA state of the ACOS device can be more pre-
cisely calculated based on HA interface state. (See “HA Interfaces” on
page 281.)
Heartbeat messages are disabled on all HA interfaces except the dedicated

HA link between the ACOS devices.
AX1(config)#ha interface ethernet 1 router-interface no-heartbeat
AX1(config)#ha interface ethernet 3 server-interface no-heartbeat
AX1(config)#ha interface ethernet 5
The following command enables session synchronization (connection mir-

roring). The feature also will need to be enabled on individual virtual ports,
later in the configuration. The IP address is the real address of the other
ACOS device.
AX1(config)#ha conn-mirror ip 10.10.30.2
The following command enables HA pre-emption, to ensure that the Active

and Standby for each virtual server are chosen based on the configuration.
By default, when HA is first configured, Active and Standby are selected
based on which ACOS device comes up first.
AX1(config)#ha preemption-enable
The following commands add each of the virtual servers to an HA group,

and enables session synchronization on the virtual ports. (For brevity, this

example does not show the complete SLB configuration, only the HA part
of the SLB configuration.)
AX1(config)#slb virtual-server VIP1
AX1(config-slb virtual server)#ha-group 1
AX1(config-slb virtual server)#port 80 tcp
AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror
AX1(config-slb virtual server-slb virtua...)#exit
AX1(config-slb virtual server)#exit
Commands on AX2
Here are the commands for AX2. The priority values for the groups are dif-
ferent from the values set on AX1, so that group 1 has higher priority on this
ACOS device than on AX1. Likewise, the priority of group 2 is set so that
its priority is higher on AX1.
AX2(config)#ha id 2
The floating IP addresses must be the same as the ones set on AX1.
The IP address for session synchronization is the address of AX1.


Configuring Layer 2 HA (Inline Mode)
The HA configuration for virtual servers and virtual ports is identical to the
configuration on AX1.

• HA ID
• HA group ID and priority. Configure only one group ID. Configure
the same ID on both ACOS devices.
• Inline mode and optional preferred port
• Restart port list and time (optional)
• HA interfaces
2. Add each virtual server to the HA group.

4. If IP NAT pools are configured, add each pool to the HA group.
Note: If source NAT is not configured for the VIP, but real servers send
responses to a gateway IP address other than the floating IP address, CPU
processing must be enabled on the interfaces connected to the real servers.
This applies to the following ACOS device models: AX 2200, AX 2200-
11, AX 3100, AX 3200, AX 3200-11, AX 3200-12, AX 3400, AX 5100,

AX 5200, and AX 5200-11. On other models, the option for CPU process-
ing is not valid and is not required.
Layer 2 Inline HA Configuration Example

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

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

a. Select HA group 1 from the Group Name drop-down list.
b. In the Priority field, enter the priority for HA group 1 and click Add.

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

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

1. Select Config Mode > System > HA > HA Inline Mode

2. Select Enabled next to Inline Mode Status.
3. Select the preferred port.
4. In Restart Port List section, select the HA interfaces.
5. Click >> to move them to the Selected list.
6. Click OK.
The following GUI screens configure HA on AX1 in Figure 39 on

page 274.
FIGURE 51 Config Mode > System > HA

FIGURE 52 Config Mode > Network > Interface > LAN (Ethernet interface
1)
Note: This example shows HA configuration of a single interface. Make sure to

configure HA settings on the other HA interfaces too.
FIGURE 53 Config Mode > System > HA > HA Inline Mode

USING THE CLI
Commands on AX1
The following commands configure the HA ID and set the HA priority. HA
priority is associated with an HA group. Since inline mode is supported only
in Active-Standby configurations, only one HA group is used. Later in the
configuration, the VIP is assigned to this HA group.
AX1(config)#ha id 1
The following command enables inline HA mode and specifies the pre-
ferred HA port.
AX1(config)#ha inline-mode preferred-port 5
The following commands configure the HA interfaces. Each interface that is

connected to a server, a router, or the other ACOS device can be configured
as an HA interface. Make sure to add the preferred HA port as one of the
HA interfaces.
AX1(config)#ha interface ethernet 3 server-interface
The following command enables restart of the HA ports connected to the

routers, to occur if the ACOS device transitions to Standby.
AX1(config)#ha restart-port-list ethernet 1 to 2
Note: If source NAT is not configured for the VIP, but real servers send
responses to a gateway IP address other than the floating IP address, enter
the cpu-process command at the configuration level for each interface
connected to the real servers. This requirement applies to the following
AX models: AX 2200, AX 2200-11, AX 3100, AX 3200, AX 3200-11,
AX 3200-12, AX 3400, AX 5100, AX 5200, and AX 5200-11. On other
models, the option for CPU processing is not valid and is not required.
The following command enables HA pre-emption mode, which causes

failover to occur in response to administrative changes to the HA configura-
tion. (For example, if you change the HA priority so that the other ACOS
device has higher priority, this will trigger a failover, but only if pre-emp-
tion mode is enabled.)

The following command specifies the IP address of the other ACOS device,
to use for session synchronization.
The following command configures the floating IP address for the real serv-
ers to use as their default gateway address.
The following commands configure a health method, real servers, a server

group, and a VIP for an HTTP service.
AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3
AX1(config-health:monitor)#method http url HEAD /index.html
AX1(config-health:monitor)#exit
AX1(config)#slb server s1 172.168.10.30
AX1(config-real server)#port 80 tcp
AX1(config-real server-node port)#health-check myHttp
AX1(config-real server-node port)#exit
AX1(config-real server)#exit
AX1(config)#slb service-group g80 tcp
AX1(config-slb service group)#member s1:80
AX1(config-slb service group)#exit
AX1(config)#slb virtual-server v1 172.168.10.80
AX1(config-slb virtual server-slb virtua...)#service-group g80

Commands on AX2
Here are the commands for implementing HA on the standby ACOS device,
AX2. Most of the commands are the same as those on AX1, with the fol-
lowing exceptions:
• The HA ID is 2.
• The HA priority is 1.
• The session synchronization (conn-mirror) IP address is the address of

the Active ACOS device. (On the Active ACOS device, the session syn-
chronization IP address is the address of the Standby ACOS device.)
AX2(config)#ha id 2
AX2(config)#ha inline-mode preferred-port 5


• HA ID
• HA group ID and priority. Configure only one group ID. Configure
the same ID on both ACOS devices.
• Inline mode
• HA interfaces
2. Enable CPU processing on the Ethernet interfaces that will receive

server replies to client requests.
3. Add each virtual server to the HA group.

5. If IP NAT pools are configured, add each pool to the HA group.

Layer 3 Inline HA Configuration Example

The following configuration example implements the deployment shown in
Figure 40 on page 278.
Note: The GUI does not support configuration of Layer 3 inline mode in the
current release.
USING THE CLI

1. To enable Layer 3 inline mode, use the following command at the
ha l3-inline-mode
2. To enable CPU processing on an interface, use the following command

at the configuration level for the interface:
cpu-process
If the interface is part of a trunk, use the command at the interface con-
figuration level for the trunk.
Commands on AX1
The following commands configure the interfaces. Since Ethernet interfaces

3 and 4 will receive server replies to client requests, CPU processing is
enabled on those interfaces.
AX1(config-if:ethernet1)#enable
AX1(config-if:ethernet3)#cpu-process
AX1(config-if:ethernet5)#exit
AX1(config)#vlan 100
AX1(config-vlan:100)#untagged ethernet 1 to 4
AX1(config-vlan:100)#exit

AX1(config)#vlan 5
AX1(config-vlan:5)#untagged ethernet 5
AX1(config)#interface ve 100
AX1(config-if:ve100)#interface ve 5
AX1(config-if:ve5)#exit
The following commands configure the HA ID and set the HA priority. HA

priority is associated with an HA group. Later in the configuration, the VIP
is assigned to this HA group.
AX1(config)#ha id 1
The following command enables Layer 3 inline HA mode.

AX1(config)#ha l3-inline-mode
The following commands configure the HA interfaces. Each interface that is

connected to a server, a router, or the other ACOS device can be configured
as an HA interface. (Make sure to add the dedicated HA link between the
ACOS devices as one of the HA interfaces.)
The following command enables restart of the HA ports connected to the

routers, to occur if the ACOS device transitions to Standby.
The following command enables HA pre-emption mode, which causes

failover to occur in response to administrative changes to the HA configura-
tion. (For example, if you change the HA priority so that the other ACOS
device has higher priority, this will trigger a failover, but only if pre-emp-
tion mode is enabled.)
The following command specifies the IP address of the other ACOS device,
to use for session synchronization.

The following command configures the floating IP address for the real serv-
ers to use as their default gateway address.
The following commands configure a health method, real servers, a server

group, and a VIP for an HTTP service.
Commands on AX2
Here are the commands for implementing HA on AX2. Most of the com-
mands are the same as those on AX1, with the following exceptions:
• The IP interfaces are different.
• The HA ID is 2.
• The HA priority is 1.
The session synchronization (conn-mirror) IP address is the address of

AX1. (On AX1, the session synchronization IP address is the address of
AX2.)

AX2(config-if:ethernet5)#exit
AX2(config)#vlan 100
AX2(config-vlan:100)#untagged ethernet 1 to 4
AX2(config)#vlan 5
AX2(config-vlan:5)#untagged ethernet 5
AX2(config)#interface ve 100
AX2(config-if:ve100)#interface ve 5
AX2(config-if:ve5)#exit
AX2(config)#ha id 2
AX2(config)#ha l3-inline-mode

Configuring Optional Failover Triggers

The following sections show how to configure the following optional
failover triggers:
• VLAN-based failover
• Gateway-based failover
• VIP-based failover
Only the configuration relevant to the triggers is shown. A complete HA

configuration also includes the configuration items described in the previ-
ous sections.
Note: Failover based on HA interface state is also optional, and is described in

other sections in this chapter.

VLAN-Based Failover Example

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

1. Select Config Mode > System > HA > HA Global.
2. In the Status Check section, enter the VLAN ID in the VLAN ID field.
3. Enter the timeout in the Timeout field.

The timeout can be 2-600 seconds. You must specify the timeout.
Although there is no default, A10 recommends trying 30 seconds.
4. Click Add.
5. Repeat step 2 through step 4 for each VLAN to be monitored for HA.
6. Click OK.
USING THE CLI
To enable HA checking for a VLAN, use the following command at the

[no] ha check vlan vlan-id timeout seconds
The timeout can be 2-600 seconds. You must specify the timeout. Although
there is no default, A10 recommends trying 30 seconds.
The following command enables VLAN-based failover for VLAN 10 and

sets the timeout to 30 seconds:
ACOS(config)#ha check vlan 10 timeout 30

Gateway-Based Failover Example

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

page 285.)
USING THE GUI

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

a. Select Config Mode > System > HA > HA Global.
b. In the Status Check section, enter the IP address of the gateway in
the IP Address field.
c. Click Add.
d. Repeat step b and step c for each gateway to be monitored for HA.
e. Click OK.
USING THE CLI

1. To configure a health monitor for a gateway, use the following com-
mands.
[no] health monitor monitor-name
Enter this command at the global Config level.
[no] method icmp
Enter this command at the configuration level for the health monitor.
2. To configure the gateway as an SLB real server and apply the health
monitor to the server, use the following command.
[no] slb server server-name ipaddr
[no] health-check monitor-name
3. To enable HA health checking for the gateway, use the following com-
mand at the global configuration level.
[no] ha check gateway ipaddr
CLI Example
The following commands configure an ICMP health method:

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

ACOS(config)#ha check gateway 10.10.10.1
Route-Based Failover Example

You can configure HA route awareness for IPv4 routes and IPv6 routes.
Note: The current release does not support this feature in the GUI.
HA Route Awareness for IPv4 Routes

To configure HA route awareness for an IPv4 route, use the following com-
mand at the global configuration level of the CLI:
[no] ha check route destination-ipaddr /mask-length
[gateway ipaddr]

[distance num]
The destination-ipaddr /mask-length option specifies the destination IPv4

subnet of the route.
The priority-cost weight option specifies the value to subtract from the HA
priority of each HA group, if the IP route table does not have a route to the
destination subnet.
The gateway addr option specifies the next-hop gateway for the route.
The protocol option specifies the source of the route:

• static – The route was added by an administrator.
• dynamic – The route was added by a routing protocol. (This includes

redistributed routes.)
The distance num option specifies the metric value (cost) of the route.
Omitting an optional parameter matches on all routes. For example, if you

do not specify the next-hop gateway, routes that match based on the other
parameters can have any next-hop gateway.
HA Route Awareness for IPv6 Routes

To configure HA route awareness for an IPv6 route, use the following com-
[no] ha check route
destination-ipv6addr/mask-length
[gateway ipv6addr]
[distance num]
The destination-ipv6addr/mask-length option specifies the destination IPv6

address. The other options are the same as those for IPv4 routes. (See
above.)
CLI Examples
The following command configures HA route awareness for a default IPv4
route. If this route is not in the IP route table, 255 is subtracted from the HA
priority of all HA groups.
ACOS(config)#ha check route 0.0.0.0 /0 priority-cost 255

Note: The lowest possible HA priority value is 1. Deleting 255 sets the HA pri-
ority value to 1, regardless of the original priority value.
The following command configures HA route awareness for a dynamic

route to subnet 10.10.10.x with route cost 10. If the IP route table does not
have a dynamic route to this destination with the specified cost, 10 is sub-
tracted from the HA priority value for each HA group.
ACOS(config)#ha check route 10.10.10.0 /24 priority-cost 10 protocol dynamic
distance 10
The following commands configure HA route awareness for an IPv6 route

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

To configure VIP-based failover, use either of the following methods.
These procedures apply specifically to the VIP-based failover parameters.

You also need to configure HA global and interface parameters. See “Con-
figuring Global HA Parameters” on page 301 and “Configuring HA Inter-
faces” on page 302.
(For a description of the feature, see “VIP-based Failover” on page 286.)
USING THE GUI
To configure VIP-based failover on a virtual server:

1. Configure HA global and interface parameters, if you have not already
done so.

3. Click on the virtual server name or click Add to create a new one.
4. Select the HA group from the HA Group drop-down list.

The Dynamic Server Weight field appears.
Note: If the HA Group drop-down list does not have any group IDs, you still
need to configure global HA parameters. See “Configuring Global HA
Parameters” on page 301.
5. Enter other parameters if needed (for example, the name, IP address,

and virtual service ports).
6. Click OK.
USING THE CLI

To configure VIP-based failover, use the following commands:
[no] ha-group group-id
Enter this command at the configuration level for a virtual server, to assign
the virtual server to the HA group. The group-id can be 1-31.
[no] ha-dynamic server-weight
Enter this command at the configuration level for the virtual server to
enable VIP-based failover. The server-weight specifies the amount to sub-
tract from the HA group's priority value for each real server that becomes
unavailable. The weight can be 1-255. The default is 1.
CLI Example
The following command configures HA group 6 on AX-1 and assigns prior-

ity 100 to the group:
AX-1(config)#ha group 6 priority 100
The following command enables HA pre-emption. HA pre-emption must be

enabled in order for failover to occur based on HA group priority changes.
AX-1(config)#ha preemption-enable
The following command configures a floating IP address and assigns it to

HA group 6:
AX-1(config)#floating-ip 192.168.10.1 ha-group 6

Forcing Active Groups to Change to Standby Status
The following commands assign virtual server VIP2 to HA group 6 and
enable VIP-based failover for the virtual server. (For simplicity, this exam-
ple does not show configuration of the real servers or non-HA virtual server
options.)
AX-1(config)#slb virtual VIP2 192.168.10.22
AX-1(config-slb virtual server)#ha-group 6
AX-1(config-slb virtual server)#ha-dynamic 10
The following commands configure the HA settings on AX-2. The priority

for HA group 6 is set to 80. The server weight for HA group 6 on VIP2 is
set to 10, the same weight value set on AX-1. Up to 2 real servers bound to
VIP2 can become unavailable on AX-1 without triggering a failover. How-
ever, if a third real server becomes unavailable, the priority of HA group 6 is
reduced to 70, which is lower than the priority value set on AX-2 for the
group. In this case, a failover does occur for VIP2.
AX-2(config)#ha group 6 priority 80
AX-2(config)#ha preemption-enable
AX-2(config)#floating-ip 192.168.10.1 ha-group 6
AX-2(config)#slb virtual VIP2 192.168.10.22
AX-2(config-slb virtual server)#ha-group 6
AX-2(config-slb virtual server)#ha-dynamic 10
Forcing Active Groups to Change to Standby Status

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

Enabling Session Synchronization
Enabling Session Synchronization

Session synchronization backs up live client sessions on the Backup ACOS
device.
To enable session synchronization:

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

persistence, and so on), and is therefore automatically enabled for these
sessions by the ACOS device. Persistent sessions are synchronized even if
session synchronization is disabled in the configuration.
USING THE GUI

To globally enable the feature:
1. Select Config Mode > System > HA> HA Global.
2. In the Mirror IP Address field, enter the IP address of a data interface on

the other ACOS device in the HA pair.
3. Click OK or Apply.
To enable the feature on individual virtual ports:

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

tion is not supported for this service type.

Configuring OSPF-Related HA Parameters
6. Click OK to redisplay the Port tab.
7. Click OK again.
USING THE CLI
To globally enable session synchronization, use the following command at

[no] ha conn-mirror ip ipaddr
The ipaddr must be an IP address of a data interface on the other ACOS

device.
To enable session synchronization on a virtual port, use the following com-

mand at the configuration level for the port:
[no] ha-conn-mirror
CLI Example
The following command sets the session synchronization address to

10.10.10.66, the IP address of the other ACOS device in this HA pair:
ACOS(config)#ha conn-mirror ip 10.10.10.66
The following commands access the configuration level for a virtual port
and enable connection mirroring on the port:
ACOS(config)#slb virtual-server vip1 10.10.10.100
ACOS(config-slb virtual server)#port 80 tcp
ACOS(config-slb virtual server-slb virtua...)#ha-conn-mirror

The following sections describe how to configure OSPF-related HA param-
eters.
OSPF Awareness of HA
The ACOS device uses HA-aware VIPs, floating IPs, IP NAT pools, and IP
range lists with route redistribution to achieve HA-aware dynamic routing.
However, by default, the OSPF protocol on the ACOS device is not aware
of the HA state (Active or Standby) of the ACOS device. Consequently, fol-
lowing HA failover of an ACOS device, other OSPF routers might continue

forwarding traffic to the Standby ACOS device (the former Active ACOS
device), instead of the new Active ACOS device.
Note: In Layer 3 inline mode, all VLANs on the ACOS device participate in
OSPF routing by default. (See “OSPF Support on Standby ACOS Device
in Layer 3 Inline Mode” on page 335.)
You can assign an additional cost to an ACOS device’s OSPF interfaces

when the HA status for any group on the device is Standby. If failover of
one or more HA groups from Active to Standby occurs, the ACOS device
does the following:
• Updates the cost of all its OSPF interfaces
• Sends Link-State Advertisement (LSA) updates to its OSPF neighbors

advertising the interface cost change
After an OSPF neighbor receives the LSA update, the neighbor updates its
OSPF link-state database with the increased cost of the links. The increased
cost biases route selection away from paths that use the Standby ACOS
device.
Similarly, if a failover results in HA status Active for all HA groups on an

ACOS device, the device removes the additional cost added for Standby sta-
tus from all its OSPF interfaces and sends LSA updates to advertise the
change. The reduced cost biases route selection toward paths that use the
Active ACOS device and away from paths that use the Standby ACOS
device.
Note: The additional cost for Standby status is removed only if the HA status for
all HA groups on the device is Active. Otherwise, if the status of any of
the groups is Standby, the additional cost remains in effect for all OSPF
interfaces on the device.
Enabling OSPF Awareness of HA

To enable OSPF awareness of HA, use the following command at the OSPF
configuration level.
[no] ha-standby-extra-cost num
The num option specifies the extra cost to add to the ACOS device’s OSPF
interfaces, if the HA status of one or more of the device’s HA groups is
Standby. You can specify 1-65535. If the resulting cost value is more than
65535, the cost is set to 65535.
Enter the command on each of the ACOS devices in the HA pair.

Manually Synchronizing Configuration Information
OSPF Support on Standby ACOS Device in Layer 3 Inline Mode

In HA Layer 3 inline mode deployments, OSPF adjacencies are automati-
cally formed between the Active and Standby ACOS devices and all OSPF
routers on all VLANs.
To limit OSPF adjacency formation to a specific VLAN only, explicitly

configure adjacency formation for that VLAN. In this case, OSPF adja-
cency formation does not occur for any other VLANs. Use the following
ha ospf-inline vlan vlan-id

Note: This section describes how to manually synchronize the configuration.
You can use the ACOS Virtual Chassis System (aVCS) to automate con-
figuration synchronization. See “Configuration Synchronization without
Reload” on page 505.
You can use config-sync options to manually synchronize some or all of the
following:
• Startup-config, to the other ACOS device’s startup-config or running-
config
• Running-config, to the other ACOS device’s running-config or startup-
config)
• Data files:
• SSL certificates and private-key files
• aFleX files
• External health check files
• Black/white-list files
Note: Manual config-sync is not required if the ACOS device is running aVCS.
Requirements
Session synchronization (connection mirroring) is required for manual con-
fig sync. Config sync uses the session synchronization link. To enable ses-
sion synchronization, see “Enabling Session Synchronization” on page 332.
SSH management access must be enabled on both ends of the link. (See
“Securing Admin Access by Ethernet” on page 471.)

The link must be on a data interface, not on the management interface.
Configuration Items That Are Backed Up

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

Configuration Items That Are Not Backed Up
The following configuration items are not backed up during HA configura-

tion synchronization:
• Interface-specific management access settings (the ones described in
“Securing Admin Access by Ethernet” on page 471)
• Hostname
• MAC addresses
• Management IP addresses
• Static Trunks or VLANs
• LACP settings
• Interface settings
• OSPF or IS-IS settings
• ARP entries or settings
Reload of the Target ACOS Device

In certain cases, the target ACOS device is automatically reloaded, but in
other cases, reload is either optional or is not allowed.
Table 17 lists the cases in which reload is automatic, optional, or not

allowed.
TABLE 17 Reload of Target ACOS Device After Config-Sync

Status of Target
Admin Role ACOS Device* Target Config Reload?
Root or Super User Standby startup-config Automatic
(Read-Write) running-config Automatic
Active startup-config Optional†
Not reloaded by default
running-config Automatic
Partition Write Standby startup-config Not Allowed
running-config Not Allowed
Active startup-config Not Allowed
running-config Not Allowed
*. “Active” means the ACOS device is currently the active device for at least one HA group.
†. If the target ACOS device is not reloaded, the GUI Save button on the Standby ACOS device does not blink to indicate
unsaved changes. It is recommended to save the configuration if required to keep the running-config before the next
reboot.

An admin who is logged on with Root or Read-Write (Super Admin) privi-
leges can synchronize for all Role-Based Administration (RBA) partitions
or for a specific partition.
An admin who is logged on with Partition Write privileges can synchronize

only for the partition to which the admin is assigned, and can only synchro-
nize to the startup-config on the other device. The with-reload and to-run-
ning-config options are not available to Partition Write admins.
Caveats
Before synchronizing the Active and Standby ACOS devices, verify that
both are running the same software version. HA configuration synchroniza-
tion between two different software versions is not recommended, since
some configuration commands in the newer version might not be supported
in the older version.
The HA configuration synchronization process does not check user privi-

leges on the Standby ACOS device and will synchronize to it using read-
only privileges. However, you must be logged onto the Active ACOS
device with configuration (read-write) access.
If the configuration includes Policy-based SLB (black/white lists), the time

it takes for synchronization depends on the size of the black/white-list file.
This is because the synchronization process is blocked until the files are
transferred from active to standby.
Do not make other configuration changes to the Active or Standby ACOS

device during synchronization.
Data that is synchronized from a Standby ACOS device to an Active ACOS

device is not available on the Active ACOS device until that device is
rebooted or the software is reloaded.

Performing HA Synchronization
To synchronize the ACOS devices in an HA configuration, use the CLI
commands described below.
USING THE GUI

1. Select Config Mode > System > HA.
2. Click on the Config Sync tab.
3. In the User and Password fields, enter the admin username and pass-
word for logging onto the other ACOS device.
4. If partitions are configured on the ACOS device, select whether to syn-

chronize all partitions or only the currently selected partition. (For infor-
mation, see “Synchronizing the Configuration” on page 212.)
5. Next to Operation, select the information to be copied to the other
ACOS device:
• All – Copies all the following to the other ACOS device:
• IP NAT configuration
• Access control lists (ACLs)
• Health monitors
• Policy-based SLB (black/white lists)
• SLB
• FWLB
• GSLB
• Data files (see below)
The items listed above that appear in the configuration file are cop-
ied to the other ACOS device’s running-config.
• Data Files – Copies only the SSL certificates and private-key files,
aFleX files, External health check files, and black/white-list files to
the other ACOS device
• Running-config – Copies everything listed for the All option, except
the data files, from this ACOS device’s running-config
• Startup-config – Copies everything listed for the All option, except
the data files, from this ACOS device’s startup-config
6. Next to Peer Option, select the target for the synchronization:
• To Running-config – Copies the items selected in step 5 to the other
ACOS device’s running-config

• To Startup-config – Copies the items selected in step 5 to the other
ACOS device’s startup-config
7. To reload the other ACOS device after synchronization, select With
Reload. Otherwise, the other ACOS device is not reloaded following the
synchronization.
Note: In some cases, reload of the other ACOS device either is automatic or is
not allowed. See Table 17 on page 337.
8. In the Destination IP field, enter the IP address of the other ACOS

device.
9. Click OK.
USING THE CLI

The ha sync commands are available at the global configuration level of the
CLI.
Note: The all-partitions and partition partition-name options are applicable on

ACOS devices that are configured for Role-Based Administration (RBA).
For information, see “Role Based Administration Private Partition” on
page 219.
To synchronize data files and the running-config, use the following com-
mand:
ha sync all
to-running-config}
ipaddr
Note: The ipaddr option specifies the IP address of the other ACOS device.
In some cases, reload of the other ACOS device either is automatic or is
not allowed. See Table 17 on page 337.
To synchronize the Active ACOS device’s startup-config to the Standby

ACOS device’s startup-config or running-config, without also synchroniz-
ing the data files, use the following command:
to-running-config}
ipaddr

Tip for Ensuring Fast HA Failover
To synchronize the Active ACOS device’s running-config to the Standby
ACOS device’s running-config or startup-config, without also synchroniz-
ing the data files, use the following command:
to-running-config}
ipaddr
To synchronize the data files by copying the Active ACOS device’s data
files to the Standby ACOS device, use the following command:
ha sync data-files
ipaddr

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

server-side router, configure a real server for each router.
To configure health checking of the gateway routers:

1. (Optional) Configure an ICMP health monitor.
For Layer 3 inline deployments, it is recommended to use very short
values (1 second) for the interval and timeout. (For examples of Layer 3
inline HA deployments for TCS, see the “Transparent Cache Switching”
chapter in the AX Series Application Delivery and Server Load Balanc-
ing Guide.)

2. Create an SLB real server configuration for each gateway. If you plan to
use a custom ICMP health monitor (previous step), apply the health
monitor to the server.
Perform these steps on both ACOS devices in the HA pair.
Note: The ACOS device also has an HA gateway health checking feature. This
feature also uses ICMP health monitors. However, if you use the HA gate-
way health checking feature, HA failover is triggered if a gateway fails a
health check. If you use real server configurations instead, as shown in the
following examples, HA failover is not triggered by a failed health check.
CLI Example – IPv4

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

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

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


HA To VRRP-A Migration
The current software allows you to automatically migrate your existing

High Availability (HA) configuration to Virtual Router Redundancy Proto-
col (VRRP-A) configuration.
VRRP-A is the A10 Thunder Series and the AX Series implementation of

the High Availability protocol that is completely different from the industry-
standard implementation of Virtual Router Redundancy Protocol (VRRP).
For purposes of operational familiarity, it borrows concepts from VRRP, but
is significantly different from VRRP. VRRP-A will not inter-operate with
VRRP.
In this release, VRRP-A, a High Availability (HA) implementation, is mutu-

ally exclusive of the HA feature and is configured separately and not as part
of the HA functionality.
Manual configurations can be time consuming and tedious. This automated

migration script saves you time and effort.
In the HA scenario, one ACOS device serves as an “Active” device, while a

second ACOS device serves as a “Standby” device. Issue the vrrp-a ha-
migration command on the Active and the Standby ACOS device to auto-
matically convert the existing HA configuration into a VRRP-A configura-
tion. Once your conversion is complete, VRRP-A will be operational after
you reload both devices.
Note: The vrrp-a ha-migration command must be run independently on both

the Active and the Standby devices.
Follow these steps before you launch the migration script.

• Back up your current configuration. Though the script creates its own
backup of the existing configuration, it is prudent that you create a copy
of the existing configuration. Store this file in case you need to revert to
your original configuration.
• Before you run the vrrp-a ha-migration command on the ACOS
devices, review your existing HA configuration file to address any
exceptions that will cause the automatic migration script to fail. Address
these exceptions by manually upgrading your HA configuration or by
deleting these configuration statements from your configuration file
before migrating your configuration. For a list of conversion exceptions,
review, “Migration Exceptions” on page 346. For high-level details on

HA and VRRP-A, refer to Table 18 on page 347. For details on com-

mands migrated from HA to VRRP-A, refer to Table 19 on page 348.
Once the conversion process from HA to VRRP-A is complete, if you wish

to revert to your HA configuration, use the vrrp-a ha-migration-restore
command.
Migration Exceptions
During the migration process, some conditions will cause the migration
command to fail. An HA configuration that does not contain any of the
following HA configuration exceptions will result in a successful
conversion to VRRP-A. Issue the migration command only after you have
removed or manually upgraded the following HA configuration statements.
Note: When you launch the migration script, it will pre-check your HA configu-
ration to ensure that no HA configuration exceptions exist. If it encounters
exceptions, the script will quit automatically without conversion to
VRRP-A.
Assuming no Virtual Chassis (VCS) has been configured, the following

exceptions will apply that will cause the HA migration command to fail:
• RBA partitions are encountered.
• Forward-L4-Packet-on-Standby is detected.
• L2 Inline Mode is detected. This includes support for HA Inline Mode

(preferred port), HA restart-time, and HA restart-port-list.
• L3 Inline Mode is detected. This includes support for HA L3 Inline
Mode and HA OSPF Inline mode.
• HA Parameters for Real Servers are detected. This includes support for
HA priority cost.
• HA Parameters for Real Ports are detected.
• Firewall Load Balancing (FWLB) is detected.
Note: If one of the seven exceptions defined above occur, a warning message
will be displayed on your screen and you will be asked to manually
migrate your configuration.

Differences between HA and VRRP-A

To understand the configuration differences between HA and VRRP-A at a
high-level, refer to the following table.
TABLE 18 Implementation Differences between HA and VRRP-A
Configuration High Availability VRRP-A
HA Connection Mirror You must indicate an IP address for The peer IP address is automatically
an HA Connection Mirror (ha conn- learned.
mirror ip 1.1.1.1).
Port Tracking Provides server and router interface Tracking is based on priority.
tracking.
Command Support HA supports the following com- VRRP-A does not support these
mands: commands.
ha inline-mode
ha l3-inline-mode
ha restart-port-list port-type
(available only for HA inline mode)
ha restart-time milliseconds
(available only for HA inline mode)
ospf-inline vlan vlan-id
(available only for HA L3-inline
mode)
During the process of migration, your HA commands will be converted in

the following manner:
Note: HA commands that do not have an equivalent command in VRRP-A will

cause the migration script to exit. These commands are shown as “Not
supported” under VRRP-A in the following table.

TABLE 19 Actual HA to VRRP-A Conversion

HA VRRP-A Migration Example
Global Parameters
ha id {1|2} [set-id num] vrrp-a set-id num ha id 1 set-id 1
vrrp-a set-id 1
vrrp-a device-id 1
ha group id num priority num vrrp-a vrid num ha group 1 priority 100
priority num vrrp-a vrid 1
priority 100
floating-ip ip-add ha-group num vrrp-a vrid num floating-ip 1.1.1.10 ha-group 1
floating-ip num vrrp-a vrid 1
floating-ip 1.1.1.10
ha interface ethernet port-num vrrp-a interface ethernet port-num ha interface
[router-interface | server-interface | [router-interface | server interface | ha interface ethernet 1 vlan 2
both] [no-heartbeat | vlan vlan-id] both] [no-heartbeat | vlan vlan-id]
ha interface ethernet 1 no-heartbeat
The VRRP-A tracking options are cre-
ha interface ethernet 1 server-inter-
ated per VRID. The migration script
face
will place the configuration under
each VRID. If an interface is under a ha interface ethernet 1 router-inter-
trunk, only the trunk will be tracked. face
vrrp-a interface ethernet 1 vlan 2

vrrp-a interface ethernet 1 no-
heartbeat
vrrp-a interface ethernet 1 server-
interface
vrrp-a interface ethernet 1 router-
interface
ha check vlan vlan-id timeout sec- track options ha check vlan 2 timeout 20
onds vlan vlan-id timeout seconds prior- vrrp-a vrid 1
ity-cost default tracking-options
vlan 2 timeout 20 priority 5
ha check gateway ipaddr gateway ipaddr priority-cost default ha check gateway 1.1.1.1
vrrp-a vrid 1
tracking-options
gateway 1.1.1.1 priority 5
ha conn-mirror ip ipaddr IP address is learned automatically None
ha preemption enable preempt-mode disable ha preemption-enable
vrrp-a vrid 1
preempt-mode disable
ha time-interval 100-ms-units vrrp-a hello-interval 100-ms-units ha time-interval 5
vrrp-a hello-interval 5


ha timeout-retry-count num vrrp-a dead-timer num ha timeout-retry-count 10
vrrp-a dead-timer 10
ha arp-retry num vrrp-a arp-retry num ha arp-retry 5
vrrp-a arp-retry 5
ha forward-l4-packet-on-standby Not supported None
Global Parameters for L2 Inline Mode
ha inline-mode [preferred-port] Not supported None
ha restart-time 100-msec-units Not supported None
ha restart-port-list Not supported None
Global Parameters for L3 Inline Mode
ha l3-inline-mode Not supported None
ha ospf-inline vlan vlan-id Not supported None
ha link-event-delay Not supported ha link-event-delay 20
vrrp-a track-event-delay 20
Parameters for Virtual Servers (appear under slb virtual-server)
ha-group group-id vrid group-id slb virtual-server v1 1.1.1.3
ha-group 1
vrid 1
ha-dynamic server-weight It will not be changed Configure a server and configure the
server weight.
Parameters for Virtual Service
ha-conn-mirror It will not be changed ha-conn-mirror
Parameters for Real Servers
ha-priority-cost weight ha-group Not supported None
group-id
Parameters for Real Ports
ha-group group-id Not supported None
Parameters for FWLB
ha-priority-cost weight ha-group Not supported None
group-id
Parameters for IP NAT
Options with ip nat pool, ipv6 nat ip nat pool pool-name starting- ip nat pool abc 1.1.1.20 1.1.1.30 net-
pool, or ip nat ip-nat pool-address ending- mask /24 ha-group-id 1
ip-nat pool-address netmask
ip nat pool abc 1.1.1.20 1.1.1.30 net-
pool-mask vrid vrid-num
mask /24 vrid 1


Parameters for IP Routes
ha check route des/mask priority- This appears under track options: ha check route 1.1.1.1 /24 gateway
cost weight [gateway ip addr | ipv6 route dest/mask priority-cost weight 2.2.2.2 priority-cost 10
addr] [protocol [gateway ipaddr | ipv6addr] [proto- vrrp-a vrid 1
{static|dynamic}][distance num] col {static | dynamic}][distance tracking-options
num]
route 1.1.1.0 255.255.255.0
gateway 2.2.2.2 priority-cost 10
Migrating from HA to VRRP-A
USING THE GUI

This feature is not supported in the GUI for this release.
USING THE CLI

To migrate your existing HA configuration into VRRP-A, follow these
steps. Begin with migrating your Standby ACOS device first before your
Active ACOS device:
3. From the configuration mode, execute the vrrp-a ha-migration com-

mand on the ACOS device designated as the Standby device:
vrrp-a ha-migration
In case the migration script encounters any configuration scenarios that
it cannot handle, it will quit.
Note: Your current configuration will be changed.

Refer to “Migration Exceptions” on page 346 or Table 19 on page 348.
You must remove the exceptions (HA configuration statements) before
reissuing the vrrp-a ha-migration command.
4. From the privileged exec mode, “ACOS-Active#, reload the standby

ACOS device. Issue the reload command. You cannot issue this com-
mand in configuration mode.
Note: Make sure that you do not issue the write-memory command. Before the
ACOS device commences the reload, be sure to say no to the question:
System configuration has been modified. Save?
[yes/no]:

When it reboots successfully, this device will automatically be placed in

standby state. For it to become the active device, from the global config-
uration mode, issue the no vrrp-a force-self-standby command.
Your HA configuration on the Standby device is now complete. Repeat
the same steps on the Active device.
Once both the Active and the Standby ACOS devices are reloaded, ver-
ify that you are successfully able to use VRRP-A as opposed to HA and
that everything is working as expected.
5. To check your VRRP-A configuration, issue the show vrrp-a com-

mand or the show vrrp-a config command. See if you can successfully
access other VIPs.
The following example shows successful completion of the migration
command on an Active ACOS device:
ACOS-Active(config)#vrrp-a ha-migration
ACOS boots from hard disk primary. VRRP-A migration only effects on hard disk
primary.
Migrate from HA to VRRP-A therein? (y/n) y
HA Migration Starts...
89 lines of configuration are processed
Replacing old config file with new config file.
Configure file has been replaced!
HA configuration has been replaced by VRRP-A configuration! Please reload the
system to finalize the migration!
Warning: After reloading, all vrids in all partitions will be forced standby!
Please manually remove forced-standby setting with command: no vrrp-a force-
self-standby all-partitions
Before you reload the ACOS device, check your running configuration to see that
no VRRP-A configuration exists:
ACOS-Active(config)#show running | sec vrrp-a
ACOS-Active(config)#

From the privileged EXEC level, reload your ACOS device:

ACOS#reload
System configuration has been modified. Save? [yes/no]:no
Do you wish to proceed with reload? [yes/no]:yes
ACOS is reloading now. Please wait....

ACOS has reloaded successfully.
AX3030(LOADING)#
After you reload, view your running configuration to see that VRRP-A has
been configured on your ACOS device
ACOS#show running | sec vrrp-a
vrrp-a device-id 2
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid default
tracking-options
interface ethernet 3 priority-cost 15
vrrp-a vrid 1
priority 100
tracking-options
vrrp-a interface ethernet 1 router-interface
vrrp-a interface ethernet 2 server-interface no-heartbeat
Reverting to HA from VRRP-A

To restore an existing HA configuration, you can revert from VRRP-A con-
figuration using the vrrp-a ha-migration-restore command. This com-
mand will only work if you have previously migrated your HA
configuration to VRRP-A using the migration script.

USING THE GUI
USING THE CLI
To replace the VRRP-A configuration with an HA configuration, use the

following command:
vrrp-a ha-migration-restore
Reboot your system to restore your HA configuration.
CLI Example
The following example displays how the vrrp-a ha-migration-restore
command will restore your HA configuration:
ACOS-Active(config)# vrrp-a ha-migration-restore
ACOS boots from hard disk primary. Migration restore only effects on hard disk
primary.
Trying to find backup config file to replace current config file.
The backup files is found.
Proceed to replace current config file? (y/n) y
System has been successfully restored! Please reload system!


Overview
VRRP-A High Availability
This chapter describes VRRP-A.VRRP-A is the A10 Thunder Series and

the AX Series implementation of the High Availability protocol that is com-
pletely different from the industry-standard implementation of Virtual
Router Redundancy Protocol (VRRP). For purposes of operational familiar-
ity, it borrows concepts from VRRP, but is significantly different from
VRRP. VRRP-A will not inter-operate with VRRP.
VRRP-A simplifies configuration of multi-system redundancy, and allows

up to 8 ACOS devices to serve as mutual backups for IP addresses.
VRRP-A is supported only on ACOS devices that are deployed in gateway

(route) mode. Transparent mode deployments (inline deployments) are not
supported. For transparent/inline deployments, use the older High Availabil-
ity (HA) feature instead.
Overview
VRRP-A can provide redundancy for the following IP resources:
• Virtual server IP addresses (VIPs)
• Floating IP addresses used as default gateways by downstream devices
• IPv6 NAT pools
• IPv4 NAT pools
• IPv4 static range lists and individual mappings for inside source NAT
Virtual Router ID
Each IP resource can be associated with a virtual router ID (VRID). At any
given time, the VRID is active on one of the devices in the VRRP-A set.
The VRID is in standby state on the other devices. If network conditions
change (the active device becomes unavailable or a link goes down), a
standby device can assume the active role for the VRID.
Figure 54 shows a simple VRRP-A deployment with 2 devices.

Overview
FIGURE 54 VRRP-A
In this example, a pair of ACOS devices are configured with private parti-
tions. The VIPs and other IP resources in each partition are backed up by the
partition’s VRID. (Partition support and VRIDs are described in more detail
below.)
At any given time, one of the devices is the active device for a VRID and
the other device is the standby for the VRID, as shown in Figure 55.
FIGURE 55 VRRP-A Active and Standby for each VRID
In this example, device 1 is the active device for the shared partition and for
private partition CorpB. Device 2 is the standby device for these partitions.
Likewise, device 2 is the active device for private partitions CorpA and
CorpC, and device 1 is the standby for these partitions.
Partition Support
VRRP-A is supported on ACOS devices configured with Role-Based
Administration (RBA) partitions, as long as Layer 2/3 virtualization is
enabled in each partition. Layer 2/3 virtualization allows each private parti-
tion to have its own VRID, independent from the VRIDs belonging to other
partitions.

Overview
By default, each partition has a single, independent VRID (VRID 0). Private
partitions can have one VRID each. If the device is not configured with
RBA partitions, the device has a shared partition only, which has a single
VRID by default. Optionally, you can enable support for 32 independent
VRIDs in the shared partition.
Note: Use of VRRP-A on an ACOS device that has RBA partitions that are not
enabled for Layer 2/3 virtualization has not been tested and is not sup-
ported.
Default VRID
By default, the shared partition and each private partition in which

Layer 2/3 virtualization is enabled has its own VRID. The VRID name is
“default”. (The numerical ID for the default VRID is 0.) The default VRID
is disabled by default.
When the default VRID is enabled, IP resources that belong to a partition

are automatically assigned to its default VRID. For example, when a parti-
tion admin adds a virtual server, the VIP address is automatically assigned
to the default VRID.
Admins with write privileges for the partition can assign a floating IP
address to the partition’s VRID. Generally, the floating IP address provides
redundancy for the default gateway IP address used by downstream devices.
Parameters related to selection of the active device and to failover also can
be configured. (See “Active / Standby Device Selection” on page 361.)
Non-Default VRID
Private partitions support non-default VRIDs in addition to the default
VRID. Previously, private partitions only supported the default VRID,
VRID 0. Now, private partitions support VRIDs 1-7 and continue to support
the default VRID 0.
The shared partition will support 1-31 VRIDs. To configure a non-default

VRID. refer to “Configuring the Non-default VRID” on page 391.
Leader and Follower VRIDs
With an increase in the number of configurable VRIDs to 512, you may

configure a VRID as a “leader” VRID and some others as “follower”
VRIDs. The benefit of configuring the leader VRID is that when you are run
the risk of consuming all your resources, one VRID can serve as the leader

Overview
and others can be configured to operate as followers. This means that only
on one VRID will you be able to configure all capabilities, such as configur-
ing the failover policy template, the preempt mode, priority, and tracking
options, while in the follower VRID, you can only configure Floating IP
Addresses.
ACOS 2.7.1 supports a maximum of 512 VRIDs on one device. Any time
this number is exceeded, VRIDs are automatically configured as follower
VRIDs or can be explicitly configured to be added as a follower VRID. To
configure a leader or a follower VRID. refer to “Configuring a Leader and
Follower VRID” on page 392.
VRID Virtual MAC Addresses

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

Overview
Floating IP Addresses
VRRP-A supports use of floating IP addresses. Floating IP addresses can
reside on any device in the VRRP-A set, and always reside on the device
that is currently active. Because floating IP addresses are always reachable
regardless of the VRRP-A states of individual devices, the floating IP
addresses provide network stability.
In a typical VRRP-A deployment, floating IP addresses are configured for

each of the ACOS device interfaces that are used as nexthop interfaces by
other devices. Figure 56 shows a simple example.
FIGURE 56 Floating IP Address
In this example, a device uses ACOS device IP address 10.8.8.6 as its

default gateway. This address is configured as a floating IP address on the
ACOS device, and always resides on the active VRRP-A device.
Because the address is configured as a floating IP address on the ACOS

device, the address remains reachable by the client even if a VRRP-A
failover occurs. For example, if VRRP-A fails over from device 2 to device
1, then the floating IP address also moves to device 1.
Note: A floating IP address can not be the same as an address that already
belongs to a device. For example, the IP address of an ACOS device inter-
face can not be a floating IP address.

Overview
Advertisement of the Floating IP MAC Address After Failover
When a floating IP address moves from one ACOS device to another fol-
lowing failover, the MAC address associated with the floating IP address
changes.
To help other devices find a floating IP address following failover, the new
active ACOS device sends IPv4 gratuitous ARPs (for an IPv4 floating IP
address) or ICMPv6 neighbor advertisements (for an IPv6 floating IP
address). The other devices in the network learn the new MAC address from
the gratuitous ARPs or neighbor advertisements.
Configuration Synchronization
VRRP-A supports the following methods of configuration synchronization:
• Automated – Uses A10 Virtual Chassis System (aVCS) to automatically
synchronize the configuration. See “Automated Configuration Synchro-
nization” on page 463.
• Manual – See “Manually Synchronizing the Configuration” on
page 379.
Session Synchronization
VRRP-A uses one active device and one standby device for a given VRID.
If session synchronization (also called connection mirroring) is enabled, the
active device backs up active sessions on the standby device.
Session synchronization applies primarily to Layer 4 sessions. Session syn-

chronization does not apply to DNS sessions. Since these sessions are typi-
cally very short lived, there is no benefit to synchronizing them. Likewise,
session synchronization does not apply to NATted ICMP sessions or to any
static NAT sessions. Synchronization of these sessions is not needed since
the newly active device will create a new flow for the session following
failover.
Session synchronization is disabled by default and can be enabled on indi-

vidual virtual ports.

Overview
Active / Standby Device Selection

One device in the VRRP-A set can be active at any given time for a given
VRID. The active device for a given VRID is selected based on VRRP-A
priority. The device with the highest VRRP-A priority for a VRID becomes
the active device for that VRID. Each VRID has its own priority value,
which can be 1-255. The default is 150. Figure 57 shows an example.
FIGURE 57 Selection of Active Device
In this example, the priority of VRID 0 has been changed to 255 for the
shared partition and private partition CorpB on device 1, and for partitions
CorpA and CorpC on device 2. The active/standby state of each VRID on
each device is based on these priority settings.
If more than one device has the highest priority value, the device with the
lowest device ID becomes the active device. For example, if the VRID pri-
ority is left set to the default value on all devices, device 1 becomes the
active device for the VRID.
VRRP-A selects the device that has the second-highest priority for a VRID
as the standby device for the VRID. In VRRP-A deployments on more than
2 devices, if more than one device has the second-highest priority value, the
device with the lowest device ID becomes the standby device. Figure 58
shows an example.

Overview
FIGURE 58 Selection of Standby Device
The priority for VRID 0 in partition CorpB is set to 255 on device 1 but is
left to its default value on the other devices. Since device 2 is has the lowest
device ID among the remaining devices, device 2 becomes the standby for
the VRID. The other devices are backups. If session synchronization is
enabled, sessions are copied from device 1 to device 2. If a failover occurs,
device 2 becomes the active device and device 1 becomes the standby
device. Sessions are not synchronized to the backups.
If the standby device becomes unavailable or its priority value is reduced

below the priority value on another backup device, the other device
becomes the new standby for the VRID, as shown in Figure 59.

Overview
FIGURE 59 Selection of New Standby Device
Note: In VRRP-A deployments of 3 or more devices, moving the active role to a

backup other than the standby can cause loss of synchronized sessions,
since sessions are synchronized only from the active device to the standby
device.
To avoid loss of sessions in this case, first change the priority on the
backup so that it will assume the role of standby. Then, when VRRP-A
fails over, the standby will have the synchronized sessions.
Failover
Failover of a VRID from the active ACOS device to the standby ACOS
device can be triggered by any of the following events:
• The standby ACOS device stops receiving VRRP-A hello messages
from the active ACOS device.
• The VRRP-A priority on the active device is dynamically reduced
below the priority on the standby device. The priority can be dynami-
cally reduced when a tracked default gateway, data port, or VLAN goes
down, a tracked route is not in the data route table, or a VIP’s real server
fails its health check.

Overview
• The VRRP-A priority on the active device is manually reduced below
the priority on the standby device by an administrator, and pre-emption
is enabled.
• The force-self-standby option is used on the active device by an admin-
istrator.
Policy-based Failover
In this VRRP-A provides flexible event tracking and policy-based failover

support. This feature allows policy-based failover even when VRRP-A pre-
emption is disabled and the ACOS device typically would remain in a
Active state, despite VRID priority changes. It allows for event-based
failover once a tracked event occurs.
For more information, see “VRRP-A Configuration and Monitoring Using

the GUI” on page 397.
VRRP-A Hello Messages

The active ACOS device for a VRID periodically sends hello messages to
the standby ACOS device and other backup devices. The hello messages
indicate that the active device for the VRID is still operating.
If the standby device stops receiving hello messages from the active device,
operation for the VRID fails over to the standby device. The device to
which operation fails over becomes the new active device for the VRID.
Hello Message Timers

By default, the active device sends hello messages every 200 milliseconds
(ms). Standby devices, by default, wait a maximum of 1 second for a hello
message. If no hello message is received within 1 second, failover occurs.
The hello interval and maximum wait time (dead time) are configurable, on
a device basis. Configuration of the VRRP-A timers requires write access to
the shared partition. The timers can not be configured by partition admins.
Hello Message Destination Addresses

VRRP-A sends hello messages to the following addresses:
• IPv4 multicast address 224.0.0.210, MAC address 01:00:5e:00:00:D2
• IPv6 link-local multicast address FF02::D2, MAC address

33:33:00:00:00:D2

Overview
Dynamic Priority Reduction
Depending on configuration, failover can be triggered even if the active

device is still operational. For each VRID, each device begins with a stati-
cally configured priority for the VRID.
You can configure the priority of a VRID to be dynamically reduced based

on changes in system or network conditions. For example, you can config-
ure link tracking on an Ethernet port. If the link goes down, the VRID prior-
ity on the device is reduced by the configured amount. Figure 60 shows an
example.
FIGURE 60 Failover Based on Dynamic Priority Reduction
In this example, link tracking is enabled for Ethernet port 6, and configured
to reduce the VRID priority by 155 if the link goes down. Device 1 has the
higher configured priority value for VRID 0 in partition CorpB, and is the
active device. However, if the link on Ethernet port 6 goes down, the prior-
ity is dynamically reduced below the priority value on device 2. Device 2
therefore becomes the active device for the VRID.
The priority value of a VRID on a device can be dynamically reduced based

on any of the following events:
• Lost connection to a default gateway – VRRP-A periodically tests con-
nectivity to the IPv4 and IPv6 default gateways by pinging them. If a
gateway stops responding, VRRP-A reduces the device’s priority for the
VRID. The priority value to subtract can be specified individually for
each gateway.
• Lost link on Ethernet data port – If the link goes down on an Ethernet
data port, VRRP-A reduces the device’s priority for the VRID. The pri-

Overview
ority value to subtract can be specified individually for each Ethernet
data port.
• Lost link on trunk – If the trunk or individual ports in the trunk go down,
VRRP-A reduces the device’s priority for the VRID. The priority value
to subtract can be specified for the trunk and for individual ports within
the trunk.
• Lost data route – If an IPv4 or IPv6 route matching the specified options
is not in the data route table, VRRP-A reduces the device’s priority for
the VRID.
• VLAN inactivity – If VRRP-A stops detecting traffic on a VLAN,
VRRP-A reduces the device’s priority for the VRID. The priority value
to subtract can be specified individually for each VLAN.
• Real server health-check failure – If a real server in a virtual port’s ser-
vice group fails a health check, VRRP-A reduces the device’s priority
for the VRID. This type of tracking can be configured an individual VIP
basis.
By default, none of the dynamic failover triggers are configured. They can
be configured on an individual partition basis.
Note: If a tracked interface is a member of a trunk, only the lead port in the
trunk is shown in the tracking configuration and in statistics. For example,
if a trunk contains ports 1-3 and you configure tracking of port 3, the con-
figuration will show that tracking is enabled on port 1. Likewise, tracking
statistics will show port 1, not port 3. Similarly, if port 1 goes down but
port 3 is still up, statistics still will show that port 1 is up since it is the
lead port for the trunk.
Note: If you track a trunk that does not exist, VRRP-A will not reduce the
device priority.
To track a trunk port within a private partition, you must verify that the
tracked port is actually being used within that private partition (for exam-
ple, verify that the port is used in a VLAN of that private partition).
If the tracked trunk is down, VRRP-A reduces the device priority based
on the trunk value and ignores the status of the ports within the trunk.
If the tracked trunk is up, VRRP-A checks the ports within the trunk, and
if any of them are down, VRRP-A reduces the device priority (1x config-
ured port priority). If two ports are down, VRRP-A reduces the device
priority by twice the priority assigned to the ports within the trunk (2x
configured port priority).
Note: VLAN tracking is supported only for the shared partition.

Overview
Priority Calculation
Every few seconds, VRRP-A recalculates the priority for each VRID on the
active device for the VRIDs.
To calculate the priority, VRRP-A subtracts the priority values for all
optional failover trigger events that have occurred from the configured pri-
ority value. The lowest value to which the priority can be reduced is 1.
Once the link or server health is restored, the failover trigger event is no lon-
ger occurring and the priority value is not subtracted during the next priority
calculation.
Track Event Delay

To prevent unnecessary failovers caused by brief, temporary link or server
health changes, VRRP-A uses a track event delay. The track event delay is
the number of seconds a failover-causing event must persist before failover
occurs.
For example, if the track event delay is 5 seconds, and a tracked link goes
down for 3 seconds, then comes back up, no failover is triggered. Failover is
triggered only if the link stays down for at least 5 seconds.
The track event delay can be from 1-tenth second to 10 seconds. The default
is 3 seconds.
Pre-emption
Pre-emption allows failover to be triggered by manually changing the prior-
ity on one or more devices so that the active device no longer has the high-
est priority for the VRID.
Pre-emption is enabled by default. If pre-emption is disabled, failover is not

triggered by manual priority changes.
Pre-emption can be configured on an individual VRID basis, by shared par-

tition admins and private partition admins.
Pre-emption Delay
If VRRP-A pre-emption is enabled, failover can be triggered by VRRP-A

configuration changes, in addition to network changes. By default, when
pre-emption is enabled, failover occurs as soon as 3 seconds after an appli-
cable configuration change takes effect.
This release enables you to configure a delay between VRRP-A configura-

tion changes and the failover that occurs due to the changes.

Overview
Optionally, you can configure a preemption delay value, 1-255. The default
VRRP-A preemption delay is 6 seconds (60 units of 100 ms). You can glob-
ally set the delay to a value from 100 ms (1 unit of 100 ms) to 25.5 seconds
(255 units of 100 ms). Preemption delay is only triggered and used when
VRRP-A is configured in a multiple ACOS device setup. Failover is only
triggered through priority changes. When VRRP-A is configured on 2
ACOS devices, with one serving as the Active device and the other as the
Standby device, changing the priority will cause an instant failover within 1
to 3 seconds.
In deployments where many sessions are synchronized, setting the pre-emp-

tion delay to a longer value can help ensure there is time for session syn-
chronization to be completed before failover.
Force-self-standby
The force-self-standby option provides a simple method to force a failover,
without the need to change VRID priorities and use pre-emption.
The option can be entered by shared partition admins and private partition
admins. If entered in the shared partition, the option applies to all VRIDs on
the device. If entered in a private partition, the option applies to all VRIDs
within that partition but does not affect VRIDs in other partitions.
The option remains in effect until one of the other failover triggers occurs or
the device is reloaded or rebooted. The option is not added to the configura-
tion and does not persist across reloads or reboots.
VRRP-A Interfaces
VRRP-A sends hello messages and session synchronization messages on
the device’s VRRP-A interfaces.
Each ACOS device providing VRRP-A for a VRID must have at least one
Up Ethernet interface that can reach the other ACOS devices. If an ACOS
device can not receive hello messages from the other devices for the VRID,
the ACOS device's VRRP-A state becomes Active. In this case, there is
more than one active VRRP-A device for the same VRID, which is invalid.
One of the active VRRP-A devices is the ACOS device that does not have a
connection to the other devices. The other active VRRP-A device is the
ACOS device that can still reach the other ACOS devices (standby VRRP-
A devices).
By default, no VRRP-A interfaces are explicitly configured. In this case,

VRRP-A uses all Up Ethernet interfaces to send and listen for hello mes-

Overview
sages. For an interface that belongs to more than 1 VLAN, the ACOS
device uses the lowest VLAN ID to which the interface belongs.
If a data interface has both IPv4 and IPv6 addresses, the primary IPv4
address is used.
Admins with write privileges for the shared partition can explicitly specify
the ACOS device interfaces to use as VRRP-A interfaces. In this case, the
specified interfaces are used as VRRP-A interfaces by the shared partition
and by all private partitions in which Layer 2/3 virtualization is enabled.
Explicitly Configured VRRP-A Interfaces (optional)
Optionally, you can explicitly configure individual interfaces to act as

VRRP-A interfaces. In this case, the ACOS device uses only the configured
VRRP-A interfaces for hello messages.
For individual Layer 2/3 virtualization (L3V) partitions, the interface
requirement differs depending on whether VRRP-A interfaces are explicitly
configured:
• If no VRRP-A interfaces are explicitly configured (the default situa-
tion), each L3V partition must have at least one Ethernet interface that
can reach the other L3V partitions for the VRID.
• If at least one interface in the shared partition is explicitly configured as
an VRRP-A interface, that interface is used for the shared partition's
VRID hello messages, and for the hello messages of all the VRIDs in
the L3V partitions.
VRRP-A Interface Types and VRRP-A State

Changes to the state of a VRRP-A interface can trigger a failover. By
default, the VRRP-A state of an interface can be Up or Down. Optionally,
you can specify the VRRP-A interface type as one of the following:
• Server interface – A real server can be reached through the interface.
• Router interface – An upstream router (and ultimately, clients) can be

reached through the interface.
• Both – Both a server and upstream router can be reached through the
interface.
Note: In the current release, the interface type is informational only. This setting
does not affect VRRP-A operation or interface tracking.

Overview
Preferred Receive Interface for Session Synchronization
By default, VRRP-A on a backup device automatically selects the Ethernet

interface on which to receive synchronized sessions. The ACOS device pro-
vides an option that enables you to specify the Ethernet interface(s) on
which it is preferred to receive synchronized sessions.
USING THE GUI

1. Select Config Mode > System > VRRP-A > VRRP-A Global.
2. Click below the Preferred Session Sync Port to display the configuration
area for the feature.
3. Select the Ethernet interface from the Interface drop-down list.
4. If the interface belongs to more than one VLAN, enter the applicable
VLAN ID in the VLAN ID field.
5. Repeat for any additional interfaces.
6. Click Add.
7. Click OK.
USING THE CLI

To specify the Ethernet interface on which to receive synchronized sessions,
use the following command at the global configuration level for the device
that will receive the session information:
[no] vrrp-a preferred-session-sync-port ethernet

portnum
Comparison of VRRP-A and HA

VRRP-A includes numerous improvements over the HA feature available in
AX releases earlier than 2.6. The older implementation is still supported for
backwards compatibility. However, an ACOS device running AX Release
2.6 or later can run VRRP-A or HA but not both.
• If you are deploying ACOS device redundancy for the first time, it is
recommended to use VRRP-A.
• If you are upgrading ACOS devices that run the earlier implementation
of HA, it is not required to change the configuration from HA to VRRP-

Overview
A. However, if you use RBA partitions or plan to use aVCS, you might
want to consider migrating to VRRP-A.
Table 20 compares the features in VRRP-A and the earlier implementation

of HA.
TABLE 20 Feature Comparison – VRRP-A and HA

Feature VRRP-A Earlier Implementation of HA
Private partition support Each private partition in which Layer IP resources are shared with other par-
2/3 virtualization is enabled has its titions and can be added to an HA
own VRID. group for backup.
IP resources belonging to the partition
are automatically added to the VRID.
Capacity Up to 8 devices can provide redun- Maximum of 2 devices can provide
dancy as a set. redundancy.
The active device for a resource can An active device can have 1 other
have up to 7 other devices available as device as a standby.
potential standbys.
Configuration requirements Only minimal configuration is Configuration of HA is more complex
required. On each device in the than configuration of VRRP-A.
VRRP-A set:
1. Specify the device ID.
2. Enable VRRP-A.
IP resources that can be backed • Virtual server IP addresses (VIPs) • Virtual server IP addresses (VIPs)
up • Floating IP address used as default • Floating IP address used as default
gateway by downstream devices gateway by downstream devices
• IPv4 NAT pools • IPv4 NAT pools
• IPv6 NAT pools • IPv6 NAT pools
• IPv4 static range lists and individ- • IPv4 static range lists and individ-
ual mappings for inside source NAT ual mappings for inside source NAT
• Source address for IPv6 router
advertisements
• FWLB virtual firewall address
Configuration synchronization If A10 Networks Virtual Chassis Sys- Must be performed manually
tem (aVCS) is configured and
enabled, it automatically performs
configuration synchronization. Other-
wise, configuration synchronization
must be performed manually.
See the following:
• “Automated Configuration Syn-
chronization” on page 463
• “Manually Synchronizing the Con-
figuration” on page 379

Overview
TABLE 20 Feature Comparison – VRRP-A and HA (Continued)
Feature VRRP-A Earlier Implementation of HA
Session synchronization Must be enabled manually on individ- Must be enabled manually on individ-
ual virtual ports ual virtual ports
Applies only to Layer 4 (TCP or Applies only to Layer 4 (TCP or
UDP) sessions UDP) sessions
Peer automatically selected based on Requires manual configuration of peer
current VRRP-A priority IP address
Failover triggers Failover can be triggered on individ- Failover can be triggered on individ-
ual VRID basis, manually or dynami- ual HA group basis, manually or
cally. dynamically.
(See “Failover” on page 363.)
Pre-emption Supported Supported
Enabled by default Disabled by default
Configurable threshold No threshold
VRRP-A Parameters
Table 20 lists the VRRP-A parameters you can configure.
Note: In the current release, VRRP-A is supported in the GUI. For details, refer
to “VRRP-A Configuration and Monitoring Using the GUI” on page 397
TABLE 21 VRRP-A Parameters

System-Wide Parameters
VRRP-A set ID VRRP-A domain. All devices that will provide 1-7
backup for a given VRID must belong to the same Default: 1
VRRP-A set.
[no] vrrp-a set-id num
Device Parameters
VRRP-A state State of VRRP-A on the device. Enabled or disabled
[no] vrrp-a enable Default: disabled
VRID Virtual router ID. IP resources that are backed up by 1-31 or “default”
VRRP-A are associated with the VRID. Default: “default”
[no] vrrp-a vrid {num | default}
Note: The num option applies only to the shared
partition. In private partitions, only the default
option is applicable.

Overview
TABLE 21 VRRP-A Parameters (Continued)
ARP repeat Number of additional IPv4 gratuitous ARPs or 1-255
count ICMPv6 neighbor advertisements, in addition to the Default: 4 additional gratuitous ARPs
first one, an ACOS device sends after transitioning by default, for a total of 5.
from standby to active.
[no] vrrp-a arp-retry num
Dead timer Number of hello intervals during which a backup 2-255
device will wait for a hello message from the active Default: 5
device, before beginning failover.
[no] vrrp-a dead-timer num
Device ID Unique ID of the device within the VRRP-A set. 1-8
[no] vrrp-a device-id num Default: not set
Use of the Disables use of the default VRID in the shared parti- Enabled or disabled
default VRID in tion and all private partitions. Default: enabled.
the shared parti- Note: Disabling the default VRID allows you to use
tion VRIDs 1-31 instead of VRID 0 (the default VRID)
in the shared partition. In private partitions, dis-
abling the default VRID disables VRRP-A.
[no] vrrp-a disable-default-vrid
Hello interval Interval at which the active device sends VRRP-A 1-255 units of 100 milliseconds (ms)
hello messages to the backup devices. each
[no] vrrp-a hello-interval Default: 200 ms
100-msec-units
Host ID Append VRID that is used to carry the host ID information Shared Partition – 1-31 or default
to VRID in its heartbeat message. Default: Not set
VRRP-A Interfaces used for VRRP-A management. ACOS device Ethernet interfaces
interfaces Note: This option is configurable only in the shared Default: All up interfaces in a partition
partition. If you use this option to explicitly specify are VRRP-A interfaces for that parti-
VRRP-A interfaces, the interfaces are used by the tion. (See “VRRP-A Interfaces” on
shared partition and by all private partitions in page 368.)
which Layer 2/3 virtualization is enabled.
Note: In the current release, the interface type spec-
ified by this parameter is informational only. This
setting does not affect VRRP-A operation or inter-
face tracking.
[no] vrrp-a interface
ethernet port-num
[router-interface |
server-interface | both]

Overview
Track event Delay waited by the ACOS device before failover 100 milliseconds (ms) to 10000 ms, in
delay following a dynamic priority change. The track increments of 100 ms
event delay helps avoid unnecessary failovers Default: 3000 ms (3 seconds)
caused by brief, temporary network changes.
(For more information, see “Dynamic Priority
Reduction” on page 365.)
[no] vrrp-a track-event-delay
100-ms-unit
VRID Parameter
Floating IP IP addresses that downstream devices should use as Valid IPv4 or IPv6 address
address their default IPv4 or IPv6 gateways. Regardless of Default: Not set
which device is active for the VRID, downstream
Note: Specifying the interface is valid
devices can reach their default IPv4 or IPv6 gate-
only for link-local IPv6 addresses.
way at the floating IP address.
This option is useful in cases where
[no] floating-ip you do not want the floating IPv6
{ address to be associated with all
ipaddr | ACOS device interfaces.
ipv6addr [ethernet port-num |
ve ve-num | trunk num]
}
Note: Maximum Number of Supported VRRP-A

Floating IP Addresses:
• For all FPGA models: 256 VRRP-A floating IPs
• For non-FPGA models: 64 VRRP-A floating IPs
• For private partitions enabled for Layer 2/3 virtu-
alization (both FPGA and non-FPGA models):
64 VRRP-A floating IPs
Pre-emption Controls whether failovers can be caused by config- Enabled or disabled
uration changes to VRRP-A priority or device ID. Threshold: 1-255
The threshold specifies the maximum difference in Defaults:
priority value that can exist between the active and
• enabled
standby devices without failover occurring.
• threshold 0
[no] preempt-mode disable
[no] preempt-mode threshold num
Priority Preference of the device to become the active device 1-255
for the VRID. The device that has the highest prior- Default: 150
ity value for the VRID becomes the active device
for the VRID.
[no] priority num

Overview
Tracking options Tracking for dynamic priority reduction used in Priority to subtract – 1-255
(shared partition dynamic failover. (See “Dynamic Priority Reduc- VLAN timeout – 2-600 seconds
only) tion” on page 365.)
Default: not set
You can configure tracking of the following net-
work resources:
• IPv4 or IPv6 gateway IP address
• Ethernet data port
• IPv4 or IPv6 data route
• VLAN
Note: You also can configure real server health
tracking for a VIP, at the configuration level for the
VIP. Use the ha-dynamic num command.
Note: For private partitions, only interface, route,
and VIP tracking are supported.
[no] tracking-options
This command accesses the configuration level for
link status tracking, where the following commands
are available:
[no] gateway {ipaddr | ipv6addr}
priority-cost num
[no] interface ethernet portnum
priority-cost num
[no] route dest-network
[gateway {ipaddr | ipv6addr}]
[distance num]
[no] trunk num priority-cost num
[per-port-pri num]
[no] vlan vlan-id timeout seconds
priority-cost num

Deploying VRRP-A
Deploying VRRP-A
Basic VRRP-A deployment requires only the following steps on each
ACOS device:
1. Specify the device ID.
2. (optional) Configure floating IP addresses.
3. Enable VRRP-A.
Configuration of additional VRRP-A parameters is optional. (For informa-

tion, see “VRRP-A Parameters” on page 372.)
Specify the VRRP-A Device ID

To specify the VRRP-A device ID, use either of the following methods:
[no] vrrp-a device-id num
You can specify 1-8. There is no default.
Note: If aVCS is configured, use the same number as the device’s aVCS device
ID.
Configuring Floating IP Addresses for VRRP-A VRIDs

You can configure floating IP addresses for individual VRIDs. To configure
a floating IP address for a VRID, use the following commands:
[no] vrrp-a vrid {num | default}
Enter the command at the global configuration level of the CLI. The com-
mand accesses the configuration level for the VRID, where the following
command is available:
[no] floating-ip {ipaddr | ipv6addr}

[ethernet portnum | ve ve-num | trunk num]

Deploying VRRP-A
Enable VRRP-A
[no] vrrp-a enable
Force-Self-Standby Reload or Restart Persistence

If the force-self-standby option is selected via the CLI, this feature will
allow a single partition, multiple partitions, or the device to remain in a
forced self-standby state even though the device or partition goes through a
reload or device restart. Use the following commands with your HA or
VRRP-A configuration to enable force self-standby persistence:
[no] ha force-self-standby
[ha-group-id group-num [persistent]] | [persistent]
[no] vrrp-a force-self-standby

[all-partitions [persistent]] |
[persistent] |
[vrid {vrid-num | default}] [persistent]]
For example, if the ha force-self-standby ha-group-id 2 persistent, ha

force-self-standby persistent, vrrp-a force-self-standby persistent, or
vrrp-a force-self-standby vrid 2 persistent command is issued, the device
will go through the save operation to preserve the self force-standby status
of the single or multiple partitions or the device. The persistence behavior
will allow the partitions to go through the reload or restart and come back
up still in self standby mode.
If you issue the vrrp-a force-self-standby command without the persistent

keyword, the partition or device will not be placed in a force-self-standby
state after the device reload or restart completes. Similarly, if you issue the
ha force-self-standby command without the persistent keyword, your HA
devices will not remain in a self-standby state after a reload or device
restart. In both cases, you will have to configure self-standby again with the
persistent keyword to have your device retain its self-standby state after a
future reload or restart operation.
Command Example
To place VRRP-A VRID 2 into a forced-self-standby state, issue the follow-
ing command. Since you are not using the persistence keyword, when the
device completes a restart or software reload, it will not place VRID 2 in a
self-standby state:
AX(config)#vrrp-a force-self-standby vrid 2

Deploying VRRP-A
To place VRID 2 in a self-standby state even after a restart or reload, add the
persistence keyword to your command:
AX(config)#vrrp-a force-self-standby vrid 2 persistent
To place all VRIDs in partition (partA) in self-standby state even after a

restart or reload, execute the following command in partition “partA:”
AX[partA](config)#vrrp-a force-self-standby persistent
To place all partitions running VRRP-A VRID into a persistent forced-self-

standby state, issue the following command:
AX(config)#vrrp-a force-self-standby all-partitions persistent
To place HA group 2 into a forced-self-standby state, with the ability to

have that state be permanent despite a restart or reload, issue the following
command using the persistence keyword:
AX(config)#ha force-self-standby ha-group-id 2 persistence
Displaying VRRP-A Information

To display VRRP-A information, use the following commands:
show vrrp-a [detail]

This command shows VRRP-A configuration information. The detail
option shows statistics.
show vrrp-a config

This command shows the VRRP-A configuration on the device.
Note: Parameters that are set at their default values are not shown.
show vrrp-a mac

This command lists the virtual MAC addresses in use by VRRP-A.

Manually Synchronizing the Configuration

VRRP-A can be used to provide high availability without the need to also
configure aVCS.
Notes:
• Before synchronizing the configuration, save the configuration for all
partitions (write memory all-partitions).
• Do not reload the ACOS device before synchronizing the configuration.
• If aVCS is configured, manual configuration synchronization is not

available.
VRRP-A Information Included

If VRRP-A is configured, the non-device-specific VRRP-A configuration
information is included in the configuration synchronized to the other
ACOS device.
The following VRRP-A commands are synchronized:

• vrrp-a arp-retry
• vrrp-a hello-interval
• vrrp-a dead-timer
• vrrp-a track-event-delay
• vrrp-a enable
• vrrp-a disable-default-vrid
• vrrp-a set-id
• vrrp-a vrid
• floating-ip
• preempt-mode
Device-specific commands, such as commands that include the vrid option,

are not synchronized.

Peer IP Address Option

You must specify the destination IP address to which to synchronize the
configuration. Previous releases require the connection mirror IP address to
be configured, and allow manual synchronization only to that IP address.
The connection mirror IP address is still supported. If configured, the con-

nection mirror IP address is used unless you specify a different address
when you initiate the configuration synchronization.
SSH Requirement
Configuration synchronization requires SSH to be enabled on the source
and destination interfaces. SSH is enabled by default on the management
interface but disabled by default on the data interfaces.
The following sections describe how to identify the destination IP address

of the VRRP-A peer, how to enable SSH on the local and peer interfaces,
and how to synchronize the configuration.
USING THE GUI
To identify the Destination IP Address:

Enter the show vrrp-a detail command. The Peer IP field lists the IP
address of the VRRP-A peer.
Note: In the current release, VRRP-A is supported in the GUI. For details, refer
to “VRRP-A Configuration and Monitoring Using the GUI” on page 397
To Enable SSH on an Interface:

Perform the following steps on the local ACOS device and on the peer
ACOS device.
1. Select Config Mode > System > Settings > Access Control.
2. Select the SSH checkbox for the interface.
3. Click OK.

To Synchronize the Configuration:
Enter the IP address of the configuration synchronization target (the peer
ACOS device) in this field. Here is the complete procedure:
1. Select Config Mode > System > HA > Config Sync.
2. Enter the admin username and password required for read-write access
to the peer ACOS device.
3. If Role-Based Administration (RBA) is configured on the ACOS

device, select whether to synchronize all partitions or only the currently
selected partition.
• To synchronize the configurations for all partitions, select Sync All
Partitions.
• To synchronize the configuration for only the currently active parti-
tion, leave the Sync All Partitions checkbox unselected.
4. Next to Operation, select the information to be copied to the other

ACOS device:
• All – Copies all the following to the other ACOS device:
• Admin accounts and settings
• IP NAT configuration
• Access control lists (ACLs)
• Health monitors
• Policy-based SLB (black/white lists)
• SLB
• FWLB
• GSLB
• Data files (see below)
The items listed above that appear in the configuration file are cop-
ied to the other ACOS device’s running-config.
• Data Files – Copies only the SSL certificates and private-key files,
aFleX files, External health heck files, and black/white-list files to
the other ACOS device
• Running-config – Copies everything listed for the All option, except
the data files, from this ACOS device’s running-config
• Startup-config – Copies everything listed for the All option, except
the data files, from this ACOS device’s startup-config

5. Next to Peer Option, select the target for the synchronization:
• To Running-config – Copies the items selected in step 4 to the other
ACOS device’s running-config
• To Startup-config – Copies the items selected in step 4 to the other
ACOS device’s startup-config
6. To reload the other ACOS device after synchronization, select With

Reload. Otherwise, the other ACOS device is not reloaded following the
synchronization.
Note: In some cases, reload either is automatic or is not allowed. See “Manually
Synchronizing Configuration Information” on page 335.
7. To specify the peer IP address, enter the address in the Destination IP

field.
8. Click OK.
USING THE CLI

To identify the Destination IP Address:
Enter the show vrrp-a detail command. The Peer IP field lists the IP
address of the VRRP-A peer.
To Enable SSH on an Interface:

[no] enable-management service ssh

{management | ethernet port-num [to port-num] |
ve ve-num [to ve-num]}
Use this command on the local ACOS device and on the peer ACOS device.
To Synchronize the Configuration:

Use one of the following commands at the global configuration level of the
CLI:
ha sync all
to-running-config}
ipaddr |
[auto-authentication]

to-running-config}
ipaddr |
to-running-config}
ipaddr |
ha sync data-files
ipaddr |
To Configure Preemption Delay:
USING THE GUI

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

To configure the VRRP-A pre-emption delay, use the following command
[no] vrrp-a preemption-delay millisecond-value
The default VRRP-A preemption delay is 6 seconds (60 units of 100 ms).
You can globally set the delay to a value from 100 ms (1 unit of 100 ms) to
25.5 seconds (255 units of 100 ms).

The following sections show configuration examples for VRRP-A. The first
example shows a very basic deployment using the minimum required com-
mands. The second example includes priority configuration changes and
tracking.
Simple Deployment
The following commands deploy VRRP-A on a set of 4 ACOS devices.
Commands on AX-1
AX-1(config)#vrrp-a device-id 1
AX-1(config)#vrrp-a enable
Commands on AX-2
Commands on AX-3
Commands on AX-4
Deployment with Custom Priority Settings

The following commands configure VRRP-A on 2 ACOS devices, with the
priority settings shown in Figure 57 on page 361.
• On ACOS device AX-1, the priority value is set to 255 on the shared
partition’s default VRID and partition CorpB’s default VRID. The prior-
ity value is left set to its default (150) for CorpA and CorpC; the priority
does not need to be set since this is the default value.
• On ACOS device AX-2, the priority value is set to 255 on the default
VRIDs in partitions CorpA and CorpC. The priority value is left set to
its default (150) for the shared partition and for CorpB; the priority does
not need to be set since this is the default value.

These commands also configure a floating IP address for each VRID.
Figure 57 on page 361 does not include the floating IP addresses. (For more
on floating IP addresses, see “Floating IP Addresses” on page 359.)
Commands on AX-1
AX-1(config)#vrrp-a vrid default
AX-1(config-vrid)#priority 255
AX-1(config-vrid)#floating-ip 10.10.10.2
AX-1(config-vrid)#end
AX-1#active-partition CorpB
Currently active partition: CorpB
AX-1[CorpB]#config
AX-1[CorpB](config)#vrrp-a vrid default
AX-1[CorpB](config-vrid-default)#priority 255
AX-1[CorpB](config-vrid-default)#floating-ip 30.30.30.2
Commands on AX-2
AX-2#active-partition CorpA
Currently active partition: CorpA
AX-2[CorpA]#config
AX-2[CorpA](config)#vrrp-a vrid default
AX-2[CorpA](config-vrid-default)#priority 255
AX-2[CorpA](config-vrid-default)#floating-ip 20.20.20.2
AX-2[CorpA](config-vrid-default)#end
AX-2#active-partition CorpC
Currently active partition: CorpC
AX-2[CorpC]#config
AX-2[CorpC](config)#vrrp-a vrid default
AX-2[CorpC](config-vrid-default)#priority 255
AX-2[CorpC](config-vrid-default)#floating-ip 40.40.40.2

Configuration of Tracking Options

The following commands configure VRRP-A tracking options. For simplic-
ity, commands for only a single device are shown.
Ethernet Interface Tracking

The following command configures tracking of Ethernet port 1. If the port’s
link goes down, 100 is subtracted from the VRID’s priority value.
AX2500(config-vrid-tracking)#interface ethernet 1 priority-cost 100
Trunk Tracking
The following commands configure the ACOS device to track the status of
a trunk (but not ports within the trunk). The VRRP-A protocol will reduce
the priority of the device by 100 if the trunk goes down.
AX2500(config)#vrrp-a vrid 1
AX2500(config-vrid)#tracking-options
AX2500(config-vrid-tracking)#trunk 1 priority-cost 100
The following commands configure the ACOS device to track the status of
a trunk, as well as the status of ports within the trunk. If trunk 2 goes down,
the priority of the associated VRID is reduced by 150. If a port within the
trunk goes down, the priority of the associated VRID is reduced by 40.
AX2500(config-vrid-tracking)#trunk 2 priority-cost 150 per-port-pri 40
VLAN Tracking
The following command configures tracking of VLAN 69. If the VLAN is
quiet for more than 30 seconds, 50 is subtracted from the VRID priority.
AX2500(config-vrid-tracking)#vlan 69 timeout 30 priority-cost 50
The current release provides enhanced VLAN tracking capabilities. For

details on this capability, refer to “Increased VLANs for VRRP-A- Failover
Tracking” on page 388 for details.

Gateway Tracking
The following commands configure tracking of gateway 10.10.10.1. If the
gateway stops responding to pings, 100 is subtracted from the VRID’s prior-
ity value.
AX2500(config)#health monitor gatewayhm1
AX2500(config-health:monitor)#method icmp
AX2500(config)#slb server gateway1 10.10.10.1
AX2500(config-real server)#health-check gatewayhm1
AX2500(config)#vrrp-a vrid default
AX2500(config-vrid-tracking)#gateway 10.10.10.1 priority-cost 100
Route Tracking
The following command configures tracking of routes to destination net-
work 3000::/64. If the IPv6 route table does not contain any routes to the
destination, 105 is subtracted from the VRID priority.
AX2500(config-vrid-tracking)#route 3000::/64 priority-cost 105
The following commands configure tracking of routes to destination net-

work 5000::/64. If the IPv6 route table does not contain any routes to the
destination, 80 is subtracted from the VRID priority.
AX2500(config-vrid-tracking)#route 5000::/64 priority-cost 80
Server Health Tracking

The following commands configure tracking of server health for virtual port
80 on a VIP. If a server in the virtual port’s service group fails its health
check, 10 is subtracted from the VRID priority.
AX2500(config)#slb virtual-server vip1 192.168.1.88
AX2500(config-slb vserver)#ha-dynamic 10
If more than one server fails its health check, 10 is subtracted for each
server. For example, if 3 servers fail their health checks, a total of 30 is sub-
tracted from the VRID’s priority.
Preemption Delay
The following command will allow you to configure the desired preemption
delay value of 200 milliseconds:
AX2500(config)#vrrp-a preemption-delay 200

Increased VLANs for VRRP-A- Failover Tracking
ACOS 2.7.1 provides support for an increased number of VLANs that can
be tracked as part of the VRRP-A failover tracking feature. The weight (as
assigned using failover policy templates—for details refer to “VRRP-A Pol-
icy-Based Failover Template” on page 429) or priority assigned to the
VLAN tracked event will be used in calculations that will impact VRRP-A
failover decisions. In previous releases, only tracking of 5 VLANs per parti-
tion was possible. Currently, 64 VLANs can be tracked per partition. For
each L3V partition, you can track 64 different VLANs
If VRRP-A stops detecting traffic on a VLAN, VRRP-A reduces the prior-

ity for the VRID. The priority value to subtract can be specified individually
for each VLAN.
To configure VLAN tracking use the following command:

vlan vlan-id timeout timeout-value priority value
ACOS 2.7.1 provides two ways to track VLANs for VRRP-A:

• Using the priority tracking option—The tracking option performs
failover by decreasing a VRID's priority value.
• Using failover policy templates—The failover policy template performs
failover by decreasing a VRID's weight value.
You can track a total of 64 different VLANs in three possible ways:

• Configure all 64 VLANs that can be tracked using tracking options.
• Configure all 64 VLANs that can be tracked using a single failover pol-
icy template or split over multiple templates.
• Configure a mix of both options mentioned above. That is configure 32
VLANS using the tracking option and configure the remaining 32
VLANs using a failover policy template.
Note: Tracking options and the failover policy template can track the same
VLANs. For example, you configure 64 VLANs using the tracking
option. You can also configure tracking of 64 of the same VLANs using a
fail-over-policy template. In essence, you are still only tracking 64
VLANs.
To view your configuration, use the show vrrp-a conf command. This will
display the VLANs that are being tracked.

After you have enabled VRRP-A on the devices, set the VRRP-A VRID,
and then to set VLAN tracking-options for 64 VLANs based on their prior-
ity cost:
vrrp-a vrid 31
tracking-options
vlan 1000 timeout 30 priority-cost 1


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

In a private partition, check to see how many VRIDs are supported:
AX[p1](config)#vrrp-a vrid ?
<1-7> Specify ha VRRP-A vrid
default Default VRRP-A vrid
In the shared partition, check to see the number of supported VRIDs:

AX(config)#vrrp-a vrid ?
<1-31> Specify ha VRRP-A vrid
default Default VRRP-A vrid

Configuring a Leader and Follower VRID

Configuration Example 1
To configure a leader VRID, do the following:
1. In the shared partition, configure a vrid-lead:
AX(config)#vrrp-a vrid-lead lead1
AX(config-vrid-lead)#partition shared vrid 1
2. In the private L3V partition, configure the VRID you wish to designate
as the follower.
a. To do so, enter the partition:
AX#active-partition p1
b. In the currently active partition, p1, enter the following command:
AX[p1](config)#vrrp-a vrid 1 follow vrid-lead lead1
c. Use the show vrrp-a command to view your configuration:
AX[p1](config-vrid-follow)#show vrrp-a
vrid default
Unit State Weight Priority
1 (Local) Active 65534 150
became Active at: May 20 12:04:05 2013
for 0 Day,22 Hour,54 min
2 (Peer) Standby 65534 150 *
vrid 1 (follow vrid-lead lead1)
2 (Peer) Standby 65534 150 *
vrid that is running: default 1
3. By default, the default-vrid-lead exists in the shared partition:

vrrp-a vrid-lead default-vrid-lead
partition shared vrid default

Configuration Example 2
To configure a leader in the shared partition, issue the following commands:

1. Define a VRID called myname as the leader:
AX(config)#vrrp-a vrid-lead myname
AX(config-vrid-lead)#partition p1 vrid default
2. Use the following show command to display your VRID leader configu-
ration:
AX(config)#show vrrp-a vrid-lead
vrrp-a vrid-lead default-vrid-lead
partition shared vrid default
vrrp-a vrid-lead myname
partition p1 vrid default
3. In the private partition, configure the VRID to follow the lead VRID:
AX[p1](config)#vrrp-a vrid 3 follow vrid-lead myname
4. Observe your configuration using the show vrrp-a command:

AX[p1](config)#show run
vrrp-a vrid default follow vrid-lead default-vrid-lead

floating-ip 7000::25
!
vrrp-a vrid 3 follow vrid-lead myname
!
5. As the Admin, if you want to change the VRID’s role from being a fol-
lower to standalone VRID again, issue the following command:
AX[p1](config)#vrrp-a vrid 3
Change the role of vrid 3 from follower to standalone? (y/n)y
6. Again, to view your configuration, use the show run command:

AX[p1](config)#show run
!
vrrp-a vrid 3
!
If you try to remove a VRID that is configured as a lead VRID and that has
other VRIDs that follow it, you will not be allowed to remove it. You must

remove the VRIDs that are configured as followers before you remove the
lead VRID.
VRRP-A Status in CLI Prompt

Use this ACOS 2.7.1 feature to identify the types of devices that are config-
ured in HA pairs or that are running VRRP-A configuration. The feature
allows you to collect device serial numbers that are unique for each device
during the HA or VRRP-A communication and can help you identify the
devices in a same HA group or VRRP-A set.
This user-configurable prompt allows you to add or remove the device host-
name, the aVCS chassis device ID, the aVCS status, the VRRP-A status, or
the HA status. Configuring a prompt is optional. If all the five options are
configured, an example of a prompt may say AX1030-vMaster[7/1](con-
fig)#.

tus}
To display the HA or VRRP-A status in the prompt, specify the ha-status

keyword. For example, this can be Active, Standby, or ForcedStandby.
When you configure ha-status, the VRRP-A or HA states of a device will be
displayed in the prompt. ForcedStandby will be displayed when you issue
standby state.
USING THE GUI
USING THE CLI

device-id

Terminal prompt format: hostname ha-status vcs-status chassis-device-id
AX(config)#terminal prompt hostname vcs-status
For details on all configurable prompts and how they work in conjunction
with one another, refer to “Configurable aVCS Prompts” on page 501.


VRRP-A Configuration and Monitoring

Using the GUI
The current release provides configuration support for VRRP-A using the
GUI.
VRRP-A is the A10 Thunder Series and AX Series implementation of High

Availability protocol that is completely different from the industry-standard
implementation of Virtual Router Redundancy Protocol (VRRP). For pur-
poses of operational familiarity, it borrows concepts from VRRP, but is sig-
nificantly different from VRRP. VRRP-A will not inter-operate with VRRP.

of the HA functionality. Now, when configuring a Virtual Server (VIP), use
a VRRP-A group instead of a High Availability group.
Note: A VRID can be configured on a virtual server only when VRRP-A is

enabled. By default, if VRRP-A is disabled, you will see an HA Group
field shown instead of the VRID field in the virtual server configuration
page.
Configure and view information for VRRP-A at the global and at the
interface level.

Configuration
Configuration
This section describes how to configure VRRP-A using the GUI.
Configuring VRRP-A Global Parameters

To enable VRRP-A at the global level, configure the parameters that appear
in the General, VRID, Floating IP Address, VRRP-A Tracking, and Force
Self Standby windows.

Configuration
General
To configure VRRP-A global parameters, follow these steps:

1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display
the General section:
2. Commence with VRRP-A configuration:

Note: You must configure the VRRP-A Status, Device ID, and the Set
ID. Several other fields contain default values, you may modify them at
this time or retain their default values:
VRRP-A Status—Choose Enabled or Disabled to indicate the state of
VRRP-A on the device. Disabled is selected by default.
Device ID—Enter a unique ID of the device within the VRRP-A set
from the drop down list. A device ID is not selected automatically.
Note: The device ID ranges vary on different ACOS devices.
Set ID—Indicate a set ID number from 1-7 for the VRRP-A domain.
All devices that will provide backup for a given VRID must belong to
the same VRRP-A set. The default is set to 1.
Default VRID—Click on either Enabled or Disabled to set the value for
the Default Virtual Router ID (VRID). Disabled allows you to use of the
default VRID in the shared partition and all private partitions. The
default value is Enabled.
Note: Disabling the default VRID allows you to use VRIDs 1-31 instead
of VRID 0 (the default VRID) in the shared partition. In private parti-
tions, disabling the default VRID disables VRRP-A.
By default, Enabled is selected.
Hello Interval—Enter the millisecond interval at which the active
device sends VRRP-A hello messages to the backup devices in the Hello
Interval. The value can be 1-255 units of 100 milliseconds (ms) each, by
default the interval is set to 2 (200 ms).
Dead Timer—Enter the Dead Timer to indicate the number of hello
intervals during which a backup device will wait for a hello message

Configuration
from the active device, before the failover to the standby device begins.
The default is 5 (1000ms).
Track Event Delay—Enter the Track Event Delay duration in
milliseconds from 100 milliseconds (ms) to 10000 ms, in increments of
100 ms waited by the ACOS device before failover following a dynamic
priority change. The track event delay helps avoid unnecessary failovers
caused by brief, temporary network changes. By default, the delay
duration is 30 (3000ms).
Preemption Delay—Enter the Preemption Delay duration in
milliseconds. Preemption allows failover to be triggered by manually
changing the priority on one or more devices so that the active device no
longer has the highest priority for the VRID. Optionally, you can
configure a preemption delay value, 1-255. The default VRRP-A
preemption delay is 6 seconds (60 units of 100 ms). You can globally set
the delay to a value from 100 ms (1 unit of 100 ms) to 25.5 seconds (255
units of 100 ms). Preemption delay is only triggered and used when
VRRP-A is configured in a multiple ACOS device setup. Failover is
only triggered through priority changes. When VRRP-A is configured
on 2 ACOS devices, with one serving as the Active device and the other
as the Standby device, changing the priority will cause an instant
failover within 1 to 3 seconds.
ARP Retry—Enter the number of additional IPv4 gratuitous ARPs or
ICMPv6 neighbor advertisements from 1-255 retries, in addition to the
first one, an ACOS device sends after transitioning from standby to
active. The default is 4 additional gratuitous ARPs, for a total of 5
ARPs.
3. Click on OK (at the bottom of the screen) to save your changes to your
running configuration or Save (from the top navigation bar) to
permanently register your changes.

Configuration
VRID
Follow these steps to configure the VRID:

1. Select Config Mode > VRRP-A > Setting >VRRP-A Global to display
VRID menu options.
2. Click on the down arrow next to VRID to expand the VRID section:
3. Click on the drop down list to specify a VRID.

a. Click on Add to create your VRID with a default priority of 150.
The VRID table will be updated with your new VRID entry.
b. To indicate a priority change from the default value of 150, select
the checkbox next to the VRID, enter a new priority value.
c. Click on Edit to accept your changes. Your revisions will be
reflected in the VRID table.
d. Fill in the details for the Failover Policy Template section.
VRRP-A provides flexible event tracking and policy-based failover
support via a template. Assuming you have already created a
failover policy template or several templates, select the template
name from the drop down menu, to associate the template with this
VRID.
4. Check Preempt Mode. The Enabled radio button is automatically
selected, and you will be able to specify a Threshold value.
Note: Unless you check Preempt Mode, you will not be able to specify
a Threshold value.
Preemption controls whether failovers can be caused by configuration

changes to VRRP-A priority or the device ID.
5. Specify the desired Threshold. The threshold of 1-255 specifies the
maximum difference in priority value that can exist between the active
and standby devices without failover occurring. The default threshold
value is 0. Choose the highest priority of 255 for the primary device.

Configuration
running configuration or Save (from the top navigation bar) to
permanently register your changes.
Floating IP Address
Follow these steps to configure the Floating ID Address:

the Floating IP Address.
2. Click on the down arrow next to Floating IP Address to expand the

Floating IP Address section:
3. Choose the VRID from the drop down list.

4. Click on the IPv4 or IPv6 radio button to specify a corresponding Float-
ing IP Address address. This IP addresses will be used by downstream
devices as their default IPv4 or IPv6 gateways. Regardless of which
device is active for the VRID, downstream devices can reach their
default IPv4 or IPv6 gateway using the floating IP address.
Note: Specifying the interface is valid only for link-local IPv6
addresses. This option is useful in cases where you do not want the
floating IPv6 address to be associated with all ACOS device interfaces.
running configuration or Save (from the top navigation bar) to perma-
nently register your changes.

Configuration
VRRP-A Tracking
the VRRP-A Tracking tab. Tracking for dynamic priority reduction is
used in dynamic failover. You can configure tracking of the following
network resources such as the IPv4 or IPv6 gateway IP address, the
Ethernet data port, IPv4 or IPv6 data route or VLAN.
Note: You also can configure real server health tracking for a VIP, at the
server and service group level.
Note: For private partitions, only interface, route and VIP tracking are
supported.
2. Click on the down arrow next to VRRP-A Tracking to expand the

VRRP-A Tracking section.
3. Specify the global Gateway tracking fields:
a. Select the VRID from the drop down menu.

b. Select either the IPv4 or IPv6 address radio button and specify the
corresponding IPv4 or IPv6 address.
c. Indicate the corresponding IP address.
d. Click on Add. The VRID table will include your table entry.
4. In the VLAN section, enter the global VLAN tracking fields:

Configuration
a. Choose a valid VLAN ID from the drop down list.
b. Specify the timeout value from 2-600 seconds.
c. Indicate the priority of 1-255.
d. Click on Add. The VRID table will include your table entry.
5. In the Trunk section, enter the global trunk tracking fields:
a. Choose a valid VRID from the drop down list.

b. Specify the Trunk ID value from 1-16.
Note: The ID must refer to an existing trunk.
c. Indicate the Priority value from 1-255.
d. Indicate the Per Port Priority value from 1-255.
e. Click on Add. The VRID table will include your table entry.
6. In the Interface section, enter the global interface tracking fields:
a. Choose a VRID from the drop down list.

b. Specify the Interface from the drop down list.
Note: Indicate an existing interface.
c. Indicate a priority cost for the interface.

Configuration
7. In the Route section, enter the route tracking fields:
a. Choose a VRID from the drop down list.

b. Specify an IPv4 or IPv6 route and the corresponding IPv4 or IPv6
address. Note: Indicate an existing route.
c. Indicate a valid route Gateway
d. Indicate a Distance of 1-255.
e. Choose any, static, or dynamic route from the Protocol drop down
menu.
f. Indicate a Priority Cost for the route from 1-255.
g. Click on Add and the new table row will be added to the existing
table.
Preferred Session Sync Port
VRRP-A uses one active device and one standby device for a given VRID.
If session synchronization (also called connection mirroring) is enabled, the
active device backs up active sessions on the standby device. Session syn-
chronization is disabled by default and can be enabled on individual virtual
ports.
To configure the VRRP-A Preferred Session Sync Port for receiving ses-
sions, do the following:
Preferred Session Sync Port tab.
2. Click on the down arrow next to expand the Preferred Session Sync Port
section.

Configuration
3. From the Interface drop down menu, select the interface attached to the
port that you wish to use to sync information.
4. Indicate the VLAN ID in the text box. The valid range for your ID can
be from 1-4094.
5. Click on Add.
Your entry will be added to the Preferred Session Sync Port table:
VRID Leader
With an increase in the number of configurable VRIDs to 512, you may
configure a VRID as a “leader” VRID and some others as “follower”
VRIDs. The benefit of configuring the leader VRID is that when you are run
the risk of consuming all your resources, one VRID can serve as the leader
and others can be configured to operate as followers. This means that only
on one VRID will you be able to configure all capabilities, such as configur-
ing the failover policy template, the preempt mode, priority, and tracking
options, while in the follower VRID, you can only configure Floating IP
Addresses.
ACOS 2.7.1 supports a maximum of 512 VRIDs on one device. Any time
this number is exceeded, VRIDs are automatically configured as follower
VRIDs or can be explicitly configured to be added as a follower VRID.

Configuration
To indicate a leader VRID, fill in the fields shown in the window below:
1. Indicate the VRID Leader Name. This can be any alphanumeric string
of 1-63 characters.
2. Indicate the Partition from the drop down list.
3. Indicate the ID assigned to this particular VRID.
4. Click on Add.
If you have private partitions configured, to configure followers for this lead
VRID, you must enter the appropriate information in this window:
1. Click on the checkbox next to Follow VRID Leader.
2. Select the VRID lead name from the drop down list.
Force Self Standby
Force Self Standby provides a simple method to force a failover, without the
need to change VRID priorities and use preemption. Follow these steps to
configure this option:
Force Self Standby tab.

Configuration
2. Click on the down arrow next to expand the Force Self Standby section:
3. Click on either the All Partitions or the VRID radio button if you want
the force self standby operation to impact all partitions or specific
VRIDs. All Partitions will impact both shared partition and private
partitions. If entered in the shared partition, the option applies to all
VRIDs on the device. If entered in a private partition, the option applies
to all VRIDs within that partition but does not affect VRIDs in other
partitions.
4. Click on Enable or Disable to execute the force self standby operation.
Note: The Force Self Standby option remains in effect until one of the
other failover triggers occurs or the device is reloaded or rebooted. The
option is not added to the configuration and does not persist across
reloads or reboots.
Configuring VRRP-A Interface Parameters

To enable VRRP-A at the interface level, from Config Mode > VRRP-A >
Setting > VRRP-A Interface, configure the Status, VRRP-A-Status, Type,
Heartbeat, and VLAN fields for a chosen interface.
To configure VRRP-A interface parameters, follow these steps:

1. Select Config Mode > VRRP-A > Setting > VRRP-A Interface to dis-
play the VRRP-A Interface window:

Configuration
2. Select a valid Ethernet interface and click on the interface name to
launch the following VRRP-A for that particular interface. In this case,
the ethernet9 interface window will be displayed:
3. The Port Number and the interface Type fields are automatically filled
in.
a. Click on Enabled in the Status field to enable the interface.
b. Click on Enabled to enable the VRRP-A Status for the particular
interface.
c. Click on the radio button to indicate if the interface Type is a Router
Interface (an upstream router reachable through the interface), a
Server Interface (a real server that is reachable through the inter-
face), or Both (the upstream router and the real server are accessible
through the interface). None is selected by default.
Note: In the current release, the interface type specified by this
parameter is informational only. This setting does not affect VRRP-
A operation or interface tracking.
d. Click on Enabled or Disabled to initiate an interface Heartbeat to
trace the health of the interface. By default, all up interfaces config-
ured with their IP Addresses in a partition are VRRP-A interfaces
for that partition.
e. Enter a VLAN ID from 1-4094.

Configuration
GUI Configuration Examples

The following sections show configuration examples for VRRP-A using the
GUI. The first example shows a very basic deployment using the minimum
required configuration. The second example includes priority configuration
changes and tracking.
Simple GUI Deployment

The following procedures deploy VRRP-A on a set of 2 ACOS devices.
Configuration on AX-1
To configure ACOS device 1, follow these steps:

the General section.
2. Click on Enabled to begin a VRRP-A configuration session.
3. Choose a Device ID from the drop down list for device 1.
4. Indicate Set ID 1.
To configure ACOS device 2, follow these steps:

the General section.
2. Click on Enabled to begin a VRRP-A configuration session.
3. Choose a Device ID from the drop down list for device 2.

Configuration
4. Indicate Set ID 1.
5. Configure the Host ID. The Host ID helps to identify the peer devices
that are learned through heartbeat messages. The Host ID indicates
which devices are configured as VRRP-A peers.
Deployment with Custom Priority Settings

The following steps help configure VRRP-A on 2 ACOS devices.
Note: This example shows how to configure a partition for CorpB, but assumes
that each device has a shared partition and three private partitions for
CorpA, Corp B, and CorpC:
• On ACOS device AX-1, the priority value is set to 255 on the shared
partition’s default VRID and partition CorpB’s default VRID. The prior-
ity value is left set to its default (150) for CorpA and CorpC. The prior-
ity does not need to be set since this is the default value.
• On ACOS device AX-2, the priority value is set to 255 on the default
VRIDs in partitions CorpA and CorpC. The priority value is left set to
its default (150) for the shared partition and for CorpB. The priority
does not need to be set since this is the default value.
VRRP-A configuration entails the following main steps:

• Indicate a VRRP-A device ID.
• Enable VRRP-A

Configuration
• Specify priority settings.
• Indicate a floating IP address.
• Configure tracking options.
• Configure Server health tracking.
• Configure partitions that may serve as standby partitions.
On enabled device 1, follow these steps to configure a VRID and priority:

the VRID option.
2. Click on the down arrow next to VRID to expand the VRID section.
3. To configure the default VRID with a priority of 255, do the following:
a. Retain the default setting for the VRID from the drop down menu.
b. Enter 255 in the Priority field in lieu of the default value of 150.
c. Click on Add. The VRID table will be updated with your new VRID
entry.
the Floating IP Address option.
5. Click on the down arrow next to the Floating IP Address to expand the
Floating IP Address section.
6. Choose the VRID from the drop down list.
7. Click on the IPv4 radio button to specify Floating IP Address of
10.10.10.2. This IP addresses will be used by downstream devices as
their default IPv4 gateway. Regardless of which device is active for the
VRID, downstream devices can reach their default IPv4 gateway using
this Floating IP Address.

Configuration
8. Click on Add.
10. On device 1, from Config Mode > System > Admin > Partition, do the
following:
a. Click on Add to create a partition for CorpB.
b. Create a partition for CorpB.
c. Click on Enabled to enable the Network Partition. When you click
on Enabled, you will have the option to specify a System Resource
Template.
d. Click OK:

Configuration
11. Configure the CorpB partition for the default VRID with a Priority of
255 and a Floating IP Address of 30.30.30.2:

Configuration
following:
a. Click on Add to create a partition for CorpA.
b. Create a partition for CorpA.
c. Click on Enabled to enable the Network Partition.
d. Click OK.
e. Click on the newly created partition, to see the following screen:
13. Configure the CorpA partition for the default VRID with a Priority of
255 and a Floating IP Address of 20.20.20.2:

Configuration
following:
a. Click on Add, create a partition for CorpC.
b. Click on Enabled to enable the Network Partition.
c. Click OK.
d. Click on the newly created partition, to see the following screen:
15. Configure an additional CorpC partition for the default VRID with a
Priority of 255 and a Floating IP Address of 40.40.40.2:

Configuration
16. From Partition that appears on the top navigation bar, click on the drop
down menu to view all your partitions:
You have completed your set up of VRRP-A on two devices.

17. From Monitor Mode > VRRP-A > VRID for ACOS device 1, view the
Active status of VRRP-A with two peers in Standby mode:
18. From Monitor Mode > VRRP-A > VRID for ACOS device 2, view the
Standby status of VRRP-A with a peer in Active mode:
19. When device 1 fails, it will cause a failover from the Active device to
the Standby device. At any given time, from Monitor Mode > VRRP-A
> VRID, view the Active or Standby status of your devices or your par-
titions:

Configuration
Configuration of GUI Tracking Options

The following configuration displays VRRP-A tracking options. For sim-
plicity, configuration for only a single device is shown.
Gateway Tracking
The following steps configure tracking of gateway 10.10.10.1. If the gate-
way stops responding to pings, 100 is subtracted from the VRID’s priority
value.
1. From Config Mode > SLB > Health Monitor > Health Monitor, click on
Add to create a Health Monitor.
2. In the Health Monitor section, enter gatewayhm1 as the Name for the
Health Monitor.
3. In the Method section, accept ICMP as the Type of the Health Monitor.
4. Click on OK at the bottom of the screen.
5. Go to Config Mode > SLB > Service > Server to view a list of available
servers.

Configuration
6. Click on the server name to display the Server details.
7. From the Health Monitor drop down list, select gatewayhm1 shown
highlighted in blue.
8. Select Config Mode > System > VRRP-A > VRRP-A Global to display
the VRRP-A Tracking option.

10. From the Gateway section, choose the default VRID from the drop
down list.
11. Choose the IPv4 radio button and enter 10.10.10.1 as the IP Address.

Configuration
12. Indicate a Priority Cost of 100.
13. Click on Add.
Click on OK (at the bottom of the screen) to save your changes to your run-
ning configuration or Save (from the top navigation bar) to permanently reg-
ister your changes.
VLAN Tracking
The following steps help configure tracking of VLAN 69. If the VLAN is
quiet for more than 30 seconds, 50 is subtracted from the VRID priority:

3. In the VLAN section, for an existing VLAN ID 69, do the following:

a. Enter a timeout value of 30.
b. Enter a Priority Cost of 50.

Configuration
4. Click on Add.
Trunk Tracking
To configure the ACOS device to track the status of a trunk (but not ports
within the trunk), follow these steps. The VRRP-A protocol will reduce the
priority of the device by 100 if the trunk goes down.
the VRRP-A Tracking.
VRRP-A Tracking section. In the Trunk section, enter the trunk track-
ing fields.
3. Choose VRID 1 from the drop down list.
4. Specify the Trunk ID value of 1.
Note: The ID must refer to an existing trunk.
5. Indicate the Priority Cost of 100.
6. Click on Add. The VRID table will include your table entry.
The following steps configure the ACOS device to track the status of a
trunk, as well as the status of ports within the trunk. If trunk 2 goes down,
the priority of the associated VRID is reduced by 150. If a port within the
trunk goes down, the priority of the associated VRID is reduced by 40.

Configuration
3. In the Trunk section, enter the trunk tracking fields. Choose VRID 2
from the drop down list.
4. Specify the Trunk ID value of 2. Note: The ID must refer to an existing
trunk.
5. Indicate the Priority Cost of 150.
6. Indicate the Per Port Priority Cost of 40.
7. Click on Add. The VRID table will include your entry.
Interface Tracking
To configure tracking of Ethernet port 1 follow these steps. If the port’s link
goes down, 100 is subtracted from the VRID’s priority value.
the VRRP-A Tracking.

3. In the Interface section, enter the ethernet interface tracking fields.
Choose a VRID from the drop down list.
4. Select a valid ethernet Interface from the drop down list.

Configuration
5. Indicate a priority cost for the interface of 100.
Route Tracking
The following steps configure tracking of routes to destination network
3000::/64. If the IPv6 route table does not contain any routes to the destina-
tion, 100 is subtracted from the VRID priority.

3. From the Route section, choose the default VRID from the drop down
list.
4.Choose the IPv6 radio button and enter 3000::/64 as the IPv6 Address.
6. Click on Add.

Configuration
The following steps configure tracking of routes to destination network
5000::/64. If the IPv6 route table does not contain any routes to the destina-
tion, 80 is subtracted from the VRID priority.

3. From the Route section, choose 1 from the VRID drop down list.
4. Choose the IPv6 radio button and enter 5000::/64 as the IP Address.
6. Click on Add. Both routes are added to the VRID table for route track-
ing:

Configuration
Server Health Tracking
The following steps help configure tracking of server health for virtual port
80 on a VIP. If a server in the virtual port’s service group fails its health
check, 10 is subtracted from the VRID priority.
Follow these steps to configure server health tracking:

2. Click on Add to create a new Virtual Server.
3. Indicate a Name of your virtual server.
4. Indicate a valid IP Address or CIDR Subnet.
Note: A valid IPv4 mask is 16-32.
5. Indicate the VRID you wish to track from the drop down menu.
6. Click on Add in the Port section of the window.
7. Enter the port number.
8. Click on OK.
Note: A VRID can be configured on a virtual server only when

VRRP-A is enabled. By default, if VRRP-A is disabled, you will see an

Configuration
HA Group field shown instead of the VRID field in the virtual server
configuration page.
If more than one server fails its health check, 10 is subtracted for each
server. For example, if 3 servers fail their health checks, a total of 30 is
subtracted from the VRID’s priority.
Monitoring the VRRP-A VRID

To monitor VRRP-A using the GUI, select Monitor Mode > VRRP-A >
VRID to display the VRID information window:
From this window, information on any configured VRIDs are displayed in

the table.
For instance, this window displays VRRP-A as enabled on one Active and
one Standby device, shows that the Standby device has been configured
with two peers, and that its peer is currently the Active device. It also dis-
plays the peer priority and whether or not the device is in a Forced Standby
state.

Configuration
Monitoring VRRP-A Status

To monitor VRRP-A status using the GUI, select Monitor Mode >
VRRP-A > Status to display the information on your VRRP-A configura-
tion:
Based on configuration, the VRRP-A status window provides information

on peers (Peer ID), IP Addresses, Ports, missed Heartbeats, and Total
Packets received.

Configuration

VRRP-A Policy-Based Failover Template
VRRP-A provides flexible event tracking and policy-based failover support

via a template. This feature allows policy-based failover even when VRRP-
A preemption is disabled and the ACOS device typically would remain in
an Active state, despite VRID priority changes. It allows for event-based
failover once a tracked event occurs.
Current VRRP-A Implementation
In the current VRRP-A implementation, the software provides two levels on

failover considerations. Level 1 reflects the weight assigned to an event.
Level 2 reflects the priority value assigned as part of the previous VRRP-A
deployment. While the priority of VRID is still a failover consideration, for
more granular control, this release introduces an additional layer called
“weight” that will take precedence above the VRID’s allocated priority.
Each VRID is now allocated a fixed, total weight of 65534 and each event is
allocated a corresponding, configurable weight of 1-255. When the event
occurs, the configured weight for the event is deducted from the total weight
assigned to the VRID. Some events (for example, when an interface goes
down) are considered to be critical for a VRID and will reduce the VRID’s
weight. ACOS devices that are part of the same set, periodically exchange
their weight information with peer ACOS devices.
The VRRP-A state machine determines the Active or Standby status based
on received weight information. Based on the newly computed weight, a
failover will occur from an ACOS device of a lower weight to another
ACOS device of a higher weight.
Preemption based on weight is always enabled. Preemption based on prior-

ity can be enabled or disabled.
Implementation in Previous Releases
In prior releases, VRRP-A handled failovers based on the VRID priority

and preemption (that is, if preemption was disabled, the ACOS device
would not failover, although tracked events would occur). VRRP-A main-
tained 32 VRIDs in the shared partition. Each VRID had a dynamic priority
ranging from 1 to 255, which is used to determine the Active or Standby sta-
tus of an ACOS device. By default, preemption is enabled, which means
that the ACOS device with the highest priority will be the Active ACOS
device.

When an ACOS device has a higher priority, it would assume the role of an
Active device in a group of ACOS devices, the others would automatically
be placed in a Standby state. If preemption is disabled, no failover will
occur. That is, when a Standby device assumes the Active role and preemp-
tion is disabled, the newly elected Active device will not give up its Active
even when another device with a higher priority becomes available.
Event Tracking for Weight and Priority
An ACOS device Active/Standby can be configured to track VRRP-A

events for weight or priority or for both. While both weight and priority can
be configured to track the exact same events, such as the state of gateways,
trunks, VLANs, interfaces, or routes, how they are accessed and assigned
these values are different.
When you configure VRRP-A using the GUI or command line at the
VRRP-A configuration level, you can specify the priority assigned to each
event. When the event occurs, the value you assign to the event will be
deducted from the priority you configure from 1-255 for the VRID of a
given ACOS device.
However, if you specify a value for a failed event using a VRRP-A failover
template, you are configuring the weight assigned to an event that will be
deducted from a fixed total weight of 65534 assigned to every VRID for an
ACOS device.
The fixed total weight for a VRID is not user configurable, unlike the prior-
ity assigned the VRID for an ACOS device which is configurable. A failed
event will result in a deduction of the weight assigned to the event from the
fixed total weight for the VRID. Since the weight of each VRID is tallied to
figure out the weight and/or priority of an ACOS device, when multiple
devices are configured with VRRP-A, this value is used to gauge the device
that will serve as the Active or the Standby device. When the weight for all
VRRP-A enabled devices are unequal, the device with the highest weight
will serve as the Active device, the rest will be placed in a Standby state.
Template Rules for Shared and Private Partitions

When creating templates in a shared partition, adhere to the following
rules:
• You may create multiple templates, however only one template can be
associated with a particular VRID. For example, if you create two tem-
plates called “template1” and “template2,” you can only associate either
template1 or template2 with VRID1. Assuming template1 and
template2 have different events configured and you want template1 (that
tracks for VLANs and gateways) to also address the events that
template2 tracks (for interfaces and routes), edit template1 to include the

events covered by template2. You cannot associate both templates to

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

Preemption is always enabled on Level 1 (weight) and can be configured to
be as enabled or disabled in Level 2 (priority). With preemption always
being enabled on Level 1, the higher weight of an ACOS device will always

place it in Active state and the remaining ACOS devices in Standby state.
Level 1 weight assignments for events will result in the deduction of that
weight from the VRID when an event occurs. When the weight is reduced
for a particular VRID, it may result in a failover to another device if its total
weight is lower than that of its peer devices. Since preemption works at the
VRID level, any VRID with a higher weight can take over for another
VRID in a different ACOS device of a lower weight. When the original
Active device is operational again, its weight is subject to change, and if it
has the highest weight amongst its peers, it will resume its role and take
over as the Active device.
Precedence Causing a Failover
The VRRP-A policy failover template provides a flexible way of defining

events that will trigger failover of an ACOS device from Active to Standby
state or vice versa. The following briefly summarizes the order in which
VRRP-A failover is determined:
• When the ACOS devices in a VRRP-A configuration have unequal
weight, the one with the higher weight will be the Active device. Refer
to
• If all ACOS devices have equal weight, the ACOS device with the
higher priority will be the Active device. Refer to
• If the two ACOS devices have equal weight and equal priority, the
device with the lower Device ID will be the Active device. Refer to
Higher Weight Scenario
Use the show vrrp-a command to view the Active/Standby status of the
ACOS devices: Note that Unit 1 is the Active device and its weight is
“65534” for VRID1:
AX(config)#show vrrp-a
vrid default
2 (Local) Standby 65534 150 *
became Standby at: May 20 12:10:05 2013
1 (Peer) Active 65534 150
vrid 1

After an event results in a reduction of the weight, Unit 1 now has a weight
of “65334” for VRID1, and a failover was triggered that placed Unit 1 in a
Standby state:
vrid default
vrid 1
2 (Local) Active 65534 150 *
1 (Peer) Standby 65334 200
Higher Priority Scenario

ACOS devices: Note for VRID1 that Unit 1 is the Active device and its
priority is “200:”
vrid default
vrid 1 became Standby at: May 20 12:10:05 2013


After an event results in a reduction of the priority, Unit 1 now has a priority
of “1” for VRID1, and a failover was triggered that placed Unit 1 in a
Standby state:
vrid default
vrid 1
1 (Peer) Standby 65534 1 *
Equal Weight and Priority Scenario

ACOS devices: Note that VRID1 has an unequal weight of “65534” and an
equal priority of “150:”
vrid default
vrid 1
1 (Peer) Standby 65334 150 *
After an event results in an increase in weight, Unit 1 and Unit 2 both have
an equal weight and priority, yet a failover is triggered based on the device

ID. For VRID1, Unit 1 is lower than Unit 2, it is now is in Active state
instead of the Standby state:
vrid default
vrid 1
Events Tracked for Weight via the Templates

Several events can be tracked for weight or priority. However, the failover
policy templates only allow you to specify the weight for each event, not the
priority. If configured using the GUI or the CLI, the following events may
cause a change in the VRID and result in an ACOS device failover:
• Gateway Tracking: VRRP-A periodically tests connectivity to the IPv4
and IPv6 default gateways connection to a real server by pinging them.
If a gateway stops responding, VRRP-A reduces the weight or priority
for the VRID. The weight value to subtract can be specified individually
for each gateway’s IP address that you configure in the tracking events
list.
• VLAN Tracking: If VRRP-A stops detecting traffic on a VLAN,
VRRP-A reduces the weight for the VRID. The weight value to subtract
can be specified individually for each VLAN.
• Trunk Tracking: If the trunk or individual ports in the trunk go down,
can be specified for the trunk and for individual ports within the trunk.
• Interface Tracking: If the link goes down on an Ethernet data port,
can be specified individually for each Ethernet data port.
• Route Tracking: If an IPv4 or IPv6 route matching the specified options
is not in the data route table, VRRP-A reduces the weight for the VRID.

The following graphic visually represents where tracking can be enabled for
an ACOS device:
Configuring VRRP-A Policy-Based Failovers

In this release, VRRP-A policy-based failovers can be configured using
either the GUI or the CLI. Failover policy templates can be configured in
either the shared partition or a private partition. Only one template can be
associated with a VRID. For details on additional template rules, refer to
“Template Rules for Shared and Private Partitions” on page 430.

USING THE GUI
To configure the policy-based failover feature using the GUI, follow these
steps:
1. Go to Config Mode > System > VRRP-A > Failover Policy Template.
The Failover Policy Template window appears.
2. Indicate the Name of the template you would like to create. You may
also assign a name for the template using the General sub-window.
3. Enter the events-based tracking options that will allow you to assign a
weight to every event. When the event occurs, the weight will reduce the
weight of the VRID and may cause a failover. Enter tracking events in
the Gateway, VLAN, Trunk, Interface, or Route tracking tabs:
a. In the General tab, enter the name you wish to assign to the template
that you are creating. If you have already created a template with a
name, it will be displayed here:
b. In the Gateway Tracking window, enter the IPv4 or IPv6 address of

the default gateway and assign a weight for the gateway that will be
reduced from the VRID in the event of a failure. Click on Add when
done:

c. In the VLAN Tracking window, select the VLAN ID from the drop-
down list, assign a timeout value (indicating the duration to wait
before a VLAN is declared dead), and the weight for the VLAN that
will be reduced from the VRID when VRRP-A stops detecting traf-
fic on the VLAN. Click on Add:
d. In the Trunk Tracking window, enter a Trunk ID and the weight for
the trunk or for the individual physical ports. The weight you assign
will be reduced from the VRID in the event of a failure of the trunk
or any port that is being tracked. Click on Add:
e. In the Interface Tracking window, select the physical interface type

from the drop down list and assign a weight for that interface. Vir-
tual interfaces (VEs) cannot be tracked. The weight of any physical
interface (or Ethernet data port) will be reduced from the VRID
when the link goes down. Click on Add.

f. In the Route Tracking window, select the IPv4 or IPv6 route in the
data route table that you wish to track. Indicate the Gateway (IPv4
or IPv6 address of the real server, distance to get to this route, proto-
col, and weight for that route that will be reduced from the VRID in
the event of a failure. Click on Add:
4. Click on OK. Your failover template will be listed in the main failover
template window.

To verify your GUI configuration, do the following:

1. Go to Monitor Mode > System > VRRP-A > VRID. View information
on existing VRID, Units, Local Status, Local Weight, Local Priority,
Peer Device, Peer Status, Peer Weight, Peer Priority and Forced
Standby.
2. Go to Monitor Mode > System > VRRP-A > Status to see information
on your VRRP-A configuration.

USING THE CLI
Failover Policy Templates can be configured using the CLI in either the
shared or the private partition.
Configuring Templates in a Shared Partition:
To configure the policy-based failover feature in the shared partition using

the CLI, follow these steps:
1. Create your failover policy template:
vrrp-a fail-over-policy-template template-name
2. Configure the events you wish to track:

a. For gateway tracking, indicate the gateway IP address and assign a
weight for the gateway in the event of failure:
gateway gateway-IP-address weight value
b. For interface tracking, indicate the interface type, interface number,
and assign a weight for that interface in the event of failure:
interface interface-type interface-number
weight value
c. For route tracking, indicate the route number and assign a weight for
that route in the event of failure:
route route-number subnet weight value
d. For trunk tracking, indicate the trunk identification number and
assign a weight for that trunk in the event of failure:
trunk trunk-id weight value
e. For VLAN tracking, indicate the VLAN identification number, the
timeout value, and assign a weight for that trunk in the event of fail-
ure:
vlan vlan-id timeout timeout-value weight
value
3. Assign a failover template to a VRID. From the VRID configuration

level, issue the following command:
vrrp-a vrid default-vrid-id
[no] template policy-template-name
Note: Only one template can be assigned to a VRID in either the shared or pri-
vate partition.

Configuring Templates in a Private Partition:
To configure the policy-based failover feature in a private partition using the

CLI, follow these steps:
1. Indicate the network partition:
partition partition-number network-partition
2. Switch to the active partition from the privilege EXEC configuration

mode:
active-partition partition-number
3. Enter the privilege EXEC mode by exiting the partition configuration

mode and the configuration mode:
exit
4. Create your failover policy template:

vrrp-a fail-over-policy-template template-name
5. Configure the events you wish to track:

a. For gateway tracking, indicate the gateway IP address and assign a
weight for the gateway in the event of failure:
gateway gateway-IP-address weight value
b. For interface tracking, indicate the interface type, interface number,
and assign a weight for that interface in the event of failure:
interface interface-type interface-number
weight value
c. For route tracking, indicate the route number and assign a weight for
that route in the event of failure:
route route-number subnet weight value
d. For trunk tracking, indicate the trunk identification number and
assign a weight for that trunk in the event of failure:
trunk trunk-id weight value
e. For VLAN tracking, indicate the VLAN identification number, the
timeout value, and assign a weight for that trunk in the event of fail-
ure:
vlan vlan-id timeout timeout-value weight
value
6. Assign a failover template to a VRID. From the VRID configuration

level, issue the following command:
vrrp-a vrid default-vrid-id
[no] template policy-template-name

7. Verify your configuration using the following show commands:

• Enter the show vrrp-a configuration command to display the
VRRP-A version number, the configuration of the VRID, and the
events that are part of a template.
show vrrp-a config
• Enter the show vrrp-a fail-over-policy-template command to dis-
play the different templates that you have created. Templates are
displayed in alphabetical order and the contents of the template are
displayed: show vrrp-a fail-over-policy-template
• Enter the show vrrp-a command to display the VRRP-A configura-
tion for all ACOS devices.
show vrrp-a
• Enter the show vrrp-a detail command to display the events that
caused the failover to occur.
show vrrp-a detail
8. You can delete a template using the “no” form of the command when
you specify the name of the template you created:
[no] vrrp-a policy-template template name
Failover Policy Template Error Message

When you create the Failover Policy Template, you may see the following
error message:
Are you sure to remove the template and all the
references?[yes/no]:
This error message will occur when you try to delete a failover template.
VRRP-A Failover Policy Template Configuration Examples

The following commands help you to create a template called “template1”
and specify events that will reduce the weight of the VRID:
AX(config)#vrrp-a fail-over-policy-template template1
AX(config-failover-policy)#interface ethernet 1 weight 200
AX(config-failover-policy)#gateway 20.20.20.20 weight 200
AX(config-failover-policy)#vlan 10 timeout 2 weight 200
AX(config-failover-policy)#route 20.20.20.0 /24 weight 200
AX(config-failover-policy)#trunk 1 weight 200

Use the show vrrp-a fail-over policy-template command to display the

template configuration:
AX(config)#show vrrp-a fail-over-policy-template
vrrp-a fail-over-policy-template template1
interface ethernet 1 weight 200
gateway 20.20.20.20 weight 200
trunk 1 priority-weight 200
route 20.20.20.0 255.255.255.0 weight 200
The following example shows you how to attach the template called “tem-
plate 1” to VRID 1 in the shared partition:
AX(config)#vrrp-a vrid 1
AX(config-vrid)#fail-over-policy-template template1
Show that the template is attached to the VRID group:

AX(config)#show vrrp-a config | section vrid 1
vrrp-a vrid 1
fail-over-policy-template template1
To view a failover policy template for VRID1, look at the running configu-
ration. In the following example, see that VRID 1 is now associated with the
template called “interface.”
AX(config)#show run | section vrid 1
vrrp-a vrid 1
fail-over-policy-template interface

Failover Policy Template in a Private Partition

1. Configure a template in a private partition called “p1” and switch to the
active partition from the privilege EXEC configuration mode. Create
your failover policy template called “template2-p1.” Configure the
events you wish to track:
AX(config)#partition p1 network-partition
AX(config-partition)#exit
AX(config)#exit
AX#active-partition p1
Currently active partition: p1
AX-Active[p1](config)#vrrp-a fail-over-policy-template template2-p1
AX-Active[p1](config-failover-policy)#interface ethernet 1 weight 200
AX-Active[p1](config-failover-policy)#vlan 21 timeout 2 weight 200
AX-Active[p1](config-failover-policy)#gateway 21.21.21.21 weight 200
AX-Active[p1](config-failover-policy)#route 21.21.21.0 /24 weight 200
AX-Active[p1](config-failover-policy)#trunk 2 weight 200
2. Show private partition configuration:

AX-Active[p1](config)#show vrrp-a fail-over-policy-template
vrrp-a fail-over-policy-template template2-p1
route 21.21.21.0 255.255.255.0 weight 200

Show Command Configuration Examples

To view the reason for a failover, the show vrrp-a command on the Active
ACOS device will display the template event that has caused the failover:
vrid default
2 (Peer) Standby 65534 150 *
vrid 1
Detected local policy based fail over events:
If you specify the name of the template, the show vrrp-a fail-over-policy-
template command will display the contents of that template:
AX(config)#show vrrp-a fail-over-policy-template template1
route 20.20.20.0 255.255.255.0 weight 200

Use the show vrrp-a detail command to display comprehensive informa-

tion on your current VRRP-A configuration:
AX(config)#show vrrp-a detail
vrid default
...
VRRP-A stats
Peer: 1, vrid default
Port 1: received 25685 missed 3
...
Total packets sent for vrid default: 58524

Sent from port 1: 29262
Sent from port 7: 29262
...
Peer IP[1]: 7.7.7.1
To view specific information on a particular VRID, you can use the show
vrrp-a config command and specify the name of the VRID:
AX(config)#show vrrp-a conf | section vrid 1
vrrp-a vrid 1

To view information on all the fail-over policy templates, you can use the
show vrrp-a fail-over-policy-template:
AX(config)#show vrrp-a fail-over-policy-template
vrrp-a fail-over-policy-template interface
vrrp-a fail-over-policy-template trunk
vrrp-a fail-over-policy-template gateway
vrrp-a fail-over-policy-template route
route 4.4.4.0 255.255.255.0 weight 200
vrrp-a fail-over-policy-template vlan
route 20.20.20.0 255.255.255.0 weight 200
3. Use the show vrrp-a configuration command to display the entire

VRRP-A configuration:
AX(config)#show vrrp-a config
vrrp-a device-id 2
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid 1
floating-ip 2002::41:41:41:105
floating-ip 2002::31:31:31:105
tracking-options
vrrp-a interface ethernet 7
vrrp-a fail-over-policy-template interface

vrrp-a fail-over-policy-template trunk

vrrp-a fail-over-policy-template gateway
vrrp-a fail-over-policy-template route
route 4.4.4.0 255.255.255.0 weight 200
vrrp-a fail-over-policy-template vlan
route 20.20.20.0 255.255.255.0 weight 200


ACOS Virtual Chassis System
ACOS Virtual Chassis System (aVCS) enables you to manage multiple

ACOS devices as 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 virtual chassis, and are managed by the vMas-
ter.
aVCS, as a management tool, provides high availability functionality on the

ACOS device with the help of VRRP-A and High Availability across two or
more ACOS devices.
In an aVCS chassis, there is a single point of management, and the vMaster

acts as a controller for vBlades. The vMaster controller provides centralized
storage of the entire ACOS device configuration. Any configuration
changes from the vMaster controller are automatically propagated to the
vBlades.
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.
This chapter describes aVCS and how to configure it.
For deployment and upgrade instructions, see the following sections:

• “Deploying a Virtual Chassis (first-time deployment only)” on
page 471
• “Upgrading a Virtual Chassis” on page 493
• “Adding a Configured ACOS Device to a Virtual Chassis” on page 493
• “Replacing a Device in a Virtual Chassis” on page 500
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 certifi-
cates and keys, aFleX policies, black/white lists, and system logs. The
management 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.

Overview
Note: Before performing a system-reset, always create a system backup of the
ACOS device to allow you to always restore be able to restore the ACOS
device from the backup when necessary.
Overview
An aVCS virtual chassis contains multiple ACOS devices (Figure 61). The
vMaster acts as a controller for the other devices (vBlades), which function
as blades in the virtual chassis. Apart from individual device management
and VCS configurations, the vMaster can take care of the following opera-
tions:
• Synchronize configurations
• Synchronize certificates
• Synchronize keys
• Synchronize aFleX policies
• Synchronize black/white lists
• Synchronize code versions
FIGURE 61 Virtual Chassis – Multiple Physical Devices

Overview
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 62.
FIGURE 62 vMaster - Control Point for all Devices
Configuration Management
When you make a configuration change on the vMaster, the vMaster sends
the configuration change to the running-config on each vBlade. For exam-
ple, if you create a new SLB server, the vMaster sends the server to the run-
ning-configs on each of the vBlades. When you save the configuration on
the vMaster, the vMaster writes the contents of its running-config to its
startup-config. Likewise, each vBlade’s running-config is saved to that
vBlade’s startup-config.
Once the virtual chassis is fully operational, all devices in the virtual chassis
have exactly the same set of configuration profiles. This includes the
startup-config and any custom configuration profiles.

Overview
Software Version Management
The vMaster also ensures that each device is running the same software ver-
sion. For example, in Figure 63, when a vBlade joins the virtual chassis,
aVCS detects that the device is running a different software version than the
vMaster is running. The vMaster replaces the software image on the vBlade
and reboots it to place the image change into effect.
FIGURE 63 vMaster - Software Upgrades on Other Devices
Likewise, aVCS checks to ensure that the vBlade has the latest configura-
tion. If the vBlade’s configuration is not up-to-date, the vMaster updates the
vBlade’s configuration.
vMaster election, configuration updates, and software version updates are

described in more detail in later sections.

Overview
High Availability
High Availability (HA) is an ACOS feature that provides ACOS
device-level redundancy to ensure continuity of service to clients. In HA
configurations, ACOS devices are deployed in pairs. If one ACOS device in
the HA pair becomes unavailable, the other ACOS device takes over. For
more information on HA, refer to “High Availability” on page 267.
This release supports the same High Availability (HA) features supported in
previous releases. You can use either HA or VRRP-A with aVCS. If you use
HA, an aVCS virtual chassis can contain a maximum of only 2 devices. If
you use VRRP-A, an aVCS virtual chassis can contain a maximum of 8
devices.
Configuration Preferences
To use redundancy with Layer 2/3 virtualization capabilities, use VRRP-A.

HA does not support Layer 2/3 virtualization.
For transparent mode deployments, configure HA since VRRP-A does not

support the transparent mode.
VRRP-A
The current release supports VRRP-A, providing device redundancy.
VRRP-A is the A10 Thunder Series and AX Series implementation of the
High Availability protocol that is completely different from the industry-
standard implementation of Virtual Router Redundancy Protocol (VRRP).
For purposes of operational familiarity, it borrows concepts from VRRP, but
is significantly different from VRRP. VRRP-A will not inter-operate with
VRRP.
VRRP-A simplifies configuration of multi-system redundancy, and allows

up to 8 ACOS devices to serve as mutual backups for IP addresses. VRRP-
A also provides redundancy with Layer 2/3 virtualization capabilities.

supported. For transparent/inline deployments, use the older High Availabil-
ity (HA) feature instead.

Overview
For more information on VRRP-A, refer to “VRRP-A High Availability” on
page 355.
supported. For transparent/inline deployments, use the HA feature instead.
vMaster Election
Each aVCS virtual chassis has a single vMaster that acts as a controller
module for the other devices (the vBlades). 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 nec-
essary to understand different configuration scenarios that impact vMaster
selection for aVCS, for HA, for VRRP-A, and for aVCS with HA or VRRP-
A:
• aVCS First Time Deployment—With aVCS, when a vMaster and mul-
tiple vBlades are configured, for the first time deployment, set the VCS
device id and the VCS priority for each ACOS device. An ACOS device
will become the vMaster if the configured VCS priority among all the
other ACOS devices in the aVCS configuration is highest. If all the
ACOS devices in the aVCS configuration have the same VCS priority,
then the ACOS device with the lowest device ID will become the vMas-
ter. Each ACOS device in this case will be a stand-alone device, without
any active or standby pairs. The ACOS devices will function as 7 inde-
pendent ACOS devices. To avoid having to configure each individual
ACOS device separately, configure only one ACOS device that will
serve as the vMaster and automatically configure the remaining 7 ACOS
devices.
• HA Active/Standby Device Selection—Just like the previous scenario,
with two ACOS devices, one device configures the other device, how-
ever, the devices are no longer stand-alone devices. Instead, the HA con-
figuration will place one device as the Active device and the other as the
Standby device. In this case, the device with the higher priority will be
the designated as the vMaster.
• VRRP-A Active/Standby Device Selection—When VRRP-A is con-
figured, 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

Overview
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 details on VRRP-A tracking options, refer to “VRRP-A High Avail-

ability” on page 355. For details on VRRP-A failover templates, refer
to, “VRRP-A Policy-Based Failover Template” on page 429.
• aVCS and VRRP-A vMaster Selection—When aVCS and VRRP-A
are configured to work in conjunction, it will result in a set up in which
all ACOS devices will be able to process traffic as an Active/Standby
pair, but these Active/Standby pairs will be configurable using one
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, configure the Active and Standby devices using one 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.
VRRP-A has its own weight and priority algorithm to determine which
ACOS device is the Active or the Standby device, however, 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 and Priority” on page 430. You can force a
device to serve as a vMaster without dynamic election by temporarily
assigning it a higher priority.
First-Time Deployment
The first time you deploy a virtual chassis, 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 virtual chassis, even if the configured priority is higher
on another device. This is due to the dynamic priority value assigned by
aVCS. Figure 66 shows an example.

Overview
• Device ID – If all devices have the same configured priority, the device
with the lowest aVCS device ID is elected to be the vMaster
Figure 64 and Figure 65 show examples for each of these parameters. In

these examples, all devices in the virtual chassis are booted at the same
time.
FIGURE 64 vMaster Election in First-Time Deployment - Same Priority

Value on each Device

Overview
FIGURE 65 vMaster Election in First-Time Deployment - Different Priority
Values Configured
Figure 66 shows an example of dynamic priority value assigned by aVCS.

Overview
FIGURE 66 vMaster Election in First-Time Deployment - one device
booted first
Dynamic Priority
The configurable aVCS priority is a static value in each device’s configura-
tion. 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 possible. Once a device
becomes vMaster, its dynamic priority ensures that it will remain the vMas-
ter, 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 vir-
tual chassis.
The dynamic priority is not configurable. However, you can force a vBlade
to become the vMaster. (See “Forced vMaster Takeover” on page 463.)

Overview
Heartbeat Messages
At regular intervals (the heartbeat time interval), the vMaster sends heart-
beat messages to each of the vBlades, to inform them that the vMaster is
still up, as shown in Figure 67.
FIGURE 67 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.

Overview
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 mes-
sages. 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 68.
FIGURE 68 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 virtual chassis is rejoined, based on the device’s
dynamic priority value. (See “Dynamic Priority” on page 460.)
Forced vMaster Takeover

You can force a vBlade to take over as vMaster, without changing the vMas-
ter-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.

Overview
FIGURE 69 Forced vMaster Takeover
Automated Configuration Synchronization

aVCS automatically synchronizes configuration information within the vir-
tual chassis. Configuration changes are synchronized in real-time as they
occur.
All configuration changes are synchronized, even changes to device-spe-

cific parameters such as hostnames and IP addresses. aVCS configuration
synchronization ensures that each device in the virtual chassis has a com-
plete set of configuration 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 70).

Overview
FIGURE 70 aVCS 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 exam-
ple, 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 71).

Overview
FIGURE 71 Common Parameters

Overview
Interface parameters are unique to each device and include the aVCS device
number (Figure 72).
FIGURE 72 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 HA or VRRP-A configura-

tion to specific devices. For more information on manual synchronization
using HA, refer to “Manually Synchronizing Configuration Information” on
page 335. For more information on manual synchronization using VRRP-A,
refer to “Manually Synchronizing the Configuration” on page 379.
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

Overview
vMaster is newer, the vBlade downloads the image from the vMaster, 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.
Virtual Chassis Management Interface

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 con-
nection goes to the vMaster You can make configuration 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 context to the vBlade, use the
following command at the Privileged EXEC level or the global configura-
vcs device-context device-id
The device-id is the aVCS ID of the vBlade.
The management session will change from the vMaster to the specified
vBlade. For additional information, refer to “aVCS CLI-session Manage-
ment Enhancements” on page 484.

Overview
Requirements
aVCS has the following requirements.
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 / HA session synchronization will be the gating factor in
terms of latency.
Note: 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 Image Location

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

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

Number of Partitions with
Layer 2/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.
Changing the System Time in an aVCS Virtual Chassis

If you need to set or change the system time on a vBlade in an aVCS 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.

aVCS Parameters
aVCS Parameters
Table 23 lists the aVCS parameters you can configure using either the CLI
or the GUI. The current release adds support for aVCS configuration using
the GUI. For details, refer to in the “Using the GUI” section in “Deploying a
Virtual Chassis (first-time deployment only)” on page 471. The screens
show the parameters that are described in Table 23.
Note: aVCS reload is required to place any aVCS-related configuration changes

into effect.
TABLE 23 aVCS Parameters

Virtual Chassis Parameters
Set ID High availability domain. All devices in the aVCS For set ID, use 1-7.
virtual chassis must also belong to the same If using HA, use 1-2 for the device ID.
VRRP-A set.
Default: not set
Note: The set ID does not automatically configure
VRRP-A on the devices in the virtual chassis.
VRRP-A requires additional configuration. (See
“VRRP-A High Availability” on page 355.)
[no] vrrp-a set-id num
or
[no] ha id {1 | 2} [set-id num]
Config Mode > HA > Setting > HA Global - Gen-
eral
Device ID Unique ID of the device within the virtual chassis. 1-8 (VRRP-A) or 1-2 (HA)
[no] vrrp-a device-id num Default: not set
Note: If using HA, see the “Set ID” row above.
Floating IP Management address of the virtual chassis. Valid IPv4 or IPv6 address
address Navigating to a floating IP address accesses the cur- Default: not set
rent vMaster of the virtual chassis.
Up to 6 floating IP addresses are supported.
aVCS automatically binds one of the device’s avail-
able IP interfaces to the virtual chassis management
IP address.
[no] vcs floating-ip ipaddr
{subnet-mask | /mask-length}
Multicast IP IP address to which devices in the virtual chassis Valid IPv4 multicast address
address send vMaster-election traffic. Default: 224.0.0.210
[no] vcs multicast-ip ipaddr

aVCS Parameters
TABLE 23 aVCS Parameters (Continued)
Multicast port Protocol port from which devices in the virtual 1-65535
chassis send vMaster-election traffic. Default: 41217
[no] vcs multicast-port portnum
SSL Secure Sockets Layer (SSL) for encryption of uni- Enabled or disabled
cast traffic, such as configuration synchronization Default: disabled
traffic, between devices.
This option does not apply to multicast traffic.
[no] vcs ssl-enable
Heartbeat time Number of seconds between transmission of kee- 1-60 seconds
interval palive messages from the vMaster to vBlades. Default: 3 seconds
[no] vcs time-interval seconds
Heartbeat dead Maximum number of seconds to wait for a kee- 5-60 seconds
interval palive message from the vMaster before triggering Default: 10 seconds
vMaster re-election.
[no] vcs dead-interval seconds
Device Configuration Parameters
Device ID Unique ID of the device within the virtual chassis. 1-8
[no] vcs device device-id Default: not set
Priority Static priority value used during vMaster election. 1-255
Higher priority values are preferred over lower pri- Default: 0 (not set)
ority values. For example, priority value 200 is pre-
ferred over priority value 2.
Note: This is only one of the parameters used dur-
ing vMaster election. See “vMaster Election” on
page 456.
[no] priority num
Unicast port Protocol port used to create TCP connections 1-65535
between the vMaster and vBlades. This connection Default: 41216
is used for configuration synchronization.
[no] unicast-port portnum

Deploying a Virtual Chassis (first-time deployment only)
TABLE 23 aVCS Parameters (Continued)
Election Ethernet port(s) used for vMaster election traffic. One or more interfaces
interfaces Up to 6 election interfaces are supported. Default: not set
aVCS selects one of the interfaces to use for vMas-
ter election. The same interface is also used for con-
figuration synchronization, and to bind to the virtual
chassis’ floating IP address. If the selected interface
becomes unavailable, aVCS selects another of the
available vMaster election interfaces.
Note: It is recommended not to disable any of the
vMaster election interfaces. Doing so can interrupt
communication between the vMaster and a vBlade,
and cause the vBlade to reload.
[no] interfaces
{ethernet portnum | management |
trunk trunk-num | ve ve-num}
Note: 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.
vMaster mainte- Seconds after which the vMaster will be main-
nance tained.
Deploying a Virtual Chassis (first-time deployment

only)
To deploy aVCS for the first time, perform the following steps.
Caution: Use this procedure only for first-time deployment of aVCS. If you are
upgrading ACOS devices on which aVCS is already configured, see
“Upgrading a Virtual Chassis” on page 493.
1. On the ACOS device to be used as the vMaster, configure aVCS. (See
“Details for step 1” on page 472.)
Note: If you plan to use Layer 2/3 virtualization, do not configure it yet.
2. After completing aVCS configuration on the vMaster, enable aVCS on

the vBlades, and configure aVCS-related parameters for the vBlades.
3. Reload aVCS on the vBlades. At this point, the vMaster synchronizes
the configuration to the vBlades.

4. View the running-config on the vMaster and on the vBlades to verify
that both the vMaster and vBlades configurations are synchronized.
The steps above establishes the first-time base aVCS configuration syn-
chronization from vMaster to vBlades. After this, subsequent configura-
tion changes on the vMaster are automatically be synchronized to the
vBlades.
5. If you plan to use Layer 2/3 virtualization, configure it on the vMaster
Details for step 1

This section provides details for step 1 in the procedure above. Use these
steps only for first-time aVCS deployment.
For first-time aVCS deployment only, perform the following steps on each
device.
1. Configure basic system settings:
• Management interface and default gateway
• Hostname
• Ethernet interfaces
• VLANs
• Routing
2. Configure the following aVCS settings related to high availability:

• Chassis ID – Assign each device to the same set. If you plan to use
VRRP-A, this is the VRRP-A set ID. If you plan to use HA (the
older implementation of high availability), this is the HA set ID.
• Device ID – Assign a unique device ID to each device. If you plan
to use VRRP-A, this is the VRRP-A device ID. If you plan to use
HA (the older implementation of high availability), this is the HA
device ID.
You can use HA (the older implementation of high availability) or

VRRP-A. Use the same type of high availability on all devices. (See
“High Availability” on page 455.)
3. Enable aVCS.
4. Configure aVCS device settings:

• vMaster-election interface – Ethernet interface(s) to use for vMaster
election. Generally, these are the interfaces connected 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.
USING THE GUI

Configure and view information for the ACOS Virtual Chassis System
(aVCS). This feature allows you to manage multiple ACOS devices as a sin-
gle, virtual chassis using the GUI.
Before Installing aVCS
Before you install aVCS, you must define the chassis-id and set-id. This can
be done using VRRP-A:
1. Go to Config Mode > System > VRRP-A -> Setting.
A partial view of the window that appears is shown below:
2. Enter the Device-ID.
3. Enter the Set-ID.
4. Click OK.

aVCS GUI Configuration Procedures
For aVCS configuration, you will have access to various screens:

1. Go to Config Mode > System > aVCS > General.
a. When the local device has been set, enable aVCS by clicking on the
aVCS Enabled check box. When you click on Enabled, an addi-
tional option to specify a vmaster-take-over value will appear.
Note: Note: If you receive a message indicating that there is currently an active
admin configuration session, you must clear the session before you can
continue with the configuration tasks described below.
b. Indicate the vmaster-take-over value. vmaster-take-over is for a

vBlade to take over the vMaster’s role. If you are logged into a
vBlade device, indicating this option will allow the vBlade to take
over as the master. Indicate a value from 1-255.
c. Click on OK when done.
2. Go to Config Mode > System > aVCS > Settings. A window will appear
that shows three major configuration sections: Chassis, Device, and
aVCS Action.

3. In the Chassis pane, configure chassis-related information:
a. Enter the Floating IPv4 or IPv6 Address, the subnet Mask or Prefix
Length.
b. Click on Add. Your configuration will be added to the table below
your configuration fields.
c. Enter the Multicast IP address.
d. Enter the Multicast Port.
e. Enter the Time Interval.
f. Enter the Dead Interval.
g. Enter the Failure Retry Count. During the aVCS start up process,
the aVCS process may encounter some errors. Indicate the number
of times aVCS will retry before it gives up trying to enable aVCS.
h. Click on the SSL Enable checkbox to enable Secure Socket Layer
encryption.
i. Click on the vMaster-message-buffer checkbox to activate a buffer
for vMaster messages.
Note: You must enter the multicast IP address and the multicast port.

4. In the Device pane, configure device-related information:
Note: You must enter a Device ID, allocate a Priority, and specify a Unicast Port
for that device.
a. Specify the Device ID.
b. Enter the Priority.
c. Enter the Unicast Port number.
d. Drag and drop interfaces from the Unselected window to the Elec-
tion Interface window. These are the interfaces on which you want
to enable VCS.
e. Click on Enabled.
f. Click on Add. Your configuration will be added to the table listed in
this section.
5. In the aVCS Action section, select the aVCS Reload check-box:
Selecting this checkbox will reload the ACOS device after configuration
is complete.
6. Select the vMaster maintenance checkbox. Selecting this checkbox will

indicate that the vBlade should not take over as the vMaster when the
vMaster is in a maintenance state.
7. Click on OK.

Monitoring Mode
In monitoring mode, from Monitor Mode > System > aVCS display aVCS
Summary, Statistics (similar to the output for the show vcs statistics CLI
command), or Images (similar to the output for the show vcs images CLI
command). Access the following aVCS Monitor pages to view the existing
aVCS configuration:
1. Go to Monitor Mode > System > aVCS > Summary. The following win-
dow will appear:
2. Go to Monitor Mode > System > aVCS > Statistics window to view the
different statistics displayed for the ACOS devices configured in an
aVCS setup.

a. View the configured Parameters section of the Statistics window:
b. View the Context section of the Statistics window:

c. View the configured Counters section of the Statistics window:
3. Go to Monitor Mode > System > aVCS > Images. View the existing
software primary or secondary images that are available on the hard
disk or on the compact flash:
USING THE CLI

Perform the following steps on each device.
1. Enter the configure command to access the global configuration level of
the CLI.
2. To specify the chassis ID and device ID, use the following VRRP-A
commands or HA command at the global configuration level of the CLI.
If using VRRP-A:
• vrrp-a set-id num
• vrrp-a device-id num
If using HA:
ha id {1 | 2} [set-id num]

3. To enable aVCS, enter the following command at the Privileged EXEC
level of the CLI:
vcs enable
4. To specify the floating interface for virtual chassis management, use the
following command at the global configuration level of the CLI:
[no] vcs floating-ip ipaddr
{subnet-mask | /mask-length}
The address must be in the same subnet as an IP interface configured on
the device. Make sure the address is not already assigned to another
device on the network.
5. To configure device-specific aVCS settings, use the following com-

mands:
vcs device device-id
Enter this command at the global configuration level of the CLI. The
command creates the aVCS profile for the device and changes the CLI
to the configuration level for it. At this level, use the following com-
mands:
enable
This command enables aVCS.
interfaces {ethernet portnum | management |
trunk trunk-num | ve ve-num}
This command specifies the interface(s) used for aVCS vMaster election
traffic. Up to 6 vMaster election interfaces are supported.
priority num
This command specifies the vMaster-election priority for the device,
1-255.
Note: This command is required only if you want to make a specific device the
vMaster instead of allowing aVCS to select the device with the lowest
device ID as the vMaster. This value is important when dynamic priority
does not apply.

First-Time Deployment Example

The following commands deploy a virtual chassis containing two devices.
Note: For simplicity, configuration of basic system settings is not shown.
Commands on Device 1
To begin, the following commands configure the high availability set ID
and device ID:
AX-1#configure
AX-1(config)#vrrp-a set-id 1
The following command enables aVCS:
AX-1#vcs enable
The following command configures the management address for the virtual
chassis:
AX-1(config)#vcs floating-ip 192.168.100.169 /24
The following commands configure the aVCS profile for the device:
AX-1(config)#vcs device 1
AX-1(config-vcs-dev)#enable
AX-1(config-vcs-dev)#interfaces management
AX-1(config-vcs-dev)#priority 125
AX-1(config-vcs-dev)#exit
AX-1(config)#vcs reload
AX-2#configure
AX-2#vcs enable

Forcing vMaster Takeover

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 following
command at the Privileged EXEC level or the global configuration level
of the CLI:
vcs device-context device-id
The device-id is the aVCS ID of the vBlade.
[no] vcs vmaster-take-over temp-priority
The temp-priority value can be 1-255.
Unless you use this command on more than one vBlade, it does not mat-
ter which value within the range 1-255 you specify. (See “Temp-priority
Value” on page 482.)
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
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 con-
figured 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 command.

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 col-
umn of the Members section.
• If you are logged directly onto a device through its management inter-
face 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 Inter-
face” on page 467.)
You also can determine the device ID by entering the following command:
show running-config | include local-device
For example, the following command indicates that the device you are
logged onto is aVCS device 2:
ACOS#show running-config | include local-device
vcs local-device 2
Displaying aVCS Information

To display aVCS information, use the following commands:
show vcs summary

This command shows global virtual chassis parameters, and lists the current
role (vMaster or vBlade) of each device in the virtual chassis.
show vcs stat

This command shows detailed statistics.
show vcs images

This command lists the installed aVCS-capable ACOS software image.

aVCS CLI-session Management Enhancements

This release includes the following enhancements to the ACOS Virtual
Chassis System (aVCS).
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 com-
mand that affects only the local device, and the command does not explic-
itly 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 man-
agement IP address of a vBlade, that vBlade is the local device.
• If you change the device context or router content 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:
ACOS(config)#mac-age-time 444
This operation applied to device 1
This type of configuration change is device-specific. However, the com-

mand does not specify the device ID to which to apply the configuration
change. Therefore, the change is applied to the local device. In this exam-
ple, the local device is device 1 in the aVCS virtual chassis.
The message is not necessary if you explicitly specify the device, and there-
fore is not displayed:
ACOS(config)#mac-age-time 444 device 2

Notes
• For commands that access the configuration level for a specific configu-
ration item, the message is displayed only for the command that
accesses the configuration level. For example:
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 exceptio 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
ACOS 2.7.1 allows the device designated as the aVCS master (vMaster) in
a cluster to failover when the device serving as the Active device running
VRRP-A fails over to the Standby device. When the Standby device
assumes the role as the Active device, it will also automatically serve as the
vMaster for the aVCS cluster. This ensures that the device that assumes
master configuration also serves as the active data path. Configuring the
VRID affinity will cause the aVCS master 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 facili-
tates troubleshooting efforts.
USING THE GUI
The GUI does not allow you to configure a master affinity to the Active
device running VRRP-A.

USING THE CLI
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 following command:
[no] affinity-vrrp-vrid vrid-group
Where vrid-group stands for the VRRP-A VRID status that you want this
mastership affinity to follow. The default VRID is 0. You can specify a
group of 1-31.
aVCS provides configuration management capabilities, so as long as this

command is issued per device and is associated with each device in the
aVCS cluster that is running VRRP-A, any time there is a failover, the
vMaster and the VRRP-A Active device will remain one and the same.
Note: Currently, two (2) devices can be deployed in a aVCS configuration.
Command Example
ACOS-Active-vMaster[1/1](config)#vcs
ACOS-Active-vMaster[1/1](config)#vcs device 1
ACOS-Active-vMaster[1/1](config-vcs-dev)#?
affinity-vrrp-vrid vmaster affinity to vrid active
clear Clear or Reset Functions
do To run exec commands in config mode
enable Enable device
end Exit from configure mode
exit Exit from configure mode or sub mode
interfaces Interfaces over which election protocol runs

no Negate a command or set its defaults
priority Device priority
show Show Running System Information
unicast-port Port used in unicast communication
write Write Configuration
ACOS-Active-vMaster[1/1](config-vcs-dev)#affinity-vrrp-vrid ?
<0-31> vrid group
ACOS-Active-vMaster[1/1](config-vcs-dev)#affinity-vrrp-vrid 0
ACOS-Active-vMaster[1/1](config-vcs-dev)#vcs device 2
ACOS-Active-vMaster[1/1](config-vcs-dev)#vcs device 3
ACOS-Active-vMaster[1/1](config-vcs-dev)#end
To verify your configuration, use the show running command. The follow-
ing excerpt of a running configuration displays your aVCS VRID affinity
configuration:
AX3200-12-1-Active-vMaster[1/1]#show running
...
vrrp-a device-id 1
vrrp-a set-id 1
vcs enable
vcs vMaster-id 1
vcs config-info 8872749ff5b45e57 1790
vcs chassis-id 1
vcs floating-ip 192.168.19.254 /24
vcs multicast-ip 224.0.0.210
vcs failure-retry-count -1
vcs device 1
priority 127
interfaces ve 19
enable

affinity-vrrp-vrid 0
vcs device 2
priority 126
interfaces ve 19
enable
vcs device 3
priority 125
interfaces ve 19
enable
vcs local-device 1
...
Option To Display Information for the Active VRRP-A Device
This release provides a new show command option, active-vrid, that dis-
plays information for the active VRRP-A device. This option is useful in
aVCS deployments that also use VRRP-A.
In aVCS deployments, the virtual chassis has a floating IP address that

serves as the management interface for the virtual chassis. When you enter
show commands from within a session on the virtual chassis’ floating IP
address, the information in the output comes from the vMaster.
In some cases, the information can differ depending on whether the vMaster
is also the active VRRP-A device.
Note: The active-vrid option is displayed in the CLI help only if aVCS and
VRRP-A both are enabled. Otherwise, the option is inapplicable and is
not displayed.
Examples
The following examples show how the output can differ depending on
whether the vMaster is also the active VRRP-A device. They also show use
of the active-vrid option.
All of the commands are entered in the CLI session on the virtual chassis’s
floating IP address.

Output Examples for show arp
The following command displays the ARP table. In this example, the ACOS
device is the vMaster for an aVCS virtual chassis, and is also the active
VRRP-A device.
ACOS-Active-vMaster[1/1]#show arp
Total arp entries: 2 Age time: 300 secs
IP Address MAC Address Type Age Interface Vlan
---------------------------------------------------------------------------
192.168.18.1 aaaa.aaaa.aaaa Dynamic 9 Management 1
192.168.18.120 bbbb.bbbb.bbbb Dynamic 251 Management 1
Since neither the device nor the active-vrid option is used, by default the
ARP table of the vMaster is displayed. In the following example, a failover
has occurred. The vMaster is a standby VRRP-A device instead of the
active device.
ACOS-Standby-vMaster[1/1]#show arp
---------------------------------------------------------------------------
192.168.18.1 aaaa.aaaa.aaaa Dynamic 11 Management 1
192.168.18.120 bbbb.bbbb.bbbb Dynamic 253 Management 1
Notice that the ARP entries are the same. The information is still from the
vMaster.
In the current release and previous releases, you can use show commands to
determine which device is the active VRRP-A device for a VRID, then use
the device option with the show command to display the information from
the active VRRP-A device. The active-vrid option provides a simpler way
to access the information, as shown in the following example:
ACOS-Standby-vMaster[1/1]#show arp active-vrid default
---------------------------------------------------------------------------
192.168.20.11 cccc.cccc.cccc Dynamic 15 Management 1
192.168.20.13 dddd.dddd.dddd Dynamic 257 Management 1
This output shows the ARP table on the active VRRP-A device for the
default VRID. The CLI prompt does not change, because the CLI session is
still on the virtual chassis’ floating IP address, which is managed by the
vMaster. The information, however, comes from the active device for the
VRID.

Output Examples for show virtual-server
This example is similar to the previous one. The information in the first two
output examples below comes from the vMaster, even though the vMaster is
a VRRP-A standby in the second set of output.
ACOS-Active-vMaster[1/1]#show slb virtual-server
Total Number of Virtual Services configured: 20
Virtual Server Name IP Current Total Request Response Peak
Service-Group Service connection connection packets packets connection
---------------------------------------------------------------------------------------
*vip1(A) 70.70.70.51 Partial Up
port 8080 http 0 0 0 0 0

sg-80 8080/http 0 23 816531 3035452 0
Total received conn attempts on this port: 0
ACOS-Standby-vMaster[1/1]#show slb virtual-server

---------------------------------------------------------------------------------------
*vip1(S) 70.70.70.51 Partial Up
port 8080 http 0 0 0 0 0

sg-80 8080/http 0 23 816531 3035452 0
In both sets of output, the counters for request packets and response packets
are the same, indicating that the statistics come from the same ACOS
device, which is the vMaster.
In the following example, the active-vrid option is used. The statistics

counter values are from the active VRRP-A device for the default VRID. In
this example, the counters show 0; it is likely that failover very recently
occurred.
ACOS-Standby-vMaster[1/1]#show slb virtual-server active-vrid default
----------------------------------------------------------------------------------------
*vip1(A) 70.70.70.51 Partial Up
port 8080 http 0 0 0 0 0

sg-80 8080/http 0 23 0 0 0

Commands That Support the active-vrid Option
The following commands support the active-vrid option:
• All commands that support the device DeviceID option
• vcs device-context command
• All show slb commands that include statistics in the output
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 pro-
vides 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.
USING THE GUI
The current release does not support this option in the GUI.
USING THE CLI
[no] snmp-server contact

on-device DeviceID contact-name
The DeviceID specifies the aVCS ID of the device.
vMaster Maintenance Mode
This release provides a new aVCS option that allows the vMaster to briefly
be placed into maintenance, without triggering failover of the vMaster role
to a vBlade. During the maintenance window, the vBlades continue to oper-
ate, without attempting to failover to the vMaster role.
The default length of the maintenance window is 60 seconds. You can set it
to 0-3600 seconds.

USING THE GUI
On the aVCS Settings page, select the vMaster-maintenance checkbox to

display the configuration field. Edit the value in the field and click OK.
USING THE CLI
To change the length of the vMaster maintenance window, use the following
vcs vMaster-maintenance seconds
You can specify 0-3600 seconds. The default is 60 seconds.
Configurable aVCS Message Buffer
This release enables you to configure a message buffer for messages

between the vMaster and vBlades. This feature is useful in cases where
occasional “burstiness” or “jitter” in the network causes unnecessary
vBlade reloads.
Without message buffering, in case there is a short period of time that vMas-
ter and vBlade lose communication, and during that period of time there is
configuration done on vMaster, after vBlade comes back and finds out the
configuration is out of date, the vBlade asks for the whole configuration
from the vMaster, and reloads itself.
With message buffering, when the vBlade comes back, instead of getting
the whole configuration from the vMaster, the vBlade gets only the incre-
mental changes, which are buffered on the vMaster. In this case, the vBlade
does not need to reload.
Message buffering is disabled by default. When you enable it, you can spec-
ify the following settings:
• Maximum number of seconds a configuration change message can be
buffered – This can be 0-900 seconds. The default is 90 seconds.
• Maximum number of messages that can be buffered – This can be
15-180 messages, and is 30 by default.

Upgrading a Virtual Chassis
USING THE GUI
On the aVCS Settings page, select the vMaster-message-buffer checkbox to

display the configuration fields. Edit the values in the fields and click OK.
USING THE CLI
To configure aVCS message buffering, use the following commands at the

[no] vcs vMaster-message-buffer aging seconds
This command specifies the maximum number of seconds a configuration

change message can be buffered.
[no] vcs vMaster-message-buffer length num-msgs
This command specifies the maximum number of messages that can be

buffered.
To disable the feature, use the following command:
no vcs vMaster-message-buffer
Upgrading a Virtual Chassis

To upgrade, see the release notes for the ACOS release to which you plan to
upgrade.
Adding a Configured ACOS Device to a Virtual Chassis

Caution: By default, when you add a configured ACOS device to a running vir-
tual chassis, the device-specific configuration is retained but the com-
mon 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.

Procedure
To add an ACOS device that already has a configuration to an aVCS chas-
sis:
1. Upgrade the virtual chassis to AX Release 2.6.1 or later ACOS release.
(See the Release Notes for the release to which you plan to upgrade.)
2. Make sure the virtual chassis is running:

a. Log onto the floating IP address (management address) of the vir-
tual chassis.
b. View the virtual chassis status: show vcs summary command
3. Connect the configured ACOS device to the Layer 2 network that con-
tains the other virtual chassis members.
4. Configure aVCS settings on the new device and reload aVCS. (See
“CLI Example” below.)
5. Verify that the device is now a member of the virtual chassis:

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. (See “Replacing a Device in a Virtual Chassis” on page 500.)
For detailed information on how to perform a staggered upgrade for VCS,
refer to “Staggered Upgrade (with VRRP-A)” and “Staggered Upgrade
with no VRRP-A)” in the Release 2.7.0 Release Notes. Staggered upgrade
allows you to perform an upgrade without impacting service.

Overview
Figure 73 shows the process that occurs when you add an ACOS device that
is already configured to a virtual chassis.
FIGURE 73 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 (labelled “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 config-

uration to its virtual chassis configuration.
The vMaster then synchronizes the device’s configuration to the other
vBlades as part of the normal configuration synchronization 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.
More Detailed Example

Figure 74 shows the configuration information present on the vMaster and
on a configured ACOS device added to the virtual chassis, before the con-
figuration merge.

FIGURE 74Configured Device Added to Virtual Chassis - before configuration
merge

Figure 75 shows the results of the configuration merge.
FIGURE 75 Configured Device Added to Virtual Chassis - after

configuration merge

Figure 76 shows the completed merge process, after the admin reloads
aVCS.
FIGURE 76 Configuration with New Device Synchronized to all vBlades

Replacing a Device in a Virtual Chassis
The disable-merge Option
The configuration merge behavior described above occurs by default. If you
want the vMaster to also remove the device-specific configuration informa-
tion from the new device, use the disable-merge option when you reload
aVCS.
Procedure
CLI Example
The following commands configure aVCS settings on a configured ACOS
device to be added to a virtual chassis, and reload aVCS to activate the
aVCS configuration:
AX-3#configure
AX-3#vcs enable
Following the reload of aVCS, the ACOS device joins the virtual chassis as
a vBlade, and its configuration information is migrated to the virtual chas-
sis’ vMaster

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 information to the new device. In this case, when you reload
aVCS on the new device, make sure to use the following option:
disable-merge

CLI Example
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:
AX-3#configure
AX-3#vcs enable
AX-3(config)#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 chas-
sis’ vMaster.
Configurable aVCS Prompts

Use this ACOS 2.7.1 feature to identify the types of devices that are config-
ured in HA pairs or that are running VRRP-A configuration. The feature
allows you to collect device serial numbers that are unique for each device
during the HA or VRRP-A communication and can help you identify the
devices in a same HA group or VRRP-A set.
This user-configurable prompt allows you to add or remove the device host-
name, the aVCS chassis device ID, the aVCS status, the VRRP-A status, or
the HA status. Configuring a prompt is optional. If all the five options are
configured, an example of a prompt may say AX1030-vMaster[7/1](con-
fig)#.

tus}
In the above command, you may configure one or more options. The man-
datory keywords represent one of the following:
• hostname—Display the device serial number of the device in the
prompt. This can be AX 2600 or ACOS 6430.

• ha-status—Display the HA or VRRP-A status in the prompt. For
example, this can be Active, Standby, or ForcedStandby. When you
configure ha-status, the VRRP-A or HA states of a device will be dis-
played in the prompt. ForcedStandby will be displayed when you issue
standby state.
• vcs-status—Display aVCS status in the prompt. For example, this
device can be the vMaster or vBlade. It represents the function or role
of the device in the aVCS set.
• chassis-device-id—Display aVCS device id in the prompt. For
example, this can be 7/1, where the number 7 indicates the chassis ID
and 1 indicates the device ID within the aVCS set.
Note: The aVCS Chassis ID and the aVCS Device ID are configurable as part of
the prompt if aVCS is running. The prompt that you specify will be syn-
chronized and reflected on all the other devices in the aVCS set.
Use the show vcs summary or show ha detail commands to view the ter-
minal prompts that will be displayed.
USING THE GUI

USING THE CLI

device-id
ACOS(config)#terminal prompt hostname vcs-status
To view the aVCS status and chassis device ID, use the following com-
mand:
ACOS(config)#terminal prompt vcs-status chassis-device-id
vMaster[1/1](config)#

To view the aVCS status, chassis device ID, and VRRP-A or HA status, use
the following command:
ACOS(config)#terminal prompt vcs-status chassis-device-id ha-status
Active-vMaster[7/1](config)#
To view the aVCS status, chassis device ID, VRRP-A or HA status, and the
hostname, use the following command:
ACOS(config)#terminal prompt vcs-status chassis-device-id ha-status
hostname
AX1030-Active-vMaster[7/1](config)#
Terminal prompt format: hostname ha-status vcs-status chassis-device-id


Configuration Synchronization without Reload
You can use the ACOS Virtual Chassis System (aVCS) feature to provide
automated configuration synchronization in HA or 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 over using
the manual HA configuration synchronization options:
• 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.
Note: VRRP-A does not use manual configuration synchronization. Instead,

VRRP-A uses aVCS for automatic configuration synchronization.
Note: The solution described in this chapter is supported only for two-device
HA deployments.
Figure 77 shows an example HA deployment that uses aVCS for automated

configuration synchronization.
FIGURE 77 aVCS Used for Automated Configuration Synchronization

VRRP-A with aVCS Deployment Example

The following commands deploy the HA configuration shown in Figure 77.
This example uses VRRP-A. If you plan to use the older implementation
instead, see “HA with aVCS Deployment Example” on page 507.
To begin, the following command enables aVCS:
AX-1#vcs enable
The following commands configure the high availability set ID and device
ID:
AX-1#configure
The following command configures the floating IP address, which is the

management address for the virtual 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.
The following commands configure the aVCS profile for the device.
AX-1(config-vcs-dev)#interfaces ethernet 1
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 configu-
ration.
AX-1(config)#write memory

AX-2#vcs enable
AX-2#configure
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.
HA with aVCS Deployment Example

The following commands deploy aVCS with the older implementation of
HA. The only difference between these commands and the commands for
VRRP-A deployment, are the commands that specify the HA device ID and
set ID.
AX-1#vcs enable
AX-1#configure
AX-1(config)#ha id 1 set-id 1
AX-2#vcs enable
AX-2#configure
AX-2(config)#ha id 2 set-id 1

Note Regarding HA Group ID
For configuration items such as VIPs that can be assigned to an HA group

ID, the group ID must be specified on both HA devices. See “Replacing a
Device in a Virtual Chassis” on page 500.

Overview
Network Address Translation
This chapter describes Network Address Translation (NAT) and how to con-
figure it. NAT translates the source or destination IP address of a packet
before forwarding the packet.
Note: This chapter does not include information about NAT features for Server
Load Balancing (SLB) or for IPv6 migration.
Note: If you use the older implementation of High Availability (HA), only half
the protocol ports on each NAT IP address are available at a given time.
This is because the ACOS device allocates half the ports to one of the
ACOS devices in the HA pair and the other half to the other ACOS
device. This does not occur with VRRP-A. If you use VRRP-A, all the
protocol ports on NAT addresses are available.
Overview
The ACOS device supports traditional, Layer 3 IP source NAT. IP source
NAT translates internal host addresses into routable addresses before send-
ing the host’s traffic to the Internet. When reply traffic is received, the
ACOS device then retranslates addresses back into internal addresses before
sending the reply to the client.
You can configure dynamic or static IP source NAT:

• Dynamic source IP NAT – Internal addresses are dynamically translated
into external addresses from a pool.
• Static source IP NAT – Internal addresses are explicitly mapped to
external addresses.
Configuration Elements for Dynamic NAT

Dynamic NAT uses the following configuration elements:
• Access Control List (ACL) – to identify the inside host addresses to be
translated
• Pool – to identify a contiguous range of external addresses into which to
translate inside addresses
• Optionally, pool group – to use non-contiguous address ranges. To use a
non-contiguous range of addresses, you can configure separate pools,
then combine them in a pool group and map the ACL to the pool group.

Overview
The addresses within an individual pool still must be contiguous, but
you can have gaps between the ending address in one pool and the start-
ing address in another pool. You also can use pools that are in different
subnets.
A pool group can contain up to 5 pools. Pool group members must
belong to the same protocol family (IPv4 or IPv6) and must use the
same HA ID. A pool can be a member of multiple pool groups. Up to 50
NAT pool groups are supported.
If a pool group contains pools in different subnets, the ACOS device
selects the pool that matches the outbound subnet. For example, if there
are two routes to a given destination, in different subnets, and the pool
group has a pool for one of those subnets, the ACOS device selects the
pool that is in the subnet for the outbound route.
The ACOS device searches the pools beginning with the first one added
to the group, and selects the first match. If none of the pools are in the
destination subnet, the ACOS device uses the first pool that has avail-
able addresses.
• Inside NAT setting on the interface connected to the inside host.
• Outside NAT setting on the interface connected to the Internet. Inside

host addresses are translated into external addresses from a pool before
the host traffic is sent to the Internet.
Note: The ACOS device enables you to specify the default gateway for an IP
source NAT pool to use. However, the pool’s default gateway can be used
only if the data route table already has either a default route or a direct
route to the destination of the NAT traffic. In this case, the pool’s default
gateway will override the route, for NAT traffic that uses the pool.
If the data route table does not have a default route or a direct route to the
NAT traffic destination, the pool’s default gateway can not be used. In this
case, the NAT traffic can not reach its destination.
Configuration Elements for Static NAT

Static NAT uses the following configuration elements:
• Static mappings or an address range list – A static mapping is a one-to-
one mapping of an inside address to an external address. An address
range list is a contiguous range of inside addresses and external
addresses to translate them into.
• Inside NAT setting on the interface connected to the inside host.
• Outside NAT setting on the interface connected to the Internet. Inside

host addresses are translated into external addresses from a static map-
ping or a range list before the host traffic is sent to the Internet.

Configuring Dynamic IP Source NAT

To configure dynamic source NAT:
1. Configure an Access Control List (ACL) to identify the inside addresses
that need to be translated.
2. Configure a pool of external addresses to use for translation. To use non-

contiguous ranges of addresses, configure multiple pools and add them
to a pool group.
3. Enable inside source NAT and map the ACL to the pool.
4. Enable inside NAT on the interfaces connected to the inside hosts.
5. Enable outside NAT on the interfaces connected to the Internet.
Note: In addition, on some ACOS device models, if Layer 2 IP NAT is required,

you also must enable CPU processing on the NAT interfaces. This applies
to models AX 2200, AX 2200-11, AX 3100, AX 3200, AX 3200-11,
AX 3200-12, AX 3400, AX 5100, AX 5200, and AX 5200-11. This addi-
tional step is performed at the configuration level for each NAT interface.
The procedures below do not include this additional step.
USING THE GUI

1. To configure an ACL to identify the inside addresses that need to be
translated:
a. Select Config Mode > Network > ACL.
b. Select the ACL type, Standard or Extended, on the menu bar.
c. Click Add.
d. Enter or select the values to filter.
e. Click OK. The new ACL appears in the Standard ACL table or
Extended ACL table.
f. Click OK to commit the ACL change.
2. To configure a pool of external addresses to use for translation:

a. Select Config Mode > IP Source NAT.
b. Select IPv4 Pool or IPv6 Pool on the menu bar.
c. Click Add.
d. Enter a name for the pool.
e. Enter the start and end addresses.

f. Enter the network mask.
g. If the ACOS device is deployed in transparent mode, enter the
default gateway to use for NATted traffic.
h. To use session synchronization for NAT translations, select the HA
group.
i. Click OK.
3. To enable inside source NAT and map the ACL to the pool:
a. Select Config Mode > IP Source NAT, if not already selected.
b. Select Binding on the menu bar.
c. Select the ACL number from the ACL drop-down list.
d. Select the pool ID from the NAT Pool drop-down list.
e. Click Add. The new binding appears in the ACL section.
f. Click OK.
4. To enable inside NAT on the interfaces connected to the inside hosts:

a. Select Config Mode > IP Source NAT, if not already selected.
b. Select Interface on the menu bar.
c. Select the interface connected to the internal hosts.
d. In the Direction drop-down list, select Inside.
e. Click Add.
f. Repeat for each interface connected to the internal hosts.
g. Do not click OK yet. Instead, go to the next step.
5. To enable outside NAT on the interfaces connected to the Internet:

a. Select the interface connected to the Internet.
b. In the Direction drop-down list, select Outside.
c. Click Add.
d. Repeat for each interface connected to the Internet.
e. Click OK.

FIGURE 78 Config Mode> Network > ACL > Standard ACL
FIGURE 79 Config Mode > IP Source NAT > IPv4 Pool
FIGURE 80 Config Mode > IP Source NAT > Binding

FIGURE 81 Config Mode > IP Source NAT > Interface
USING THE CLI

1. To configure an ACL to identify the inside addresses that need to be
translated, use either of the following commands at the global configu-
ration level of the CLI.
Use a standard ACL to specify the host IP addresses to translate. All
host addresses that are permitted by the ACL are translated before traffic
is sent to the Internet.
To also specify other information including destination addresses and
source and destination protocol ports, use an extended ACL.
Standard ACL Syntax

access-list acl-num {permit | deny}
source-ipaddr {filter-mask | /mask-length}
Extended ACL Syntax
access-list acl-num {permit | deny} {ip | icmp}
{any | host host-src-ipaddr |

net-src-ipaddr {filter-mask | /mask-length}}
{any | host host-dst-ipaddr |

net-dst-ipaddr {filter-mask | /mask-length}}
or

access-list acl-num {permit | deny} {tcp | udp}
{any | host host-src-ipaddr |

net-src-ipaddr {filter-mask | /mask-length}}
[eq src-port | gt src-port | lt src-port |
range start-src-port end-src-port]
{any | host host-dst-ipaddr |

net-dst-ipaddr {filter-mask | /mask-length}}
[eq dst-port | gt dst-port | lt dst-port |
range start-dst-port end-dst-port]
2. To configure a pool of external addresses to use for translation, use one

of the following commands at the global configuration level of the CLI.
To configure an IPv4 pool:
ip nat pool pool-name start-ipaddr end-ipaddr
netmask {subnet-mask | /mask-length}
[gateway ipaddr]
[ha-group-id group-id [ha-use-all-ports]]
Note: The ha-use-all-ports option applies only to DNS virtual ports. Using this
option with other virtual port types is not valid. (For information about
this option, see the CLI Reference.)
To configure an IPv6 pool:

ipv6 nat pool pool-name
start-ipv6-addr end-ipv6-addr
netmask mask-length
[gateway ipaddr] [ha-group-id group-id]
To configure a pool group:

ip nat pool-group pool-group-name
{pool-name ...}
3. To enable inside source NAT and map the ACL to the pool, use the fol-
lowing command:
ip nat inside source list acl-name
pool {pool-name | pool-group-name}

4. To enable inside NAT on the interfaces connected to the inside hosts,
use the following commands:
interface [ethernet port-num | ve ve-num]
ip nat inside
The interface command changes the CLI to the configuration level for
the interface connected to the internal hosts. These are the hosts identi-
fied by the ACL configured in step 1 and used by the commands in
step 2 and step 3.
5. To enable outside NAT on the interfaces connected to the Internet, use

the following commands:
ip nat outside
CLI EXAMPLE
The following commands configure an ACL to specify the internal hosts to

be NATted. In this example, all hosts in the 10.10.10.x subnet are to receive
NAT service for traffic to the Internet.
ACOS(config)#access-list 1 permit 10.10.10.0 0.0.0.255
The following command configures an IPv4 pool of external addresses to

use for the NAT translations. In this example, 10.10.10.x addresses will be
translated into 192.168.1.1 or 192.168.1.2:
ACOS(config)#ip nat pool pool1 192.168.1.1 192.168.1.2 netmask /24
The following command enables inside source NAT and associates the ACL
with the pool:
ACOS(config)#ip nat inside source list 1 pool pool1
The following commands enable inside source NAT on the interface con-
nected to the internal hosts:
ACOS(config-if:ethernet4)#ip nat inside
The following commands enable source NAT on the interface connected to

the external hosts:
ACOS(config-if:ethernet6)#ip nat outside

Configuring Static IP Source NAT

You can configure individual static source NAT mappings or configure a
range of static mappings.
After configuring the static source NAT mappings, do the following:

• Enable inside NAT on the interfaces connected to the inside hosts.
• Enable outside NAT on the interfaces connected to the Internet.
Limitations for Static NAT Mappings

• Application Layer Gateway (ALG) services other than FTP are not sup-
ported when the server is on the inside.
• HA session synchronization is not supported. However, sessions will
not be interrupted by HA failovers.
• Syn-cookies are not supported.
USING THE GUI
Note: The GUI supports configuring a static NAT range but does not support
configuring individual mappings.
1. To configure the static translations of internal host addresses to external
addresses:
a. Select NAT Range on the menu bar.
b. Click Add.
c. Enter a name for the range.
d. Select the address type (IPv4 or IPv6)
e. In the From fields, enter the first (lowest numbered) address and
network mask in the range of inside host addresses to be translated.
f. In the To field, enter the first (lowest numbered) address and net-
work mask in the range of external addresses into which to translate
the inside host addresses.
g. In the Count field, enter the number of addresses to be translated.
h. To apply HA to the addresses, select the HA group.
i. Click OK.

2. To enable inside NAT on the interfaces connected to the inside hosts:
a. Select Interface on the menu bar.
b. Select the interface from the Interface drop-down list.
c. Select Inside in the Direction drop-down list.
d. Click OK.
e. Repeat for each inside interface.
3. To enable outside NAT on the interfaces connected to the Internet:

a. Select Interface on the menu bar.
b. Select the interface from the Interface drop-down list.
c. Select Outside in the Direction drop-down list.
d. Click OK.
e. Repeat for each outside interface.
USING THE CLI

1. To configure the external addresses to use for translation, use one of the
following commands.
To configure individual address mappings, use the following command
to configure each mapping:
ip nat inside source
static source-ipaddr nat-ipaddr
[ha-group-id group-id]
The source-ipaddr is the internal host that will send requests. The nat-
ipaddr is the address into which the ACOS device will translate the
source-ipaddr before forwarding the requests.
Similarly, for inbound static NAT, the following syntax is supported:

[no] ip nat inside source static destination-
ipaddr nat-ipaddr
The destination-ipaddr is the internal host to which external hosts send
requests. The nat-ipaddr is the address into which the ACOS device will
translate the destination-ipaddr before forwarding the requests.
To configure a range list to use for static mappings:

ip nat range-list list-name
source-ipaddr /mask-length
nat-ipaddr /mask-length
count number [ha-group-id group-id]

The source-ipaddr specifies the starting address in the range of internal
host addresses. The nat-ipaddr command specifies the first address in
the range of external addresses to use for the translations.
The count option specifies how many mappings to create.
2. If you used the ip nat inside source command, enter the following com-
mand at the global configuration level of the CLI, to enable static NAT
support:
ip nat allow-static-host
Note: This step is not required if you use a static source NAT range list instead.
3. To enable inside NAT on the interfaces connected to the inside hosts,

ip nat inside
The interface command changes the CLI to the configuration level for
the interface connected to the internal hosts.
4. To enable outside NAT on the interfaces connected to the Internet, use

the following commands:
ip nat outside
CLI EXAMPLE
The following commands enable static NAT, configure an IP address range

named “nat-list-1” that maps up to 100 local addresses starting from
10.10.10.97 to Internet addresses starting from 192.168.22.50, set Ethernet
interface 2 as the inside NAT interface, and set Ethernet interface 4 as the
outside NAT interface.
ACOS(config)#ip nat range-list nat-list-1 10.10.10.97 /16 192.168.22.50 /16
count 100

NAT ALG Support for PPTP

NAT Application Layer Gateway (ALG) support for the Point-to-Point Tun-
neling Protocol (PPTP) enables clients and servers to exchange Point-to-
Point (PPP) traffic through the ACOS device over a Generic Routing
Encapsulation (GRE) tunnel.
PPTP is used to connect Microsoft Virtual Private Network (VPN) clients

and VPN hosts. Figure 82 shows an example.
FIGURE 82 NAT ALG for PPTP
The ACOS device is deployed between PPTP clients and the VPN server
(VPN Server using PPTP). The ACOS device interface connected to the
PPTP clients is enabled for inside source NAT. The ACOS device interface
connected to the VPN server is enabled for outside source NAT.
Each client runs a PPTP Network Server (PNS). To set up a VPN session,
the PNS sends an Outgoing-Call-Request to the PPTP Access Concentrator
(PAC), which is the VPN server. The destination TCP port is the PPTP port
(1723 by default). The request includes a Call ID that the PNS chooses.
Because multiple clients may share the same NAT address, the ACOS
device must ensure that clients do not share the same Call ID as well. There-
fore, the ACOS device assigns to each client a NAT Call ID (analogous to a
NAT source port for TCP) and modifies the Outgoing-Call-Request to use
the NAT Call ID instead.
The PAC replies to the Outgoing-Call-Request with a Call ID of its own.

This is like a TCP destination port. The ACOS device does not change the

PAC’s Call ID. The PAC then assigns to the client an IP address belonging
to the VPN subnet.
On the ACOS device, the GRE session is created after the PNS sends its
reply. In the GRE session, the Call ID is used as the Layer 4 port, instead of
a TCP/UDP port number. (See the example of show session output in “CLI
Example” on page 523.)
In Figure 82 on page 520, client (PNS) 10.1.1.1 wants to connect to a VPN

through the VPN Server (PAC) 10.3.3.2, which is using PPTP. Client
10.1.1.1 establishes a PPTP control session (on port 1723) with 10.3.3.2.
When the client sends the Outgoing-Call-Request over that TCP session
with its desired Call ID, the ACOS device will translate the Call ID into a
unique Call ID for NAT. Once the VPN server replies with its own Call ID,
the ACOS device will establish the GRE session.
After the Call IDs are exchanged, the client and server encapsulate VPN
subnet traffic in a GRE tunnel. The GRE tunnel packets are sent under nor-
mal IP between 10.1.1.1 and 10.3.3.2. A GRE packet for PPTP uses a Call
ID in the same way as a TCP or UDP destination port. Therefore, GRE
packets from the server (10.3.3.2) will use the NAT Call ID. The ACOS
device translates the NAT Call ID back into the client’s original Call ID
before sending the packet to the client.
Note: One GRE session is supported per control session, which means one call
at a time is supported. In practice, PPTP is used only for VPNs, in which
case multiple concurrent calls do not occur.
Configuring NAT ALG for PPTP

To configure an ACOS device to support NAT ALG for PPTP:
• Configure dynamic IP source NAT:
• Configure an ACL that matches on the PPTP client subnet(s).
• Configure an IP source NAT pool that contains the range of IP
addresses into which to translate client addresses.
• Configure an inside source NAT list, using the ACL and pool.
• Enable inside IP source NAT on the ACOS device interface con-
nected to the VPN clients.
• Enable outside IP source NAT on the ACOS device interface con-
nected to the VPN server.
• If NAT ALG support for PPTP is disabled, enable it. (The feature is
enabled by default.)

Note: In the current release, NAT ALG support for PPTP is not supported with
static NAT or NAT range lists.
Note: In the current release, NAT ALG support for PPTP can not be disabled or
re-enabled using the GUI.
USING THE CLI
To configure dynamic IP source NAT, use the following commands.
First, to configure the ACL, use the following command at the global con-
figuration level of the CLI:
access-list acl-num permit
source-ipaddr {filter-mask | /mask-length}
Note: The ACL must permit IP traffic. The syntax above is for a standard ACL.
If you plan to use an extended ACL instead, make sure to use the ip
option, instead of icmp, tcp, or udp.
To configure the IP address pool, use the following command at the global
ip nat pool pool-name start-ipaddr end-ipaddr
[gateway ipaddr] [ha-group-id group-id]
To configure an IP source NAT list, use the following command at the

ip nat inside source list acl-name
pool {pool-name | pool-group-name}
To enable inside source NAT on an interface, use the following command at

the configuration level for the interface:
[no] ip nat inside
To enable outside source NAT on an interface, use the following command

at the configuration level for the interface:
[no] ip nat outside
To enable or disable NAT ALG support for PPTP, use the following com-
ip nat alg pptp {enable | disable}
The feature is enabled by default. The default protocol port number is 1723
and can not be changed.

To display GRE sessions, use the following commands:
show session
To display or clear statistics, use the following commands:

show ip nat alg pptp statistics
clear ip nat alg pptp statistics
CLI Example
The commands in this section implement the NAT ALG for PPTP configu-
ration shown in Figure 82 on page 520.
The following commands configure dynamic inside source NAT.

ACOS(config)#access-list 1 permit 10.1.1.0 0.0.0.255
ACOS(config)#ip nat pool pptp-pool 192.168.1.100 192.168.1.110 netmask /24
ACOS(config)#ip nat inside source list 1 pool pptp-pool
The following commands specify the inside NAT interface and the outside
NAT interface.
ACOS(config-if:ethernet1)#ip address 10.2.2.254 255.255.255.0
ACOS(config-if:ethernet2)#ip address 10.3.3.254 255.255.255.0
The following command displays session information:

ACOS(config-if:ethernet2)#show session
Prot Forward Source Forward Dest Reverse Source Reverse Dest
Age Hash
---------------------------------------------------------------------------------------
--------------------
Gre 10.1.1.1:49152 10.3.3.2:32799 10.3.3.2:32799 192.168.1.100:2109

240 1
Tcp 10.1.1.1:2301 10.3.3.2:1723 10.3.3.2:1723 192.168.1.100:2109

240 2
This example shows the GRE session and the TCP session over which the
GRE session is transported. For the GRE session, the number following
each IP address is the PPTP Call ID. For the TCP session, the number is the
TCP protocol port.

Mapping Allocation Method
The following command displays PPTP NAT ALG statistics.
ACOS(config-if:ethernet2)#show ip nat alg pptp statistics
Statistics for PPTP NAT ALG:
-----------------------------
Calls In Progress: 10
Call Creation Failure: 0
Truncated PNS Message: 0
Truncated PAC Message: 0
Mismatched PNS Call ID: 1
Mismatched PAC Call ID: 0
Retransmitted PAC Message: 3
Truncated GRE Packets: 0
Unknown GRE Packets: 0
No Matching Session Drops: 4
Faster Timeout for TCP/UDP IP NAT Translations

The current release supports faster timeout for TCP and UDP IP NAT trans-
lations. You can set the timeout for TCP or UDP sessions to a value in one
of the following ranges:
• 2-31 seconds – The timeout takes place very rapidly, as close to the con-
figured timeout as possible.
• 32-12000 seconds – The timeout value must be divisible by 60, and can
be a minimum of 1 minute. If the timeout is set to a value in the range
32-59, the timeout value is rounded up to 60. Values in the range
61-11999 are rounded down to the nearest multiple of 60.
There are no GUI or CLI changes for this enhancement. The only change is
in the supported ranges.
Mapping Allocation Method

By default, the ACOS device creates NAT translations by using all the pro-
tocol ports of the first IP address in a pool, then using all the ports of the
next IP address, and so on.
Optionally, you can change the allocation method to IP round robin. The IP
round robin allocation method provides a more even distribution of address
selection, by selecting pool IP addresses in round robin fashion.
The mapping allocation method is configurable on an individual pool basis.

Fast Aging for IP NATted ICMP and DNS Sessions
USING THE GUI
On the configuration page for the pool, select the IP-RR option.
USING THE CLI
When configuring the pool, use the ip-rr option.

The ACOS device uses application-aware aging for IP NATted sessions, in
cases where the ACOS device performs IP NAT translation of the internal
client IP addresses.
The default timeout for IP NATted ICMP sessions, as well as UDP sessions
on port 53 (DNS), is set to the SLB maximum session life (MSL), which is
2 seconds by default.
Note: Fast aging applies to sessions between internal clients and external
resources, in cases where the ACOS device performs IP NAT translation
of the client addresses. This type of traffic is not SLB traffic between cli-
ents and a VIP configured on the ACOS device. For SLB DNS traffic,
short aging based on the MSL time is the default aging mechanism.
Table 24 summarizes the session timeouts and how to configure them.
TABLE 24 Session Timeout for IP NATted ICMP and UDP Sessions

Default Timeout for IP NATted ICMP DNS
Sessions Method To Change Timeout
SLB MSL timeout (2 seconds by default) You can use either of the following methods:
Note: For DNS, this is the default only for the default • Change the SLB MSL timeout.
DNS port (53). • Change the IP NAT translation timeout:
• ICMP – Change the IP NAT translation ICMP
timeout, by specifying the number of seconds for
the timeout, instead of “fast”. To be able to specify
a faster timeout value, refer to “Faster Timeout for
TCP/UDP IP NAT Translations” on page 524.
• DNS – Change the IP NAT translation UDP time-
out for the DNS port, by specifying the number of
seconds for the timeout, instead of “fast”. The
timeout is configurable for individual UDP ports.
To be able to specify a faster timeout value, refer
to “Faster Timeout for TCP/UDP IP NAT Transla-
tions” on page 524.

USING THE CLI
To display the timeout that will be used for IP NATted sessions, use the fol-
lowing command:
show ip nat timeouts
To change the IP NAT translation timeout for ICMP, use the following com-
mand:
[no] ip nat translation icmp-timeout
{seconds | fast}
To change the IP NAT translation timeout for a UDP port, use the following
command:
[no] ip nat translation service-timeout
udp port-num {seconds | fast}
The port-num option specifies the UDP port number.
The fast option sets the timeout to the SLB MSL timeout, for the specified
UDP port.
You can set the timeout for UDP sessions to a value in one of the following
ranges:
• 2-31 seconds – The timeout takes place very rapidly, as close to the con-
figured timeout as possible.
• 32-12000 seconds – The timeout value must be divisible by 60, and can
be a minimum of 1 minute. If the timeout is set to a value in the range
32-59, the timeout value is rounded up to 60. Values in the range
61-11999 are rounded down to the nearest multiple of 60.
CLI Example
The following command displays the current IP NAT translation timeouts:

ACOS#show ip nat timeouts
NAT Timeout values in seconds:
SYN TCP UDP ICMP
------------------------
60 300 300 fast
Service 53/udp has fast-aging configured

Client and Server TCP Resets for NATted TCP Sessions
In this example, the output indicates that fast aging is used for IP NATted
ICMP sessions, and for IP NATted DNS sessions on port 53.
The message at the bottom of the display indicates that the fast aging setting
(SLB MSL timeout) will be used for IP NATted UDP sessions on port 53. If
the message is not shown in the output, then the timeout shown under
“UDP” will be used instead.
Client and Server TCP Resets for NATted TCP

Sessions
By default, the ACOS device does not send TCP Resets to the client and
server when a NATted TCP session becomes idle. To enable this option, use
the following command at the global configuration level of the CLI:
ip nat reset-idle-tcp-conn
Requirements for Translation of DNS Traffic

If you plan to use IP NAT for DNS traffic, make sure the configuration
includes the following:
• Both the DNS request from the inside client, and the response from the
external DNS server, must pass through the IP NAT outside interface.
• If an ACL is configured on the interface that will receive the DNS
responses (the IP NAT outside interface), the ACL must include a per-
mit rule that allows traffic from the DNS server. Otherwise, the traffic
will be denied by the implicit (non-visible) deny any any rule at the end
of the ACL.
Pool-specific TCP Maximum Segment Life

You can customize the Maximum Segment Life (MSL) for source-NAT
connections.
The MSL is the maximum number of seconds a TCP segment (packet) is

allowed to remain in the network. When one of the endpoints in a TCP con-
nection sends a FIN to close the connection, that endpoint then enters the
TIME-WAIT state.

Pool-specific TCP Maximum Segment Life
During the TIME-WAIT state, the endpoint is not allowed to accept any
new TCP connections. This behavior is meant to ensure that the TCP end-
point does not receive a segment belonging to a previous connection after
the endpoint enters a new connection.
The TIME-WAIT state lasts up to twice the MSL. On some older TCP/IP
stacks, this can result in a wait of up to 240 seconds (4 minutes) after a FIN
before the endpoint can enter a new connection.
To help reduce the time between connections for these endpoints, you can
set the MSL on individual source NAT pools. You can set the MSL to 1-
1800 seconds.
Note: The current release supports this feature for IPv4 source NAT pools, and
for virtual ports on IPv4 or IPv6 VIPs. The current release does not sup-
port this feature for IPv6 source NAT pools. For information about con-
figuring this feature for virtual ports, see the “Network Address
Translation for SLB” chapter in the Application Delivery and Server Load
Balancing Guide.
USING THE GUI
To set the MSL for system-level source NAT:

On the ACL Bind page, enter the MSL value in the MSL field.
USING THE CLI

To set the MSL for system-level source NAT, use the msl option when con-
figuring the ACL binding. To configure the ACL binding, use the following
[no] ip nat inside source list acl-name
pool pool-or-group-name msl seconds
CLI Example
The following commands configure custom MSL values for system-level
source NAT:
ACOS(config)#access-list 123 permit tcp host 192.168.20.102 any eq 22
ACOS(config)#access-list 124 permit tcp host 192.168.20.102 any eq 80
ACOS(config)#ip nat pool ronpool 192.168.20.105 192.168.20.105 netmask /24
ACOS(config)#ip nat inside source list 123 pool ronpool msl 23
ACOS(config)#ip nat inside source list 124 pool ronpool msl 48

IP NAT Use in Transparent Mode in Multi-Netted Environment
IP NAT Use in Transparent Mode in Multi-Netted

Environment
If the ACOS device is deployed in transparent mode, the device uses NAT
IP addresses to perform health monitoring on servers that are outside the IP
subnet or VLAN of the ACOS device. If there are multiple IP addresses in
the NAT pool, the ACOS device uses only the last IP address in the pool for
the health checks. Also, the ACOS device only responds to control traffic
(for example, management and ICMP traffic) on the last IP address in the
pool.
In the following example, the ACOS device’s IP address is on the

172.168.101.0/24 subnet. A NAT pool has been configured to reach servers
outside of that subnet/VLAN.
ACOS#show ip
System is running in Transparent Mode
IP address: 172.168.101.4 255.255.255.0
IP Gateway address: 172.168.101.251
SMTP Server address: Not configured
ACOS#show ip nat pool

Total IP NAT Pools: 4
Pool Name Start Address End Address Mask Gateway HA Group
----------------------------------------------------------------------------
Pool-A 173.168.10.20 173.168.10.25 /24 173.168.10.250 0
In this configuration, the ACOS device will initiate health checks using the
last IP address in the pool as the source IP address. In this example, the
ACOS device will use IP address 173.168.10.25. In addition, the ACOS
device will only respond to control traffic directed to 173.168.10.25 from
the 173.168.10.0/24 subnet.

NAT Range List Requires ACOS Device Interface or Route Within the Global Subnet
NAT Range List Requires ACOS Device Interface

or Route Within the Global Subnet
In an IP source NAT configuration, return UDP or ICMP traffic may not be
able to reach the ACOS device. This can occur under the following circum-
stances:
• IP source NAT is configured using a NAT range list.
• The ACOS device does not have any data interfaces or routes that con-
tain an address within the subnet of the range list's global address(es).
To work around this issue, configure an IP interface that is within the NAT
range list’s global subnet. You can configure the address on any active data
interface on the ACOS device.
This issue does not affect NATted traffic other than ICMP or UDP traffic, or
use of an ACL with a NAT pool.
IP NAT in HA Configurations
If you are using IP source NAT or full NAT in an HA configuration, make
sure to add the NAT pool or range list to an HA group. Doing so allows a
newly Active ACOS device to properly continue management of NAT
resources following a failover.
USING THE GUI
In the GUI, you can select the HA group from the HA Group drop-down list
on the following configuration tabs:
• Config Mode > IP Source NAT > IPv4 Pool
• Config Mode > IP Source NAT > IPv6 Pool
• Config Mode > IP Source NAT > NAT Range
USING THE CLI
In the CLI, the ha-group-id option is supported with the following NAT
commands:
[no] ip nat pool pool-name start-ipaddr end-ipaddr

Configuring Dynamic IP NAT with Many Pools
netmask {subnet-mask | /mask-length} [gateway ipaddr]
[no] ipv6 nat pool pool-name start-ipv6-addr

end-ipv6-addr netmask mask-length [gateway ipaddr]
[no] ip nat range-list list-name

source-ipaddr /mask-length nat-ipaddr /mask-length
count number [ha-group-id group-id]

The ACOS device supports use of up to 1023 pools for dynamic IP NAT. If
you plan to use a lot of pools (100 or more), use the procedure in this sec-
tion.
To configure dynamic IP NAT with more than 100 pools:

1. Configure the NAT pools. Each pool can contain a single, contiguous
range of public IP addresses.
2. For each pool, configure a Limit ID (LID) and add the pool to the LID.
3. Configure a class list that maps internal clients to the LIDs.
4. Enable inside source NAT.
Configure NAT Pools

To configure a NAT pool, use the following command at the global configu-
ration level of the CLI:
[no] ip nat pool pool-name start-ipaddr end-ipaddr
The start-ipaddr and end-ipaddr options specify the beginning and ending
public IP addresses in the range to be mapped to internal addresses. The
netmask option specifies the subnet mask or mask length for the addresses.
Configure LIDs
A Limit ID (LID) assigns a numeric ID to a NAT pool. To configure a LID,

[no] lid num
Enter this command at the global configuration level of the CLI. The num
specifies the LID number and can be 1-1024, for a maximum of 1024 LIDs.
This command changes the CLI to the configuration level for the LID,
where the following command is available:
[no] use-nat-pool pool-name

This command binds a NAT pool to the LID.
Configure a Class List

To bind internal addresses to LIDs (and thus to NAT pools), use a class list.
You can configure a class list in either of the following ways:
• Use a text editor on a PC or other device to create the list, then import it
onto the ACOS device.
• Use CLI commands to create the list.
Class List Syntax

Each entry (row) in the class list defines a client class, and has the following
format: ipaddr /network-mask glid num
Each entry consists of the following:

• ipaddr – Specifies the inside subnet that requires NAT. The network-
mask specifies the network mask.
To configure a wildcard IP address, specify 0.0.0.0 /0. The wildcard
address matches on all addresses that do not match any entry in the class
list.
• glid num – Specifies the global LID.
Importing a Class List
After the class list is configured, import it onto the ACOS device, using the
following command at the Privileged EXEC or global configuration level of
the CLI:.
import class-list file-name url
The file-name specifies the name the class list will have on the ACOS
device. The url specifies the file transfer protocol, username (if required),
and directory path.

You can enter the entire URL on the command line or press Enter to display
a prompt for each part of the URL. If you enter the entire URL and a pass-
word is required, you will still be prompted for the password. To enter the
entire URL:
• tftp://host/file
• ftp://[user@]host[:port]/file
• scp://[user@]host/file
• rcp://[user@]host/file
Configuring a Class List Using the CLI
To configure a class list in the CLI, use the following commands:

[no] class-list name [file]
Enter this command at the global configuration level of the CLI.
The file option saves the class list as a separate file. Without this option, the
class list is instead saved in the startup-config. The file option is valid only
when you create the class list. After you create the list, the list remains
either in the startup-config or in a separate file, depending on whether you
use the file option when you create the list.
Note: If the class list contains 100 or more entries, as is likely with this feature,
it is recommended to use the file option.
A class list can be exported from the ACOS device only if you use the file
option.
The class-list command creates the class list if it is not already configured,
and changes the CLI to the configuration level for the list.
[no] ipaddr /network-mask glid num
• To add an entry to the class list, use the command without “no”.
• To modify an entry, use the command without “no”. Use the same
source IP address as the entry to replace. Entries are keyed by source IP
address.
• To delete an entry, use “no” followed by the source IP address.

Enable Inside Source NAT

To enable inside source NAT, use the following commands:
[no] ip nat inside source class-list name

Use this command at the global configuration level of the CLI.
[no] ip nat inside

Use this command on each interface connected to the inside clients.
[no] ip nat outside

Use this command on each interface connected to the external network or
Internet.
The commands in this example configure dynamic NAT with more than 100
pools.
Class List
This example uses the following class list:
10.10.10.1 /32 glid 1
10.10.10.2 /32 glid 2
10.10.10.3 /32 glid 3
10.10.10.4 /32 glid 4
10.10.10.5 /32 glid 5
10.10.10.6 /32 glid 6
...
10.10.10.254 /32 glid 254
For brevity, this example and the CLI example do not show LIDs or pools
7-253.
This example uses mask length /32 for each entry, which uses a separate
LID (and therefore, a separate pool) for each individual host. The entries are
not required to be for individual hosts. For example, the following entry
assigns all hosts in subnet 10.10.20.x to LID 10:
10.10.10.0 /24 glid 10

ACOS Configuration Commands
The following commands configure the NAT pools:
ACOS(config)#ip nat pool p1 192.168.217.201 192.168.217.201 netmask /24
...
The following commands configure the LIDs:

ACOS(config)#lid 1
ACOS(config-global lid)#use-nat-pool p1
ACOS(config-global lid)#lid 2
...
ACOS(config-global lid)#exit
The following command imports the class list:

ACOS(config)#import class-list revnat ftp:
Address or name of remote host []?1.1.1.2
User name []?axadmin
Password []?*********
File name [/]?revnat
The following command enables inside source NAT:

ACOS(config)#ip nat inside source class-list revnat

The following commands enable inside NAT on the interface connected to
the internal clients:
The following commands enable outside NAT on the interface connected to

the Internet:

Management Interface as the Source for Management Traffic
Specifying the Source Interface for Management

Traffic
By default, the ACOS device uses data interfaces as the source for manage-
ment traffic. Optionally, you can configure the device to use only the fol-
lowing types of interfaces as the source for management traffic:
• Management interface
• Loopback interface
Management Interface as the Source for Management

Traffic
By default, the ACOS device attempts to use a route from the main route
table for management connections originated on the ACOS device. You can
enable the ACOS device to use the management route table to initiate man-
agement connections instead.
This section describes the ACOS device’s two route tables, for data and
management traffic, and how to configure the device to use the management
route table.
Route Tables
The ACOS device uses separate route tables for management traffic and
data traffic.
• Management route table – Contains all static routes whose next hops are
connected to the management interface. The management route table
also contains the route to the device configured as the management
default gateway.
• Main route table – Contains all routes whose next hop is connected to a
data interface. These routes are sometimes referred to as data plane
routes. Entries in this table are used for load balancing and for Layer 3
forwarding on data ports.
This route table also contains copies of all static routes in the manage-
ment route table, excluding the management default gateway route.

You can configure the ACOS device to use the management interface as the
source interface for automated management traffic. In addition, on a case-
by-case basis, you can enable use of the management interface and manage-
ment route table for various types of management connections to remote
devices:
The ACOS device automatically will use the management route table for
reply traffic on connections initiated by a remote host that reaches the
ACOS device on the management port. For example, this occurs for SSH or
HTTP connections from remote hosts to the ACOS device.
Note: Static routes whose next hop is the management interface are duplicated
in the management route table.
Recommendation: Keep the Management and Data Interfaces in

Separate Networks
It is recommended to keep the management interface and the data interfaces
in separate networks. If both tables have routes to the same destination sub-
net, some operations such as pinging may have unexpected results. An
exception is the default route (0.0.0.0/0), which can be in both tables.
To display the routes in each table, use the following commands:

• show ip route mgmt – This command displays the routes in the man-
agement route table.
• show ip route or show ip fib – These commands display data plane
routes.
Management Routing Options

You can configure the ACOS device to use the management interface as the
source interface for the following management protocols, used for auto-
mated management traffic:
• SYSLOG
• SNMPD
• NTP
• RADIUS
• TACACS+
• SMTP
For example, when use of the management interface as the source interface
for control traffic is enabled, all log messages sent to remote log servers are

sent through the management interface. Likewise, the management route
table is used to find a route to the log server. The ACOS device does not
attempt to use any routes from the main route table to reach the server, even
if a route in the main route table could be used.
In addition, on a case-by-case basis, you can enable use of the management

interface and management route table for the following types of manage-
ment connections to remote devices:
• Upgrade of the ACOS software
• SSH or Telnet connection to a remote host
• Import or export of files
• Export of show techsupport output
• Reload of black/white lists
• SSL loads (keys, certificates, and Certificate Revocation Lists)
• Copy or restore of configurations
• Backups
Caution: If you enable this feature, then downgrade to AX Release 1.2.4 or ear-
lier, it is possible to lose access to the ACOS device after you down-
grade. This can occur if you configure an external AAA server
(TACACS+ server) to authorize CLI commands entered on the
ACOS device, and the TACACS+ server is connected to the ACOS
device through the management default gateway.
If this is the case, before you downgrade, remove the TACACS+ con-
figuration from the ACOS device. After you downgrade, you can re-
add the configuration, but make sure the TACACS+ server can be
reached using a route other than through the management default
gateway.
Management Interface as Source for Automated Management Traffic
By default, use of the management interface as the source interface for auto-
mated management traffic is disabled.
To enable it, use the following command at the configuration level for the
management interface:
[no] ip control-apps-use-mgmt-port
Here is an example:
ACOS(config-if:management)#ip control-apps-use-mgmt-port

Management Interface as Source Interface for Manually Generated

Management Traffic
To use the management interface as the source interface for manually gener-
ated management traffic, use the use-mgmt-port option.
In the GUI, this option is provided as a Use Management Port checkbox on

the applicable pages.
In the CLI, this option is supported with the following commands.
Commands at the User EXEC Level

ssh [use-mgmt-port] {host-name | ipaddr)
login-name [protocol-port]
telnet [use-mgmt-port] {host-name | ipaddr)
[protocol-port]
Commands at the Privileged EXEC Level

export {aflex | ssl-cert | ssl-key | axdebug}
file-name [use-mgmt-port] url
ssh [use-mgmt-port] {host-name | ipaddr)
login-name [protocol-port]
telnet [use-mgmt-port] {host-name | ipaddr)
[protocol-port]
Commands at the Global Configuration Level

backup {config | log} [use-mgmt-port] url
[no] bw-list name [use-mgmt-port] url
[period seconds] [load]
copy {running-config | startup-config |
from-profile-name}
[use-mgmt-port]
{url | to-profile-name [cf]}
health external
{delete program-name |
import [use-mgmt-port] [description] url |
export [use-mgmt-port] program-name url}
[no] restore [use-mgmt-port] url

[no] slb ssl-load
{certificate file-name | private-key file-name}
[use-mgmt-port] url
upgrade {cf | hd} {pri | sec} [use-mgmt-port] url
Show Commands
show techsupport [[use-mgmt-port] export url]
[page]
Using a Loopback Interface as the Source for

Management Traffic
You can configure the ACOS device to use a loopback interface IP address
to be used as the source interface for management traffic originated by the
device.
You can enable use of a specific loopback interface as the source for one or
more of the following management traffic types:
• FTP
• NTP
• RCP
• SNMP
• SSH
• SYSLOG
• Telnet
• TFTP
• Web
FTP, RCP, and TFTP apply to file export and import, such as image
upgrades and system backups.
Telnet and SSH apply to remote login from the ACOS device to another
device. They also apply to RADIUS and TACACS+ traffic. SSH also
applies to file import and export using SCP.
Web applies to GUI login.

Notes
• Loopback interface IP address – The loopback interface you specify
when configuring this feature must have an IP address configured on it.
Otherwise, this feature does not take effect.
• Management interface – If use of the management interface as the
source for management traffic is also enabled, the loopback interface
takes precedence over the management interface. The loopback inter-
face’s IP address will be used instead of the management interface’s IP
address as the source for the management traffic.
Likewise, the use-mgmt-port option has no effect.
• Ping traffic – Configuration for use of a loopback interface as the source
for management traffic does not apply to ping traffic. By default, ping
packets are sourced from the best interface based on the ACOS route
table. You can override the default interface selection by specifying a
loopback or other type of interface as part of the ping command. (See
the CLI Reference for syntax information.)
• Layer 2/3 Virtualization – This feature is supported only for loopback
interfaces that belong to the shared partition. When this feature is con-
figured, management traffic initiated from a private partition will use the
IP address of the specified loopback interface as the source address, and
will use the shared partition’s data routing table to select the outbound
interface.
Limitations
The current release has the following limitations related to this feature:
• Floating loopback interfaces are not supported.
• IPv6 interfaces are not supported.
• aVCS is not supported.
USING THE GUI
The current release does not support configuration of this feature using the
GUI.
USING THE CLI
To configure the ACOS device to use a loopback interface as the source

interface for management traffic, use the following command at the global

[no] ip mgmt-traffic
{all | ftp | ntp | rcp | snmp | ssh | syslog |
telnet | tftp | web}
source-interface loopback num
To apply the command only to a specific type of traffic (SNMP, NTP, and so
on), use the option for that traffic type. To apply the command to all man-
agement traffic types, use the all option.
CLI Example
The following commands configure an IP address on loopback interface 2:
ACOS(config)#interface loopback 2
ACOS(config-if:loopback2)#ip address 10.10.10.66 /24
ACOS(config-if:loopback2)#exit
The following command configures the ACOS device to use loopback inter-
face 2 as the source interface for management traffic of all types listed
above:
ACOS(config)#ip mgmt-traffic all loopback 2


Storage Areas
Boot Options
This chapter describes how to display or change the storage area from
which the ACOS device boots.
Note: This chapter does not describe how to upgrade the system image. For
upgrade instructions, see the release notes for the release to which you
plan to upgrade.
Storage Areas
The ACOS device has four storage areas (also called “image areas”) that
can contain software images and configuration files:
• Primary storage on the Solid State Drive (SSD) or disk
• Secondary storage on the SSD or disk
• Primary storage on the compact flash (CF)
• Secondary storage on the compact flash
These storage areas are depicted in Figure 83.
FIGURE 83 Software Image Locations on the ACOS Device
The SSD or disk storage areas are used for normal operation. The compact
flash storage areas are used only for system recovery.
Note: In this document, references to SSD can refer to the hard disk in some
older ACOS devices.

Storage Areas
Normally, each time the ACOS device is rebooted, the device uses the same
storage area that was used for the previous reboot. For example, if the pri-
mary storage area of the SSD or disk was used for the previous reboot, the
system image and startup-config from the primary storage area are used for
the next reboot.
Unless you change the storage area selection or interrupt the boot sequence
to specify a different storage area, the ACOS device always uses the same
storage area each time the device is rebooted.
Note: The ACOS device always tries to boot using the SSD or disk first. The
compact flash is used only if the SSD or hard disk is unavailable. If you
need to boot from compact flash for system recovery, contact A10 Net-
works.
Displaying Storage Information

To display the software images installed in the ACOS storage areas, and the
currently running software version, use either of the following methods.
USING THE GUI
The first page that is displayed when you log onto the GUI is the Summary
page (see Figure 85). The following graphic lists the software image ver-
sions installed in each of the storage areas (that is part of the Summary
page).
FIGURE 84 Software Images—Detailed View

Storage Areas
FIGURE 85 Monitor Mode > Overview > Summary
System
Images
Above the highlighted fields, the Startup Mode field lists the storage area
used for the most recent reboot. The Software Version field lists the cur-
rently running software version.

Storage Areas
USING THE CLI
The show version command shows storage area information. The command
also lists other information, including the currently running software ver-
sion.
ACOS#show version
AX Series Advanced Traffic Manager AX2500
Copyright 2007-2013 by A10 Networks, Inc. All A10 Networks products are
protected by one or more of the following US patents and patents pending:
7716378, 7675854, 7647635, 7552126, 20090049537, 20080229418, 20080040789,
20070283429, 20070271598, 20070180101
64-bit Advanced Core OS (ACOS) version 2.7.1-P2, build 29 (Jul-12-

2013,07: 28)
Booted from Hard Disk primary image
Serial Number: AX25061111010069

aFleX version: 2.0.0
aXAPI version: 2.1
Hard Disk primary image (default) version 2.7.1-P2, build 29
Hard Disk secondary image version 2.6.6-GR1, build 50
Compact Flash primary image (default) version 2.4.3-P8-SP3, build 2
Compact Flash secondary image version 2.4.3-P8-SP3, build 2
Last configuration saved at Jul-12-2013, 10:06
Hardware: 8 CPUs(Stepping 5), Single 74G Hard disk
Memory 6122 Mbyte, Free Memory 1529 Mbyte
Hardware Manufacturing Code: 110100
Current time is Jul-12-2013, 11:07
The system has been up 0 day, 0 hour, 58 minutes
ACOS#

Storage Areas
Displaying the Storage Location for Future Reboots

To display the storage area that will be used for the future reboots, use either
of the following methods.
Note: The ACOS device always tries to boot using the SSD or disk first. The
compact flash is used only if the SSD or hard disk is unavailable. If you
need to boot from compact flash for system recovery, contact A10 Net-
works.
USING THE GUI
Select Config Mode > System > Settings > Boot.
USING THE CLI

Use the following command: show bootimage
In the following example, the ACOS device is configured to boot from the
primary storage area on the SSD or disk:
ACOS#show bootimage
(* = Default)
Version
-----------------------------------------------
Hard Disk primary 2.7.1-P2.29 (*)
Hard Disk secondary 2.6.6-GR1.50
Compact Flash primary 2.4.3-P8-SP3.2 (*)
Compact Flash secondary 2.4.3-P8-SP3.2

Booting from a Different Storage Area

The ACOS device allows you to change the boot device from the primary
image to the secondary image on a single storage device, either the SSD,
hard disk, or the CF. You can use the CLI or the GUI to make the change
from the primary image to the secondary image or vice versa. However, if
you are choosing to change the boot device from the SSD (hard disk) to the
CF (Compact Flash) you have to interrupt the boot sequence to do so. Both
boot devices, SSD (hard disk) and CF, contain their own primary and sec-
ondary boot locations.
To reboot from a different image within the same storage device (SSD or
CF), do one of the following:
• Interrupt the boot sequence and use the bootloader menu to temporarily
select the other storage area.
• Configure the ACOS device to use the other storage area for all future
reboots, then reboot.
Temporarily Changing the Boot Image for the Next Reboot

To temporarily change the storage location within the same boot device
(SSD or CF) from the primary to the secondary image, interrupt the boot
sequence to access the bootloader menu.
To access the bootloader menu, reboot the ACOS device, then press Esc
within 3 seconds when prompted.
When the bootloader menu appears, use the Up and Down arrow keys to
select the image area from which to boot, and press Enter. The menu does
not automatically time out. You must press Enter to reboot using the
selected image.
Caution: Each storage area has its own version of the startup-config. When
you save configuration changes, they are saved only to the startup-
config in the storage area from which the ACOS device was booted.
If you plan to reboot from a different storage area, but you want to
use the same configuration, first save the configuration to the other
storage area. (The procedures in “Permanently Changing the Storage
Location for Future Reboots” on page 552 include steps for this.)
Note: The bootloader menu is available on new ACOS devices that are shipped
with AX Release 2.6.1 or later. However, the bootloader menu is not auto-
matically installed when you upgrade from a release earlier than 2.6.1. To
install the bootloader menu on upgraded devices, see the AX Release

2.6.1 release notes, or the description of the boot-block-fix command in
the CLI Reference for 2.6.1 or later.
ACOS#reboot
Rebooting System Now !!!
Proceed with reboot? [yes/no]:yes
INIT:
Shutting down........Restarting system.

Press `ESC' to enter the boot menu... 1
Admin presses Esc within 3 seconds.
# # ### # #
# # ## # # ## # ###### ##### # # #### ##### # # ####
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # ##### # # # # # # # #### ####
####### # # # # # # # # # ## # # # ##### # # #
# # # # # # ## # # ## ## # # # # # # # #
# # ##### ### # # ###### # # # #### # # # # ####
Copyright 2005-2011 by A10 Networks, Inc. All A10 Networks products are
protected by one or more of the following US patents and patents pending:
7716378, 7675854, 7647635, 7552126, 20090049537, 20080229418, 20080040789,
20070283429, 20070271598, 20070180101
-------------------------------------------------------------------
0: ACOS (Primary Image)
1: ACOS (Secondary Image)
-------------------------------------------------------------------
Use the Up and Down arrow keys to select the image from which to boot.
Press enter to boot the selected image.
Admin presses down arrow to select 1.
Highlighted entry is 1:
Admin presses Enter to reboot using the selected image.
Booting 'ACOS (Secondary Image)'

Please wait while the system boots...
Booting........................[OK]
ACOS login:

Permanently Changing the Storage Location for Future Reboots

To change the storage area that will be used for future reboots, use either of
the following methods.
Note: The procedures in this section change the storage area selection for all
future reboots (unless you later change the selection again). If you only
need to temporarily override the storage area selection for a single reboot,
see “Temporarily Changing the Boot Image for the Next Reboot” on
page 550.
Caution: Each storage area has its own version of the startup-config. When
you save configuration changes, they are saved only to the startup-
config in the storage area from which the ACOS device was booted.
If you plan to reboot from a different storage area, but you want to
use the same configuration, first save the configuration to the other
storage area. The procedures in this section include a step for this.
USING THE GUI

1. Save the configuration, by clicking the Save icon at the top of the GUI
window.
This step copies any unsaved configuration changes from the running-
config to the startup-config.
FIGURE 86 Save the Configuration
2. Copy the startup-config to the storage area you plan to use for the next
reboot:
a. Select Config Mode > System > Config.
b. Click one of the following:
• Primary Startup – This option selects the startup-config in the
primary storage area of the SSD or hard drive. Click this link if
you plan to use the primary storage area for the next reboot.
• Secondary Startup – This option selects the startup-config in the
secondary storage area of the SSD or hard drive. Click this link
if you plan to use the secondary storage area for the next reboot.

The selected startup-config is displayed, in the Content field.
c. Use the Copy From drop-down list to select the startup-config file
that was used for the most recent reboot. This is the startup-config
to which you saved configuration changes in step 1. The commands
in the selected startup-config replace the commands that were dis-
played in the Content field.
d. Click OK. The startup-config you selected in step b is replaced with
the one selected in step c.
3. Change the storage area to use for booting:

a. Select Config Mode > System > Settings > Boot.
b. Select Primary or Secondary.
c. Click OK.
Note: You can select the storage area for the SSD or hard disk and for the com-
pact flash. However, the ACOS device always tries to boot using the SSD
or hard disk first. The compact flash is used only if the SSD or hard disk
is unavailable.
USING THE CLI

1. Save the configuration, by entering the following command:
write memory
This step copies any unsaved configuration changes from the running-
config to the startup-config.
2. Copy the startup-config to the storage area you plan to use for the next
reboot. Use the following command:
write memory {primary | secondary}
• primary – Select this option if the secondary storage area is the one
the ACOS device was booted from, and you plan to boot from the
primary storage area next time.
• secondary – Select this option if the primary storage area is the one
the ACOS device was booted from, and you plan to boot from the
secondary storage area next time.

3. Select the storage area to use for future reboots. Use the following com-
mand.
bootimage {hd | cf} {pri | sec}
Note: This command is available at the global configuration level of the CLI.
• The hd | cf option specifies whether you are selecting a storage area
on the SSD or hard drive, or the compact flash.
• The pri | sec option specifies whether the ACOS device first tries to
boot using the image in the primary image area or the secondary
image area.
To verify the setting, use the following command: show bootimage
CLI Example
In this example, the ACOS device was booted from the primary storage
area, and will be configured to use the secondary image area for future
reboots.
The following command displays the current setting for the storage area to
use for reboots:
ACOS#show bootimage
(* = Default)
Version
-----------------------------------------------
Hard Disk primary 2.7.1-P2.29 (*)
Hard Disk secondary 2.6.6-GR1.50
The following commands save the configuration and copy it to the other
storage area:
ACOS(config)#write memory
[OK]
ACOS(config)#write memory secondary
[OK]

The following commands configure the ACOS device to use the secondary
storage area on the SSD or hard drive for future reboots, and verify the set-
ting:
ACOS(config)#bootimage hd sec
Secondary image will be used if ACOS is booted from hard disk
ACOS(config)#show bootimage
(* = Default)
Version
-----------------------------------------------
Hard Disk primary 2.7.1-P2.29
Hard Disk secondary 2.6.6-GR1.50 (*)


Backing Up System Information
Configuration Management
By default, when you click the Save button in the GUI or enter the write
memory command in the CLI, all unsaved configuration changes are saved
to the startup-config. The next time the ACOS device is rebooted, the con-
figuration is reloaded from this file.
In addition to these simple configuration management options, the ACOS

device has advanced configuration management options that allow you to
save multiple configuration files. You can save configuration files remotely
on a server and locally on the ACOS device itself.
Note: For information about managing configurations for separate partitions on

an ACOS device configured for Role-Based Administration (RBA), see
“Role Based Administration Private Partition” on page 219.
Note: For information about managing configurations for separate partitions on

an ACOS device configured for Layer 2/3 virtualization (L3V) partition,
see “Layer 3 Virtualization of Private Partitions” on page 227.
Note: For information about synchronizing configuration information between

ACOS devices in a High Availability (HA) pair, see the section that
applies to the HA implementation you use:
• VRRP-A (supported in AX Release 2.6 and later) –“Manually Syn-
chronizing the Configuration” on page 379.
• Older implementation of HA –“Manually Synchronizing Configura-
tion Information” on page 335.
Note: For upgrade instructions, see the release notes for the ACOS release to
which you plan to upgrade.

The ACOS device allows you to back up the system, individual configura-
tion files, and even log entries onto remote servers. You can use any of the
following file transfer protocols:
• Trivial File Transfer Protocol (TFTP)
• File Transfer Protocol (FTP)
• Secure Copy Protocol (SCP)

• Unix Remote Copy (RCP)
USING THE GUI

1. Select Config Mode > System > Maintenance.
2. Select one of the following from the menu bar:

• Backup > System – This option backs up the configuration file(s),
aFleX scripts, and SSL certificates and keys.
• Backup > log – This option backs up the log entries in the ACOS
device’s syslog buffer. (If there are any core files on the system, this
option backs them up as well.)
3. Select the backup location:

• Local – Saves the backup on the PC or workstation where you are
using the ACOS GUI.
• Remote – Saves the backup onto another PC or workstation.
4. If you selected Local:

a. Click OK.
b. Click Save and navigate to the save location. Optionally, you can
edit the filename.
c. Click Save.
5. If you selected Remote:

a. Select the checkbox for the Use Management Port to use the man-
agement interface as the source interface for the connection to the
remote device.
b. In the Protocol drop-down list, select the file transfer protocol: FTP,
TFTP, RCP, SCP, or SFTP.
• If using FTP and the remote device does not use the default FTP
port, change the port. Specify the host, port, location, user, and
password.
• If using TFTP, specify the host, and location
• If using RCP, specify the host. location, and user.
• If using SCP, specify the host, location, user, and password.
• If using SFTP, specify the host, location, user, and password.
• In the Host field, enter the hostname or IP address of the remote
device.
c. In the Location field, enter the pathname. To change the system
backup file from the default name (“backup_system.tar”), specify
the new name at the end of the path.

Saving Multiple Configuration Files Locally
d. In the User and Password fields, enter the username and password
required for write access to the remote device.
e. Click OK.
USING THE CLI
At the Privileged EXCE level of the CLI, use the following command:
backup {system | log} url
The system option backs up the startup-config file, aFleX scripts, and SSL
certificates and keys.
The log option backs up the log entries in the ACOS device’s syslog buffer.
The use-mgmt-port option allows you to indicate the use of the management
interface as the source interface for the connection to the remote device.
The url option specifies the file transfer protocol, username, and directory
path. You can enter the entire URL on the command line or press Enter to
display a prompt for each part of the URL. If you enter the entire URL and a
password is required, you will still be prompted for the password. To enter
the entire URL:
• tftp://host/file
• ftp://[user@]host[:port]/file
• scp://[user@]host/file
• rcp://[user@]host/file
• sftp://[user@]host/file

The ACOS device has CLI commands that enable you to store and manage
multiple configurations on the ACOS device.
Note: Unless you plan to locally store multiple configurations, you do not need
to use any of the advanced commands or options described in this section.
Just click Save in the GUI or enter the write memory command in the
CLI to save configuration changes. These simple options replace the com-
mands in the startup-config stored in the image area the ACOS device
booted from with the commands in the running-config.

Configuration Profiles
Configuration files are managed as configuration profiles. A configuration
profile is simply a configuration file. You can locally save multiple configu-
ration profiles on the ACOS device. The configuration management com-
mands described in this section enable you to do the following:
• Save the startup-config or running-config to a configuration profile.
• Copy locally saved configuration profiles.
• Delete locally saved configuration profiles.
• Compare two configuration profiles side by side to see the differences

between the configurations.
• Link the command option “startup-config” to a configuration profile
other than the one stored in the image area used for the most recent
reboot. (This is the profile that “startup-config” refers to by default.)
This option makes it easier to test a configuration without altering the
configuration stored in the image area.
Note: Although the enable and admin passwords are loaded as part of the sys-
tem configuration, they are not saved in the configuration profiles.
Changes to the enable password or to the admin username or password
take effect globally, regardless of the values that were in effect when a
given configuration profile was saved.
USING THE GUI

You can use the Config Mode > System > Config File page to perform the
following configuration management tasks:
• Display individual configuration files.
• Add, modify, and delete configuration files.
• Display side-by-side comparisons of configuration files.
Displaying a Configuration File

1. Select Config Mode > System > Config File.
2. Click on the configuration file name.
Adding a Configuration File

2. Click Add. The Config File page appears.

3. Enter the name in the Name field.
4. To use another configuration file as a template, select the file from the
Copy drop-down list.
5. Edit the file if required.
6. Click OK.
Modifying a Configuration File

2. Click on the configuration file name.
3. Edit the file.
4. Click OK.
Deleting a Configuration File

2. Select the checkbox next to each configuration file to delete.
3. Click Delete.
Comparing Configuration Files

2. Select the checkbox next to each of the 2 configuration files to compare.
3. Click Diff.
Note: You can compare a maximum of 2 files at a time.
The device configurations appear side-by-side in a new window. Differ-

ences between the two configurations are highlighted:
• Yellow – Indicates a configuration section that is present in each
device’s configuration, but does not contain exactly the same configura-
tion on both devices.
• Red – Indicates a configuration command that is present in the device
configuration shown on the left, but is not present in the device configu-
ration shown on the right.
• Green – Indicates a configuration command that is present in the device
configuration shown on the right, but is not present in the device config-
uration shown on the left.

USING THE CLI
To manage multiple locally stored configurations, use the following com-

mands. All commands are available at the global configuration level of the
CLI.
write {memory | force}

[primary | secondary | profile-name]
[cf]
[all-partitions |
partition{shared | private-partition-name] ]
[all-partitions |
partition{shared | private-partition-name}]
This command replaces the configuration commands in the specified con-

figuration profile with the commands in the running-config.
If you enter write memory without additional options, the command

replaces the configuration profile that is currently linked to by startup-con-
fig with the commands in the running-config. If startup-config is set to its
default (linked to the configuration profile stored in the image area that was
used for the last reboot), then write memory replaces the configuration pro-
file in the image area with the running-config.
If you enter write force, the command forces the ACOS device to save the
configuration regardless of whether the system is ready.
The all-partitions and partition partition-name options are applica-

ble on ACOS devices that are configured for Role-Based Administration
(RBA). If you omit both options, only the resources in the shared partition
are saved. (If RBA is not configured, all resources are in the shared parti-
tion, so you can omit both options.)
The all-partitions option is applicable only to admins with Root, Read-

write, or Read-only privileges.
If you enter write memory primary, the command replaces the configura-
tion profile stored in the primary image area with the running-config. Like-
wise, if you enter write memory secondary, the command replaces the
configuration profile stored in the secondary image area with the running-
config.
If you enter write memory profile-name, where profile-name is the name of

a configuration profile, the ACOS device replaces the commands in the
specified profile with the running-config.

The cf option replaces the configuration profile in the specified image area
(primary or secondary) on the compact flash rather than the hard disk. If you
omit this option, the configuration profile in the specified area on the hard
disk is replaced.
show startup-config
[
all [cf]|
all-partitions |
partition {shared | partition-name} |
profile profile-name] [cf] |
all-partitions |
partition {shared | partition-name}]
]
To display a list of the locally stored configuration profiles, use the all
option. The cf option displays all the configuration profiles stored on the
compact flash.
The all-partitions command shows all resources in all partitions. In this

case, the resources in the shared partition are listed first. Then the resources
in each private partition are listed, organized by partition.
The partition shared partition-name command shows only the

resources in the specified partition.
The profile profile-name command displays the commands that are in

the specified configuration profile.
The cf option displays the configuration profile on the compact flash rather
than the hard disk. If you omit this option, the configuration profile on the
hard disk is displayed.
The all-partitions option shows all resources in all partitions.
The partitions option shows only the resources in the specified partition.
copy {running-config | startup-config |

from-profile-name}
[use-mgmt-port]
{url | to-profile-name [cf]}
The copy startup-config from-profile-name command copies the configu-

ration profile that is currently linked to “startup-config” and saves the copy
under the specified profile name.

The copy startup-config to-profile-name command copies the configura-
tion profile that is currently linked to “startup-config” and saves the copy
under the specified profile name.
The copy running-config to-profile-name command copies the running-

config and saves the copy under the specified profile name.
The use-mgmt-port command uses the management interface as the source

interface for the connection to the remote device. The management route
table is used to reach the device. By default, the ACOS device attempts to
use the data route table to reach the remote device through a data interface.
The cf option copies the profile to the compact flash instead of the hard
disk.
Note: You cannot use the profile name “default”. This name is reserved and
always refers to the configuration profile that is stored in the image area
from which the ACOS device most recently rebooted.
(The url option backs up the configuration to a remote device. See “Backing
Up System Information” on page 557.)
diff {startup-config | profile-name}

{running-config | profile-name}
Displays a side-by-side comparison of the commands in a pair of configura-

tions.
The diff startup-config running-config command compares the configura-

tion profile that is currently linked to “startup-config” with the running-con-
fig. Similarly, the diff startup-config profile-name command compares the
configuration profile that is currently linked to “startup-config” with the
specified configuration profile.
To compare a configuration profile other than the startup-config to the run-

ning-config, enter the configuration profile name instead of startup-config.
To compare any two configuration profiles, enter their profile names instead
of startup-config or running-config.
In the CLI output, the commands in the first profile name you specify are
listed on the left side of the terminal screen. The commands in the other pro-
file that differ from the commands in the first profile are listed on the right
side of the screen, across from the commands they differ from. The
following flags indicate how the two profiles differ:

• |– This command has different settings in the two profiles.
• >_ This command is in the second profile but not in the first one.
• <_ This command is in the first profile but not in the second one.
link startup-config {default | profile-name}

[primary | secondary] [cf]
This command links the “startup-config” token to the specified configura-

tion profile. By default, “startup-config” is linked to “default”, which means
the configuration profile stored in the image area from which the ACOS
device most recently rebooted.
This command enables you to easily test new configurations without replac-
ing the configuration stored in the image area.
The primary | secondary option specifies the image area. If you omit this
option, the image area last used to boot is selected.
The cf option links the profile to the specified image area in compact flash
instead of the hard disk.
The profile you link to must be stored on the boot device you select. For
example, if you use the default boot device selection (hard disk), the profile
you link to must be stored on the hard disk. If you specify cf, the profile
must be stored on the compact flash. (To display the profiles stored on the
boot devices, use the show startup-config all and show startup-config all
cf commands.)
After you link “startup-config” to a different configuration profile, configu-

ration management commands that affect “startup-config” affect the linked
profile instead of affecting the configuration stored in the image area. For
example, if you enter the write memory command without specifying a
profile name, the command saves the running-config to the linked profile
instead of saving it to the configuration stored in the image area.
Likewise, the next time the ACOS device is rebooted, the linked configura-
tion profile is loaded instead of the configuration that is in the image area.
To relink “startup-config” to the configuration profile stored in the image

area, use the default option (link startup-config default).
delete startup-config profile-name [cf]
This command deletes the specified configuration profile. The cf option

deletes the profile from compact flash instead of the hard disk.

Note: Although the command uses the startup-config option, the command
only deletes the configuration profile linked to “startup-config” if you
enter that profile’s name. The command deletes only the profile you spec-
ify.
Note: If the configuration profile you specify is linked to “startup-config”,

“startup-config” is automatically relinked to the default. (The default is
the configuration profile stored in the image area from which the ACOS
device most recently rebooted).
CLI EXAMPLES
The following command saves the running-config to a configuration profile

named “slbconfig2”:
ACOS(config)#write memory slbconfig2
The following command shows a list of the configuration profiles locally

saved on the ACOS device. The first line of output lists the configuration
profile that is currently linked to “startup-config”. If the profile name is
“default”, then “startup-config” is linked to the configuration profile stored
in the image area from which the ACOS device most recently rebooted.
ACOS(config)#show startup-config all
Current Startup-config Profile: slb-v6
Profile-Name Size Time
------------------------------------------------------------
1210test 1957 Jan 28 18:39
ipnat 1221 Jan 25 10:43
ipnat-l3 1305 Jan 24 18:22
ipnat-phy 1072 Jan 25 19:39
ipv6 2722 Jan 22 15:05
local-bwlist-123 3277 Jan 23 14:41
mgmt 1318 Jan 28 10:51
slb 1354 Jan 23 18:12
slb-v4 12944 Jan 23 19:32
slb-v6 13414 Jan 23 19:19
The following command copies the configuration profile currently linked to

“startup-config” to a profile named “slbconfig3”:
ACOS(config)#copy startup-config slbconfig3
The following command compares the configuration profile currently

linked to “startup-config” with configuration profile “testcfg1”. This exam-

ple is abbreviated for clarity. The differences between the profiles are
shown in this example in bold type.
ACOS(config)#diff startup-config testcfg1
!Current configuration: 13378 bytes (
!Configuration last updated at 19:18:57 PST Wed Jan 23 2008 (
!Configuration last saved at 19:19:37 PST Wed Jan 23 2008 (
!version 1.2.1 (
! (
hostname ACOS (
! (
clock timezone America/Tijuana (
! (
ntp server 10.1.11.100 1440 (
! (
...
! (
interface ve 30 (
ip address 30.30.31.1 255.255.255.0 | ip address
10.10.20.1 255.255.255.0
ipv6 address 2001:144:121:3::5/64 | ipv6 address
fc00:300::5/64
! (
! (
> ip nat range-
list v6-1 fc00:300::300/64 2001:144:121:1::900/6
! (
ipv6 nat pool p1 2001:144:121:3::996 2001:144:121:3::999 netm <
! <
slb server ss100 2001:144:121:1::100 <
port 22 tcp <
--MORE--
The following command links configuration profile “slbconfig3” with

“startup-config”:
ACOS(config)#link startup-config slbconfig3
The following command deletes configuration profile “slbconfig2”:

ACOS(config)#delete startup-config slbconfig2


Power On Auto Provisioning
The ACOS Power On Auto Provisioning (POAP) feature automates the pro-
cess of upgrading software images across many ACOS devices that are
being deployed in the network. POAP can be used to upgrade software on
existing devices or to roll out a configuration file to many ACOS devices.
POAP offers an efficient way to upgrade the software image or config file
across many devices at the same time.
Use of this feature requires a DHCP server and a TFTP server that has been
pre-configured with the proper ACOS software image and config file. The
ACOS device must have access to the management port on a DHCP server
and access to the TFTP server.
Figure 87 shows how the POAP process works.
FIGURE 87 Power On Auto Provisioning process
1. The ACOS device boots and sends a broadcast request to the DHCP
server.
2. The DHCP server sends a response that includes an IP address for the
ACOS device, and an IP address where the TFTP server can be reached.
3. The ACOS device attempts to locate the TFTP server at the IP address it
just received from the DHCP server by sending a request to that address.
4. The TFTP server responds to the request from the ACOS device by
sending the “ACOS_upg.tgz” file.
Once the ACOS device receives the “ACOS_upg.tgz” file, it performs
the following operations:

• Extracts the upgrade image and configuration file.

• Upgrades its software using the new image.
• Links to the configuration file.
• Then the ACOS device reboots.
Configuration
Prerequisites before using POAP
• Create an upgrade package named “ACOS_upg.tgz”.
The package may contain one or both of the following optional files:
• Image file: “sto.tar.gz”
• Config file: “poap_startup”
• Save this upgrade package on a TFTP server that can be accessed by the
ACOS device. This package should be stored in the working directory
of the TFTP server, (for example, “tftpboot”).
• To enter POAP mode, the current startup-config file on the ACOS
device must be empty; if the startup-config file is not completely empty
then the POAP install will fail.
• At the end of the installation process, POAP links to the new
startup-config file, which is a text file named “poap_startup”.
Note: The POAP installation process does not erase an existing startup-config
file, but as a precaution, you can save an existing startup-config file by
creating a backup prior to enabling POAP.
Note: If the ACOS device encounters an existing file named “poap_startup” on

the ACOS device (perhaps a remnant left over from a prior attempt to
enable the feature), the POAP installation process will rename this exist-
ing file “poap_startup.original”.

USING THE CLI
POAP mode is enabled by default on SoftAX virtual appliances, but the fea-
ture is disabled by default on all physical devices. To enable POAP mode on
a physical device, use the following CLI command at the global config
level:
[no] poap
Using the “no” form of the command will disable the feature.
You can use the following CLI command to show the status (enabled or dis-
abled) of POAP mode:
show poap


System Center Operations Manager Support
This release introduces a management pack that allows the ACOS device to
be integrated with Microsoft’s System Center Operations Manager
(SCOM). SCOM is a data center management tool that provides administra-
tors with centralized management and the ability to monitor large numbers
of network devices. The tool displays device status, health, and performance
information for the devices on the network, and it can be configured to send
alerts for certain types of events.
By introducing a management pack, administrators can now use a familiar

tool (SCOM) to monitor and manage the ACOS devices on their network.
SCOM integration supports the following sub-features:

• Near real-time performance monitoring of ACOS device traffic on
global level, as well as at the more-granular VIP, service group, and
node level.
• Traffic monitoring of total connections, connections per second, total
bytes, and packet numbers.
• Ability to display device health metrics for CPU, memory, and status
(UP/DOWN) for VIPs, service groups, and nodes.
• Ability to enable or disable nodes.
Benefits of SCOM
Benefits of offering SCOM support on the ACOS device include the follow-
ing:
• Near real-time performance monitoring
• Customized network map views
• Flexible reporting engine
• Customizable thresholds and alerts
• Historical data collection
Figure 88 shows an example of the SCOM topology. This implementation is

based on the client/server model, with the SCOM client residing on the
ACOS device and the SCOM server running on top of Windows 2008 R2
SP1 or Windows 2012 Operating System (OS).

The PowerShell “cmdlet” pulls updates from the ACOS device and displays
critical metrics within the SCOM Dashboard.
FIGURE 88 SCOM topology
Configuration
The ACOS device SCOM management pack is installed as a snap-in. When
performing this installation, please observe the following system require-
ments.
Minimum hardware requirements

• CPU: Intel® or AMD® series processor with 64-bit computing
• RAM: 4GB
• Hard Drive: 20G or more free space
Minimum Software requirements

• Windows server 2008 R2 / Windows Server 2008 R2 SP1
• Microsoft Net Framework 4.0 or later version
• Windows SQL Server 2008
• Microsoft System Center Operations Manager (SCOM) 2012
To install and configure Microsoft’s System Center Operations Manager

(SCOM) data center management tool, see the AX SCOM Management
Pack Deployment Guide from A10 Networks.

Enabling and disabling nodes

A10 Management Pack supports the ability to remotely enable and disable
functions of the real servers, real ports, virtual servers, virtual ports, and ser-
vice-group member within managed A10 device. However, before you can
perform these operations, you must first set the account and password of the
device that has been discovered to gain permissions required to operate the
device.
1. Set the account and password for device, as follows:
a. In the Operations Console, click Administration pane.
b. Expand Run As Configuration, and select Profiles.
c. Right-click A10.Account, and select Properties.
d. In the Run as Profile Wizard dialog box, go to the Introduction pane,
and click Next.
e. In the General Properties pane, click Next.
f. In the Run As Accounts pane, click Add.
g. In the “Add a Run as account” dialog box, select an existing “run
as” account, or click New to build a new account.
h. Select a class, group, or object. Then, click Select, and select an
Object.
i. In the Object Search dialog box, select A10 Device Class, and click
Search.
j. Select the device for which you would like to add an account in the
Available Items box, click Add, and then click OK.
k. Click OK in the “Add a Run As account” dialog box.
2. Click Save in Run As Profile Wizard dialog box.
3. Click the name of the instance that you want to disable or enable.
4. In the Task Pane, click the disable or enable function, and the run task
windows opens.
5. In the Open window, click OK.
For additional details on the requirements for System Center Operations

Manager, please visit Microsoft TechNet's website at the following URL:
http://technet.microsoft.com/en-us/library/jj656654.aspx


Multiple Port-monitoring Mirror Ports
The ACOS software provides support for multiple mirror ports for each
traffic direction (inbound, outbound) in addition to support for a single mir-
ror port for each traffic direction.
You can configure up to 4 mirror ports. A mirror port can be a physical

Ethernet data interface.
When configuring a mirror port, you can specify the traffic directions to be
mirrored to the port: input or output. If you do not specify a traffic direction,
both directions are mirrored to port.
When you enable monitoring on a port, you can specify the mirror port to
use. You also can specify the traffic direction. A monitored port can use
multiple mirror ports.
Note: This feature is supported on only some AX models: AX 5200-11,

AX 5200, AX 5100, AX 3400, and AX 3200-12.
USING THE GUI
The current release does not support this feature.
USING THE CLI
To configure mirror ports, use the following command at the global config-
uration level:
[no] mirror-port mirror-id ethernet portnum

[input | output]
The mirror-id can be 1-4.
The portnum can be a valid Ethernet port number. (The range depends on
how many Ethernet data ports your ACOS device model has.)
The input | output option specifies the traffic direction to mirror:

• input – Ingress traffic on the monitored port(s) is mirrored to the mirror
port.
• output – Egress traffic on the monitored port(s) is mirrored to the mirror
port.

By default, both traffic directions are mirrored.
To display the port mirroring configuration, use the following command:

show mirror
USING THE CLI
The following commands configure 4 mirror ports:

ACOS(config)#mirror-port 1 ethernet 4
ACOS(config)#mirror-port 2 ethernet 7 output
ACOS(config)#mirror-port 3 ethernet 9
ACOS(config)#mirror-port 4 ethernet 3 input
The following command verifies the mirror configuration:

ACOS(config)#show mirror
Mirror Ports 1: Input = 4 Output = 4
Mirror Ports 2: Input = None Output = 7
Mirror Ports 4: Input = 3 Output = None
At this point, monitoring is not yet enabled on any ports. The following
commands access the configuration level for Ethernet interface 1 and enable
monitoring of its traffic.
ACOS(config-if:ethernet1)#monitor ?
both Both incoming and outgoing packets
input Incoming packets
output Outgoing packets
ACOS(config-if:ethernet1)#monitor input ?
<1-4> Mirror index
ACOS(config-if:ethernet1)#monitor input 1
The following command again displays the mirror configuration:

ACOS(config-if:ethernet1)#show mirror
Ports monitored at ingress : 1
The output now lists the monitoring configuration on port 1, which uses
mirror 1.

The following commands attempt to enable monitoring of ingress traffic on

port 2, using mirror 2. However, this configuration is not valid, because mir-
ror 2 can accept egress traffic only.
Please configure mirror port first.
Likewise, the both option is not valid in this case:

ACOS(config-if:ethernet2)#monitor both 2
Please configure mirror port first.
The following configuration is valid, since mirror 2 is configured to accept

only the egress traffic of monitored ports:
ACOS(config-if:ethernet2)#monitor output 2
Here is the mirror configuration now:

Ports monitored at egress : 2
The ingress traffic received on port 2 can be monitored, if a mirror that

accepts ingress traffic is used. In this example, mirrors 1, 3, and 4 can
accept ingress traffic. The following command configures use of mirror 4
for ingress traffic received on port 2:
Here is the mirror configuration after this change:

Ports monitored at egress : 2

For brevity, this example does not show configuration of monitoring using
mirror 3. Likewise, the example does not show that a mirror can accept
monitored traffic from more than one interface, but this is supported.
Port Monitoring and Mirroring for aVCS Devices

Port mirroring and monitoring is supported in an aVCS setup. Use the fol-
lowing command:
mirror-port ethernet port-num device device-id
The only distinction from the base command is that in aVCS scenario, you
must specify the device ID as shown below:
AX5200-11-Active-vMaster[1/1](config)#mirror-port 2 ethernet 13 ?
device Device
input Mirror incoming packets to this port
output Mirror outgoing packets to this port
In the monitoring mode, you can specify the device to which the Ethernet
belongs:
AX5200-11-Active-vMaster[1/1][p1]#show mirror ?
active-vrid VRRP-A vrid
device Device
| Output modifiers
The following output displays that Ethernet 2 resides on device 1:

interface ethernet 1/2
cpu-process
monitor both 1 vlan 3

Overview
VLAN-to-VLAN Bridging
This chapter describes VLAN-to-VLAN bridging and how to configure it.
Overview
VLAN-to-VLAN bridging allows an ACOS device to selectively bridge
traffic among multiple VLANs. The ACOS device selectively forwards
packets from one VLAN to another based on the VLAN-to-VLAN bridging
configuration on the ACOS device. This feature allows the traffic flow
between VLANs to be tightly controlled through the ACOS device without
the need to reconfigure the hosts in the separate VLANs.
VLAN-to-VLAN bridging is useful in cases where reconfiguring the hosts

on the network either into the same VLAN, or into different IP subnets, is
not desired or is impractical.
You can configure a bridge VLAN group to forward one of the following
types of traffic:
• IP traffic only (the default) – This option includes typical traffic
between end hosts, such as ARP requests and responses.
This option does not forward multicast packets.
• All traffic – This option forwards all types of traffic.
Configuration Notes
VLAN-to-VLAN bridging is supported on ACOS devices deployed in
transparent mode (Layer 2) or in gateway mode (Layer 3).
Each VLAN to be bridged must be configured on the ACOS device. The

normal rules for tagging apply:
• If an interface belongs to only one VLAN, the interface can be
untagged.
• If the interface belongs to more than one VLAN, the interface must be
tagged.
Each VLAN can belong to only a single bridge VLAN group.

Configuration
Each bridge VLAN group can have a maximum of 8 member VLANs. Traf-
fic from any VLAN in the group is bridged to all other VLANs in the group.
Up to 64 bridge VLAN groups are supported.
If the ACOS device is deployed in gateway mode, a Virtual Ethernet (VE)

interface is required in the bridge VLAN group.
Configuration
To configure VLAN-to-VLAN bridging:
1. Configure each of the VLANs to be bridged. In each VLAN, add the
ACOS device’s interfaces to the VLAN.
2. Configure a bridge VLAN group. Add the VLANs to the group.

If the ACOS device is deployed in gateway mode, add a Virtual Ethernet
(VE) interface to the group.
Optionally, you can assign a name to the group. You also can change the
types of traffic to be bridged between VLANs in the group.
3. If the ACOS device is deployed in gateway mode, configure an IP

address on the VE to place the ACOS device in the same subnet as the
bridged VLANs.
USING THE CLI
To configure a bridge VLAN group, use the following commands.
[no] bridge-vlan-group group-num

Use this command at the global configuration level of the CLI to create the
bridge VLAN group and enter the configuration mode for it, where the fol-
lowing commands are available. The group-num can be 1-64.
If the ACOS device is a member of an aVCS virtual chassis, specify the
group number as follows: DeviceID/group-num
[no] name string

This command configures a name for the group. The string can be 1-63
characters long. If the string contains blank spaces, use double quotation
marks around the entire string.
[no] vlan vlan-id

[vlan vlan-id ... | to vlan vlan-id]
This command adds the VLANs to the group.

Configuration
[no] router-interface ve num

On an ACOS device deployed in gateway mode, this command adds the VE
to the group.
forward-all-traffic
This command configures the ACOS device to forward all types of traffic
between the VLANs in the group. By default, only IP traffic is forwarded. If
you change the traffic type but later want to change it back to the default,
you can use the following command: forward-ip-traffic
Group Information and Statistics

To display information for a bridge VLAN group, use the following com-
mand:
show bridge-vlan-group [group-id]
CLI Example – Transparent Mode

The commands in this section configure an ACOS device deployed in trans-
parent mode to forward IP traffic between VLANs 2 and 3.
The following commands configure the VLANs:

ACOS(config)#vlan 2
ACOS(config-vlan:2)#tagged ethernet 2
ACOS(config-vlan:2)#exit
ACOS(config)#vlan 3
The following commands configure the bridge VLAN group:

ACOS(config)#bridge-vlan-group 1
ACOS(config-bridge-vlan-group:1)#vlan 2 to 3
ACOS(config-bridge-vlan-group:1)#exit

Configuration
CLI Example – Gateway Mode
The commands in this section configure an ACOS device deployed in gate-

way mode to forward IP traffic between VLANs 2 and 3 on IP subnet
192.168.1.x.
The following commands configure the VLANs:

ACOS(config)#vlan 2
ACOS(config)#vlan 3
The following commands configure the bridge VLAN group, which

includes a VE:
ACOS(config)#bridge-vlan-group 1
ACOS(config-bridge-vlan-group:1)#vlan 2 to 3
ACOS(config-bridge-vlan-group:1)#router-interface ve 1
ACOS(config-bridge-vlan-group:1)#exit
The following commands assign an IP address to the VE:

ACOS(config-if:ve1)#ip address 192.168.1.100 /24
ACOS(config-if:ve1)#exit

FIPS-Compliant and FIPS-Certified ACOS Devices
FIPS Support
The A10 Thunder Series and the AX Series support Federal Information
Processing Standards (FIPS).
The following sections describe the FIPS support added in this release.
• “FIPS-Compliant and FIPS-Certified ACOS Devices” on page 585
• “FIPS Compliance for Hardware” on page 586
• “FIPS Compliance for SSL” on page 588
• “FIPS Compliance for Software” on page 589
• “Web Support for FIPS Compliance” on page 590
• “CLI Support for FIPS Compliance” on page 590
• “FIPS-compliant Web Server” on page 591
FIPS-Compliant and FIPS-Certified ACOS Devices

The following ACOS models are both FIPS-compliant and FIPS-certified,
meaning that the entire ACOS appliance has been certified by NIST. This is
in contrast to some vendors, which only certify their cryptographic cards but
do not submit the entire appliance for FIPS 140-2 certification.
• AX 2500
• AX 2600-GCF
• AX 3000-GCF
• AX 5100 (with 2 SSL modules)
• AX 5200 (with 2 SSL modules)
Note: The FIPS models listed above must be ordered and shipped directly from
A10 Networks. Converting or upgrading a standard ACOS unit to a FIPS
unit (through the field upgrade process) is not supported.

FIPS Compliance for Hardware

To enhance device security and achieve FIPS-compliance, the ACOS device
hardware has the following changes beginning in AX Release 2.6.1-P1.
SSL Modules
FIPS-compliant ACOS devices do not offer the option to add SSL modules
(“cards”) in the expansion slots, because this would require a chassis that
could be opened at the customer premises (which would violate the FIPS
requirements).
While standard A10 Thunder and AX Series models allow installation of

SSL modules, the FIPS-compliant ACOS devices come with a preset num-
ber of SSL modules. There will be no option to upgrade the device by add-
ing SSL modules at a later time.
Tamper-Proof Seals
To enhance security, one or more tamper-evident labels* with a serial num-
ber and company ID are affixed to the ACOS device chassis. (See
Figure 89, “A10 FIPS-approved Tamper-proof Labels,” on page 587.)
Tamper-evident seals are delicate and clearly indicate when the packaging
has been deliberately altered or adulterated. Seals are affixed to the ACOS
device chassis in several places to make it apparent when someone has
opened the box or otherwise disturbed any of the removable components.
Tamper-evident seals are affixed by A10 Networks prior to delivery to the

customer.
*.
Novavision A1579 labels

FIGURE 89 A10 FIPS-approved Tamper-proof Labels
As shown in Figure 90, “Position of Tamper-proof Labels on AX 2500/

2600/3000,” on page 587 and Figure 91, “Position of Tamper-proof Labels
on AX 5100/5200,” on page 588, tamper-evident seals are affixed to the
ACOS device in the following locations:
• On the fan units
• On the expansion slots
• On the power supply
FIGURE 90 Position of Tamper-proof Labels on AX 2500/2600/3000

FIPS Compliance for SSL
FIGURE 91 Position of Tamper-proof Labels on AX 5100/5200
Changes to ACOS Device Chassis

To ensure that internal electronic components cannot be seen through venti-
lation or other openings, the chassis is designed so that it is impossible to
read identification information printed on these internal components.
FIPS Compliance for SSL

To enhance device security and achieve FIPS-compliance, the following
SSL changes are in effect beginning with AX Release 2.6.1-P1:
• Transport Layer Security (TLS), which is FIPS-compliant, is allowed,
but SSLv2 and SSLv3, which are not FIPS-compliant, are not sup-
ported.
• Ciphers that are not FIPS-compliant are disabled during boot.
• Certificates must have at least 1024 bits.
Note: MD5 is not FIPS-compliant and is therefore not supported.

• Only certificates with SHA1 authentication is allowed.
• If Diffie-Hellman key exchange method is used in TLS, then group1 is

disabled because its key size is only 512 bits.

FIPS Compliance for Software
• Inside OpenSSL-FIPS1.2 there is an implementation of ANSI X931
RNG (inside the directory /FIPS).
• When a random number is generated, the value is compared with the last
number that was generated to ensure they are not the same.
• In client/server-SSL situations, the certificate that the ACOS device
receives must meet the requirement of having at least 1024 bits and
SHA-1 authentication.
• To meet FIPS-compliance, the ACOS device supports encryption of
keys with a length equal to or greater than 1024-bits.
• In FIPS mode, exporting of keys can be by secure protocols.
FIPS Compliance for Software

To enhance device security and achieve FIPS-compliance, the following
system-level changes are in effect beginning with AX Release 2.6.1-P1:
Software Upgrade Image

FIPS-compliant software upgrade images have a signature using HMAC.
Software upgrades are allowed only when it is determined that the upgrade
image is correct, after having been verified using the signature.
Ports
While the USB ports have not been physically removed from the hardware,
they have been disabled at the software level to enhance security.
RMAs
In the event that a customer must return the ACOS device to A10 Networks
using the standard Return Merchandise Authorization (RMA) process, the
customer first must use the security-reset system command to destroy all
encryption keys.
Per FIPS requirements, the ACOS device can not be shipped back to the
manufacturer with the software encryption keys intact. This security-reset
system command destroys the keys prior to shipping the device.

Web Support for FIPS Compliance
Caution: Running this command will remove all keys from the system, includ-
ing those used for image integrity during bootup. After the command
is entered, the ACOS device will not boot again.
Lost Passwords
Normally, if a customer loses their password, they can simply perform a
password reset by entering the serial number on their ACOS device using
the management or console port. However, due to FIPS requirements, this
“backdoor” password-reset behavior is not allowed, so if the password is
lost, customers must follow the standard RMA process to return the ACOS
device to A10 Networks so a factory reset of the password can be done.
Web Support for FIPS Compliance

To achieve FIPS compliance, the following changes to the management
GUI are in effect beginning with AX Release 2.6.1-P1:
• Local user passwords must be greater than 6 characters.
In prior releases, ACOS devices had a minimum requirement that pass-
words be at least 3 characters long. FIPS-compliance requires that pass-
words must be at least 6 characters long. As a related change, the default
password has been changed from “a10” to “a10$pass” for FIPS-compli-
ant ACOS devices.
• File transfers between the ACOS device and an external server (from/to
the ACOS device and an external server) must use the “SCP” (Secure
Copy command) communication method. The following alternate file
transfer methods are disable on FIPS-compliant devices: TFTP, FTP,
RCP.
CLI Support for FIPS Compliance

To achieve FIPS compliance, the following changes to the CLI are in effect
beginning with AX Release 2.6.1-P1:
• Telnet services are no longer available under the enable-management
service telnet command.
• SSH 2.0 is FIPS-compliant (and therefore allowed). The RSA, DSA,
and Diffie-Hellman key exchange key sizes must be at least 1024 bits.
• User passwords must be greater than 6 characters.
FIPS-compliance requires that passwords must be at least 6 characters

FIPS-compliant Web Server
long. The default ACOS device password has been changed from “a10”
to “a10$pass” for FIPS-compliant ACOS devices.
• File transfers between the ACOS device and an external server must use
the “SCP” (Secure Copy command) communication method.
The following file transfer methods are disabled: TFTP, FTP, RCP.
• “Back door access”, or entering the serial number via the console or
management ports to reset the ACOS device, is not supported.

The A10 Thunder Series and the AX Series’ web server is FIPS-compliant.
As part of this compliance, the following Cryptographic Algorithms are
approved:
• AES for encryption/decryption
• 3DES for encryption/decryption
• SHA-1 for hashing and for authentication of hashed messages
• RSA for signing and verification, as well as encryption/decryption
• X9.31 for RNG (Random Number Generator)
• Transport Layer Security (TLS) 1.0. is the only FIPS-compliant crypto-

graphic protocol. SSL v2.0 and v3.0 are not FIPS-compliant and will not
be supported.
Additional FIPS 140-2 requirements are described in the National Institute

of Standards and Technology document:
http://csrc.nist.gov/groups/STM/cmvp/standards.html#02


Error Types Monitored by Automatic Recovery
Fail-safe Automatic Recovery
Fail-safe automatic recovery detects critical hardware and software error

conditions. The feature also automatically takes action to recover the system
if any of these errors occurs, so that the ACOS device can resume service to
clients.
Fail-safe automatic recovery is disabled by default, for both hardware and

software errors. You can enable the feature for hardware errors, software
errors, or both.
Error Types Monitored by Automatic Recovery

Fail-safe automatic recovery monitors and recovers from the following
types of system error conditions.
Hardware Errors
When fail-safe monitoring is enabled for hardware errors, the following
types of errors are detected:
• SSL processor stops working – Fail-safe is triggered if an SSL processor
stops working.
• Compression processor stops working – Fail-safe is triggered if an
HTTP compression processor stops.
• FPGA stops working – Fail-safe is triggered if either of these internal
queues stops working.
If any of these types of errors occurs, the ACOS device captures diagnostic
information, then reboots.
Note: Fail-safe recovery also can be triggered by a “PCI not ready” condition.
This fail-safe recovery option is enabled by default and can not be dis-
abled.

Recovery Timeout
Software Errors
When fail-safe monitoring is enabled for software errors, the following
types of errors are detected:
• FPGA I/O buffer shortage – The number of free (available) packet buf-
fers is below the configured threshold. By default, at least 512 packet
buffers must be free for new data. (Monitoring for this type of FPGA
error is applicable to all ACOS device models.)
On ACOS device models that use FPGAs hardware, the FPGA is logi-
cally divided into 2 domains, which each have their own buffers. If an
FPGA buffer shortage triggers fail-safe, recovery occurs only after both
domains have enough free buffers.
• Session memory shortage – The amount of system memory that must be
free for new sessions is below the configured threshold. By default, at
least 30 percent of the ACOS device’s session memory must be free for
new sessions.
In High Availability (HA) or VRRP-A deployments, fail-safe recovers from

software errors by triggering failover to a standby device. To trigger the
failover, fail-safe enables the force-self-standby option.
Note: Fail-safe temporarily enables the force-self-standby option. The ha force-

self-standby command is not added to the running-config.
If neither HA nor VRRP-A is enabled, fail-safe reloads the ACOS device.
Recovery Timeout
The recovery timeout is the number of minutes the ACOS device waits after
detecting one of the hardware or software errors above before recovering
the system.
• Recovery timeout for hardware errors – By default, the ACOS device
reboots as soon as it has gathered diagnostic information. Typically, this
occurs within 1 minute of detection of the error (no timeout). You can
change the recovery timeout for hardware errors to 1-1440 minutes.
• Recovery timeout for software errors – Fail-safe waits for the system to
recover through normal operation, before triggering a recovery. The
default recovery timeout for software errors is 3 minutes. You can
change it to 1-1440 minutes.

Configuration
Configuration
This section describes how to configure the fail-safe feature.
USING THE GUI

USING THE CLI

To configure fail-safe automatic recovery, use the following command at
[no] fail-safe
{
fpga-buff-recovery-threshold 256-buffer-units |
hw-error-monitor-enable |
hw-error-recovery-timeout minutes |
session-memory-recovery-threshold percentage |
sw-error-monitor-enable |
sw-error-recovery-timeout minutes
}
Parameter Description
fpga-buff-
recovery-
threshold
256-buffer-
units Minimum required number of free (available)
FPGA buffers. If the number of free buffers
remains below this value until the recovery time-
out, fail-safe software recovery is triggered.
You can specify 1-10 units. Each unit contains
256 buffers. The default is 2 units (512 buffers).
hw-error-
monitor-enable Enables fail-safe monitoring and recovery for
hardware errors. This is disabled by default.
hw-error-
recovery-
timeout minutes Number of minutes fail-safe waits after a hard-
ware error occurs to reboot the ACOS device.
You can specify 1-1440 minutes. The default is 0
(not set).

Configuration
session-memory-
recovery-
threshold
percentage Minimum required percentage of system mem-
ory that must be free. If the amount of free mem-
ory remains below this value long enough for the
recovery timeout to occur, fail-safe software
recovery is triggered.
You can specify 1-100 percent. The default is 30
percent.
sw-error-
monitor-enable Enables fail-safe monitoring and recovery for
software errors. This is disabled by default.
sw-error-
recovery-
timeout minutes Number of minutes the software error condition
must remain in effect before fail-safe occurs.
– If the system resource that is low becomes free
again within the recovery timeout period, fail-
safe allows the ACOS device to continue normal
operation. Fail-safe recovery is not triggered.
– If the system resource does not become free,
then fail-safe recovery is triggered.
Displaying Fail-safe Information

To display fail-safe information, use the following command:
show fail-safe {config | information}
The config option displays the fail-safe configuration entered by you or

other admins.
The information option displays fail-safe settings and statistics. The output
differs between models that use FPGAs in hardware and models that do not.
(See “CLI Example” on page 597.)
Note: The config option displays the CLI commands only the for settings you
configure. A fail-safe command that is still set to its default value does not
appear in the output.

Configuration
CLI Example
The following commands configure some fail-safe settings and verify the
changes.
AX3400(config)#fail-safe session-memory-recovery-threshold 30
AX3400(config)#fail-safe fpga-buff-recovery-threshold 2
AX3400(config)#fail-safe sw-error-recovery-timeout 3
AX3400(config)#show fail-safe config
fail-safe session-memory-recovery-threshold 30
fail-safe fpga-buff-recovery-threshold 2
fail-safe sw-error-recovery-timeout 3
The following command shows fail-safe settings and statistics on an ACOS

device model that uses FPGAs in hardware:
AX3400(config)#show fail-safe information
Total Session Memory (2M blocks): 1012
Free Session Memory (2M blocks): 1010
Session Memory Recovery Threshold (2M blocks): 809
Total Configured FPGA Buffers (# of buffers): 4194304
Free FPGA Buffers in Domain 1 (# of buffers): 507787
Free FPGA Buffers in Domain 2 (# of buffers): 508078
Total Free FPGA Buffers (# of buffers): 1015865
FPGA Buffer Recovery Threshold (# of buffers): 256
Total System Memory (Bytes): 2020413440
TABLE 25 show fail-safe information fields (FPGA models)

Field Description
Total Session Total amount of the ACOS device’s memory that is allocated
Memory for session processing.
Free Session Amount of the ACOS device’s session memory that is free
Memory for new sessions.
Session Memory Minimum percentage of session memory that must be free
Recovery before fail-safe occurs.
Threshold
Total Total number of configured FPGA buffers the ACOS device
Configured has. These buffers are allocated when the ACOS device is
FPGA Buffers booted. This number does not change during system opera-
tion.
The FPGA device is logically divided into 2 domains, which
each have their own buffers. The next two counters are for
these logical FPGA domains.

Configuration
TABLE 25 show fail-safe information fields (FPGA models) (Continued)
Field Description
Free FPGA Number of FPGA buffers in Domain 1 that are currently free
Buffers in for new data.
Domain 1
Free FPGA Number of FPGA buffers in Domain 2 that are currently free
Buffers in for new data.
Domain 2
Total Free FPGA Total number of free FPGA buffers in both FPGA domains.
Buffers
FPGA Buffer Minimum number of packet buffers that must be free before
Recovery fail-safe occurs.
Threshold
Total System Total size the ACOS device’s system memory.
Memory
The following command shows fail-safe settings and statistics on an ACOS

device model that does not use FPGAs in hardware. (The FPGA buffer is an
I/O buffer instead.)
AX2500(config)#show fail-safe information
Total Session Memory (2M blocks): 1018
Free Session Memory (2M blocks): 1017
Session Memory Recovery Threshold (2M blocks): 305
Total Configured FPGA Buffers (# of buffers): 2097152
Free FPGA Buffers (# of buffers): 2008322
FPGA Buffer Recovery Threshold (# of buffers): 1280
Total System Memory (Bytes): 4205674496
TABLE 26 show fail-safe information fields (non-FPGA models)

Field Description
Total Session Total amount of the ACOS device’s memory that is allocated
Memory for session processing.
Free Session Amount of the ACOS device’s session memory that is free
Memory for new sessions.
Session Memory Minimum percentage of session memory that must be free
Recovery before fail-safe occurs.
Threshold
Total Total number of configured FPGA buffers the ACOS device
Configured has. These buffers are allocated when the ACOS device is
FPGA Buffers booted. This number does not change during system opera-
tion.

Configuration
TABLE 26 show fail-safe information fields (non-FPGA models) (Continued)
Field Description
Free FPGA Number of FPGA that are free for new data.
Buffers
FPGA Buffer Minimum number of packet buffers that must be free before
Recovery fail-safe occurs.
Threshold
Total System Total size the ACOS device’s system memory.
Memory

Configuration

A10 Thunder Series and AX Series —System Guide

Customer Driven Innovation
Corporate Headquarters
A10 Networks, Inc.

3 West Plumeria Dr
San Jose, CA 95134 USA
Tel: +1-408-325-8668 (main)

Tel: +1-888-822-7210 (support – toll-free in USA)
Tel: +1-408-325-8676 (support – direct dial)
Fax: +1-408-325-8666
www.a10networks.com
© 2013 A10 Networks Corporation. All rights reserved.
602

A10 Thunder AX 271-P2 Admin-2013.07.22

Uploaded by

Copyright:

Available Formats

You might also like

A10 Thunder AX 271-P2 Admin-2013.07.22

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A10 Thunder AX 271-P2 Admin-2013.07.22

Uploaded by

Copyright:

Available Formats

System

A10 Thunder™ Series and AX Series

A10 Networks Inc. Software License and End User Agreement

Obtaining Technical Assistance

A10 Networks, Inc.

Tel: +1-408-325-8668 (main)

Collecting System Information

To collect system information, use either of the following methods.

USING THE GUI (RECOMMENDED)

3. Email the file as an attachment to support@a10networks.com.

Customer Driven Innovation 3 of 602

USING THE CLI

4 of 602 Customer Driven Innovation

About This Document

This document describes features of the A10 Networks Advanced Core

• AX Series Advanced Traffic Manager / Application Delivery Controller.

FIGURE 1 A10 Thunder 6430

Customer Driven Innovation 5 of 602

• System Configuration and Administration Guide

• Application Access Management and DDoS Mitigation Guide

• Web Application Firewall Guide

Application Delivery Guides

• Global Server Load Balancing Guide

Note: Some guides include GUI configuration examples. In these examples,

6 of 602 Customer Driven Innovation

A10 Virtual Application Delivery Community

Customer Driven Innovation 7 of 602

8 of 602 Customer Driven Innovation

Obtaining Technical Assistance 3

About This Document 5

Customer Driven Innovation 9 of 602

10 of 602 Customer Driven Innovation

Jumbo Frames 101

Link Trunking 107

Link Monitoring with Automated Link Disable

Customer Driven Innovation 11 of 602

Link Layer Discovery Protocol 141

Bidirectional Forwarding Detection 145

Gateway Health Monitoring 165

Open Shortest Path First (OSPF) 169

12 of 602 Customer Driven Innovation

DHCP and DHCP Relay 181

Internet Group Multicast Protocol Queries 189

Application Delivery Partitions 193

Customer Driven Innovation 13 of 602

Role Based Administration Private Partition 219

Layer 3 Virtualization of Private Partitions 227

Resource Templates for L3V Partitions 247

14 of 602 Customer Driven Innovation

Inter-Partition Routing 259

High Availability 267

Customer Driven Innovation 15 of 602

HA To VRRP-A Migration 345

VRRP-A High Availability 355

16 of 602 Customer Driven Innovation

VRRP-A Configuration and Monitoring

Customer Driven Innovation 17 of 602

VRRP-A Policy-Based Failover Template 429