System Configuration and Administration Guide

System Configuration and Administration Guide
ACOS 2.7.2-P9
System Configuration and
Administration Guide
for A10 Thunder™ Series and AX™ Series
16 September 2016
©
9/16/2016 A10 Networks, Inc. - All Rights Reserved
Information in this document is subject to change without notice.
Patents
A10’s products (including all AX Series products) are protected by one or more of the following U.S. patents: 8595819, 8595791,
8595383, 8584199, 8464333, 8423676, 8387128, 8332925, 8312507, 8291487, 8266235, 8151322, 8079077, 7979585, 7804956, 7716378,
7665138, 7647635, 7627672, 7596695, 7577833, 7552126, 7392241, 7236491, 7139267, 6748084, 6658114, 6535516, 6363075, 6324286,
5875185, RE44701, 8392563, 8103770, 7831712, 7606912, 7346695, 7287084, 6970933, 6473802, 6374300.
Trademarks
The A10 logo, A10 Lightning, A10 Networks, A10 Thunder, aCloud, ACOS, aFleX, aFlow, aGalaxy, aVCS, aXAPI, IDaccess, IDsentrie, IP to ID,
Link Director, MultiLink Director, SoftAX, Thunder, the Thunder logo, VirtualN, and vThunder are trademarks or registered trademarks of
A10 Networks, Inc. All other trademarks are property of their respective owners.
Confidentiality
This document contains confidential materials proprietary to A10 Networks, Inc. This document and information and ideas herein may
not be disclosed, copied, reproduced or distributed to anyone outside A10 Networks, Inc. without prior written consent of A10 Net-
works, Inc.
A10 Networks Inc. Software License and End User Agreement

Software for all A10 Networks products contains trade secrets of A10 Networks and its subsidiaries and Customer agrees to treat 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 information is provided "as-is." The product
specifications and features described in this publication are based on the latest information available; however, specifications are sub-
ject to change without notice, and certain features may not be available upon initial product release. Contact A10 Networks for current
information regarding its products or services. A10 Networks’ products and services are subject to A10 Networks’ standard terms and
conditions.
Environmental Considerations
Some electronic components may possibly contain dangerous substances. For information on specific component types, please contact the
manufacturer of that component. Always consult local authorities for regulations regarding proper disposal 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 loca-
tion, which can be found by visiting www.a10networks.com.
Table of Contents
System Overview .........................................................................................................................21

ACOS Architecture ...........................................................................................................................................21
ACOS Software Processes .............................................................................................................................................. 22
Memory Pre-allocation .................................................................................................................................................... 23
Hardware Interfaces ........................................................................................................................................23
Software User Interfaces................................................................................................................................23
Server Load Balancing ....................................................................................................................................23
Intelligent Server Selection ........................................................................................................................................... 24
SLB Configuration Templates ...................................................................................................................................... 24
Outbound Next Hop Load Distributor .................................................................................................................. 26
Transparent Cache Switching ..................................................................................................................................... 26
Firewall Load Balancing ................................................................................................................................................... 26
Where Do I Start?..............................................................................................................................................26
FIPS Support ..................................................................................................................................29

FIPS-Compliant and FIPS-Certified ACOS Devices................................................................................29
FIPS Compliance for Hardware ....................................................................................................................30
SSL Modules ........................................................................................................................................................................... 30
Hardware Security Module (HSM) .................................................................................................................... 30
Tamper-Proof Seals ............................................................................................................................................................ 30
Changes to ACOS Device Chassis ............................................................................................................................. 33
FIPS Compliance for SSL.................................................................................................................................34
FIPS Compliance for FIPS Level 3 HSM .................................................................................................................. 34
FIPS Compliance for Software......................................................................................................................35
Software Upgrade Image ............................................................................................................................................... 35
Ports ............................................................................................................................................................................................ 35
RMAs ........................................................................................................................................................................................... 35
Lost Passwords ...................................................................................................................................................................... 35
GUI Support for FIPS Compliance...............................................................................................................36
CLI Support for FIPS Compliance................................................................................................................36
FIPS-Compliant Web Server..........................................................................................................................37
Common Setup Tasks....................................................................................... 39
page 3 | ACOS 2.7.2-P9 System Configuration and Administration Guide - 16 September 2016
A10 Thunder Series and AX Series
Contents
Logging On ....................................................................................................................................41
User Interfaces...................................................................................................................................................41
Logging On to the CLI.....................................................................................................................................42
Logging On to the GUI....................................................................................................................................43
Disabling HTTP-to-HTTPS Redirection......................................................................................................44
Console Restart .................................................................................................................................................45
Configuring Basic System Parameters .................................................................................47

Set the Hostname and Other DNS Parameters......................................................................................47
Use the GUI to Set the Hostname and DNS Parameters ............................................................................ 47
Use the CLI to Set the Hostname and DNS Parameters .............................................................................. 48
Set the CLI Banners ..........................................................................................................................................49
Use the GUI to Set the CLI Banners .......................................................................................................................... 49
Use the CLI to Set the CLI Banners ........................................................................................................................... 49
Set the Time and Date Parameters.............................................................................................................50
Set the NTP Server Authentication .......................................................................................................................... 51
CLI Example ................................................................................................................................................................... 55
Set the NTP Server Preference .................................................................................................................................... 55
Use the GUI to Set the NTP Server Preference ......................................................................................... 55
Use the CLI to Set the NTP Server Preference ........................................................................................... 56
Replace the Web Certificate .........................................................................................................................56
Use the GUI to Replace the Web Certificate ...................................................................................................... 57
Use the CLI to Replace the Web Certificate ........................................................................................................ 57
Configure Increased I/O Buffer Support...................................................................................................57
Use the GUI to Configure I/O Buffers ...................................................................................................................... 57
Use the CLI to Configure I/O Buffers ....................................................................................................................... 58
Configure the Management Interface ......................................................................................................58
Use the GUI to Configure the Management Interface ................................................................................ 59
Use the CLI to Configure the Management Interface .................................................................................. 60
Deployment Examples ..............................................................................................................63

Transparent Mode Deployment..................................................................................................................63
Configuration Example ................................................................................................................................................... 64
Routed Mode Deployment ...........................................................................................................................66
Configuration Example ................................................................................................................................................... 66
vThunder ........................................................................................................................................71
vThunder for Multiple Hypervisors ............................................................................................................71
vThunder Installation ......................................................................................................................................73
ACOS 2.7.2-P9 System Configuration and Administration Guide - 16 September 2016 | page 4
Contents
System Requirements: ..................................................................................................................................................... 73

Management of vThunder ............................................................................................................................................ 73
vThunder Feature Support............................................................................................................................73
vThunder Features in SLB Releases .......................................................................................................................... 73
vThunder Features in IPv6 Migration Releases ................................................................................................. 74
Standardized Parameter Limits for vThunder Models .................................................................................. 74
vThunder for Citrix XenServer 5.6...............................................................................................................74
Application Delivery Partition Support....................................................................................................74
Single-Interface Mode for vThunder (VMware only)...........................................................................75
Thunder HVA .................................................................................................................................77
Configuration Management ............................................................................ 79
Backing Up System Information ............................................................................................81

Overview of System Backup .........................................................................................................................81
Saving Multiple Configuration Files Locally............................................................................................83
Configuration Profiles ....................................................................................................................................................... 83
Using the GUI to Work with Configuration Profiles ............................................................................... 84
Using the CLI to Work with Configuration Profiles ................................................................................ 85
Source Interface for Management Traffic ...........................................................................89

Management Interface as the Source for Management Traffic.......................................................89
Route Tables ........................................................................................................................................................................... 89
Management Routing Options .................................................................................................................................. 90
Management Interface as Source for Automated Management Traffic .......................................... 91
Management Interface as Source Interface for Manually Generated
Management Traffic .......................................................................................................................................................... 91
Using a Loopback Interface as the Source for Management Traffic ................................................... 91
Boot Options .................................................................................................................................95

Storage Areas.....................................................................................................................................................95
Displaying Storage Information ................................................................................................................................. 96
Displaying the Storage Location for Future Reboots .................................................................................... 97
Booting from a Different Storage Area .....................................................................................................98
Temporarily Changing the Boot Image for the Next Reboot .................................................................. 98
Permanently Changing the Storage Location for Future Reboots .................................................... 100
Power On Auto Provisioning ................................................................................................ 103
Contents
Overview .......................................................................................................................................................... 103

Power On Auto Provisioning Process .................................................................................................................. 103
Configuration.................................................................................................................................................. 104
System Center Operations Manager Support ................................................................ 105

Overview of SCOM Integration................................................................................................................. 105
Benefits of SCOM .............................................................................................................................................................. 105
Configure SCOM Integration..................................................................................................................... 106
Fail-Safe Automatic Recovery .............................................................................................. 109

Error Types Monitored by Automatic Recovery.................................................................................. 109
Hardware Errors ................................................................................................................................................................. 109
Software Errors ................................................................................................................................................................... 109
Recovery Timeout ............................................................................................................................................................ 110
Total Memory Decrease ............................................................................................................................................... 110
Configure Fail-Safe Automatic Recovery .............................................................................................. 110
Monitoring Tools ............................................................................................ 115
System Log Messages ............................................................................................................. 117

Destinations for Syslog Messages ........................................................................................................... 117
Syslog Message Severity Levels ............................................................................................................... 117
Configurable Syslog Parameters.............................................................................................................. 118
Configure Single-Priority Logging .......................................................................................................... 119
Configure Log Rate Limiting ..................................................................................................................... 120
Emailing Log Messages .......................................................................................................... 123

Boolean Operators ........................................................................................................................................ 123
Configuration.................................................................................................................................................. 124
Simple Network Management Protocol (SNMP) ........................................................... 129

SNMP Support on the ACOS Device ....................................................................................................... 129
Configure Encryption for SNMPv3 Users .............................................................................................. 130
Use the GUI to Configure Encryption for SNMPv3 Users ........................................................................ 130
Use the CLI to Configure Encryption for SNMPv3 Users .......................................................................... 130
Enable SNMP Traps ....................................................................................................................................... 130
SNMP Communities and Views ................................................................................................................ 132
SNMP Community Strings .......................................................................................................................................... 132
SNMP Views ......................................................................................................................................................................... 132
Contents
Configure SNMP............................................................................................................................................. 133

Configure the Source Interface for SNMP Notifications .................................................................. 135
Link Monitoring ......................................................................................................................... 137

Overview of Link Monitoring .................................................................................................................... 137
Link Monitoring Actions ............................................................................................................................. 137
Link Monitor Template Sequence Numbers........................................................................................ 138
Link Monitor Template Logical Operators............................................................................................ 138
Configure Link Monitor ............................................................................................................................... 139
Using the CLI .............................................................................................................................................................. 139
Gateway Health Monitoring ................................................................................................. 143

Overview .......................................................................................................................................................... 143
Configure Gateway Health Monitoring ................................................................................................. 145
Use the GUI to Configure Gateway Health Monitoring ........................................................................... 145
Use the CLI to Configure Gateway Health Monitoring ............................................................................. 145
Multiple Port-Monitoring Mirror Ports .............................................................................. 147

Overview .......................................................................................................................................................... 147
Configure Mirror Ports................................................................................................................................. 147
Port Monitoring and Mirroring for aVCS Devices .............................................................................. 149
Configuration ..................................................................................................................................................................... 149
NetFlow v9 and v10(IPFIX) .................................................................................................... 151

Overview .......................................................................................................................................................... 151
NetFlow Versions Supported .................................................................................................................................... 151
NetFlow Parameters ..................................................................................................................................... 152
Predefined NetFlow Templates ................................................................................................................ 153
Configuring NetFlow.................................................................................................................................... 154
sFlow ............................................................................................................................................. 159

sFlow Sampling Types ................................................................................................................................. 159
Counter Polling Interval ............................................................................................................................................... 159
Packet Sampling Rate .................................................................................................................................................... 160
Information Included in sFlow Datagrams........................................................................................... 160
Configuration.................................................................................................................................................. 160
Network Configuration .................................................................................. 167
Contents
Virtual LAN Support ................................................................................................................. 169

Overview .......................................................................................................................................................... 169
Default VLAN (VLAN 1) ................................................................................................................................................. 169
Virtual Ethernet Interfaces .......................................................................................................................................... 170
Maximum Number of Supported Virtual Ethernet Interfaces ............................................................. 170
VLAN-to-VLAN Bridging .............................................................................................................................. 170
Configuration ..................................................................................................................................................................... 171
Jumbo Frames ........................................................................................................................... 175

Configuration.................................................................................................................................................. 177
Link Trunking ............................................................................................................................. 181

Overview .......................................................................................................................................................... 181
Static Trunk Configuration ......................................................................................................................... 181
Trunk Parameters and Trunk Interface Parameters ..................................................................................... 183
Configuring Trunk Parameters ................................................................................................................................. 183
Adding Ports to a Trunk ....................................................................................................................................... 184
Configuring Port-threshold Parameters .................................................................................................... 184
Configuring Interface-level Parameters on a Static Trunk ............................................................. 185
Static Trunk Configuration Example ..................................................................................................................... 185
Dynamic Trunk Configuration .................................................................................................................. 186
LACP Parameters .............................................................................................................................................................. 186
UDLD ............................................................................................................................................................................... 187
Configuration ..................................................................................................................................................................... 188
Minimum Port Threshold for LACP ....................................................................................................................... 188
Monitoring LACP via the GUI ........................................................................................................................... 190
LACP Passthrough ......................................................................................................................................... 195
Configuration ..................................................................................................................................................................... 196
Link Layer Discovery Protocol .............................................................................................. 203

Overview of LLDP .......................................................................................................................................... 203
Configure LLDP .............................................................................................................................................. 204
LLDP Configuration Example ................................................................................................................................... 204
Open Shortest Path First (OSPF) .......................................................................................... 207

Support for Multiple OSPFv2 and OSPFv3 Processes....................................................................... 207
Support for OSPFv2 and OSPFv3 on the Same Interface or Link ................................................. 207
OSPF MIB Support......................................................................................................................................... 208
OSPF Configuration Example.................................................................................................................... 208
Contents
Interface Configuration ................................................................................................................................................ 208

Global OSPF Parameters .............................................................................................................................................. 209
Clearing Specific OSPF Neighbors ......................................................................................................................... 210
Configuring OSPF-Related HA Parameters .......................................................................................... 212
OSPF Awareness of HA ................................................................................................................................................. 212
OSPF Support on Standby ACOS Device in Layer 3 Inline Mode ...................................................... 213
OSPF Logging ................................................................................................................................................. 213
Configuring Router Logging for OSPF ................................................................................................................ 213
Enable output options ......................................................................................................................................... 213
Set severity level and facility ............................................................................................................................ 214
Enable debug options to generate output ............................................................................................. 215
Border Gateway Protocol (BGP) ........................................................................................... 219

BGP Route Redistributions......................................................................................................................... 219
Using BGP Route Maps to Permit or Deny Updates.......................................................................... 219
Using BGP Route Maps for Traffic Engineering................................................................................... 220
Route Selection Based on Local Preference......................................................................................... 220
Globally-Enabled Default Route Origination....................................................................................... 221
Equal-Cost Multi-path ECMP Support.................................................................................................... 222
Configuration Example ................................................................................................................................................ 222
BGP Support with HA and VRRP-A .......................................................................................................... 224
Matching on VRRP-A VRID or HA Group Status ............................................................................................. 224
Tracking the BGP State Using HA or VRRP-A ................................................................................................... 228
Bidirectional Forwarding Detection .................................................................................. 231

BFD Parameters.............................................................................................................................................. 232
Configuring BFD ............................................................................................................................................ 232
Static Route Support ...................................................................................................................................................... 232
Configuring BFD Parameters for BGP .......................................................................................................... 233
Displaying BFD Information .............................................................................................................................. 234
Disable BFD ................................................................................................................................................................. 234
Configure BFD with OSPF (for IPv4) ...................................................................................................................... 234
Sample Configuration .......................................................................................................................................... 235
Configure BFD with OSPF (for IPv6) ...................................................................................................................... 235
Configure BFD with IS-IS (for IPv4) ........................................................................................................................ 237
Configure BFD with IS-IS (for IPv6) ........................................................................................................................ 238
Contents
Configure BFD with BGP .............................................................................................................................................. 239

Configuring Static BFD ................................................................................................................................................. 239
IPv4 Static BFD (Global) ....................................................................................................................................... 239
IPv6 Static BFD (Global) ....................................................................................................................................... 239
IPv6 Static BFD (Link-Local) ............................................................................................................................... 240
Configuring BFD Intervals ........................................................................................................................................... 240
Global Interval Configuration .......................................................................................................................... 240
Interface Interval Configuration ..................................................................................................................... 240
Enable Authentication .................................................................................................................................................. 241
Authentication Per interface ............................................................................................................................ 241
Authentication Per Neighbor (for BGP only) .......................................................................................... 241
Enable Echo and Demand function ..................................................................................................................... 241
Enable the Echo Function .................................................................................................................................. 241
Enable the Echo Function Per Interface .................................................................................................... 241
Enable Demand Mode ......................................................................................................................................... 241
Asynchronous Mode ............................................................................................................................................. 242
Viewing BFD Status....................................................................................................................................... 242
BFD Summary Output .................................................................................................................................................. 242
BFD Detailed Output ..................................................................................................................................................... 242
Viewing BFD Statistics ................................................................................................................................................... 242
Dynamic Host Configuration Protocol (DHCP) .............................................................. 243

Overview .......................................................................................................................................................... 243
Configuring DHCP......................................................................................................................................... 243
DHCP Relay ...................................................................................................................................................... 244
Configuring DHCP Relay .............................................................................................................................................. 244
Internet Group Multicast Protocol (IGMP) Queries ...................................................... 249

In Routed Mode ....................................................................................................................................................... 249
In Non-Routed Mode ............................................................................................................................................ 250
Configuring IGMP Membership Queries ........................................................................................................... 250
Configuring a Software Defined Network ....................................................................... 253

Understanding Overlay Networks........................................................................................................... 253
Understanding Packet Encapsulation and Transport....................................................................... 254
Understanding VXLAN Encapsulation ................................................................................................................ 255
Understanding NVGRE Encapsulation ................................................................................................................ 255
Understanding Fragmentation of Tunneled Packets ................................................................................ 256
Contents
Configuring a Sample Topology .............................................................................................................. 256

Configuring the Underlay/Provider Partition ................................................................................................. 257
Configuring the Overlay/Tenant Partition P1 ................................................................................................. 259
Verifying the Configuration ....................................................................................................................................... 260
Notes about the Current Implementation ........................................................................................... 261
Network Address Translation (NAT) ............................................................. 263
Configuring Dynamic NAT .................................................................................................... 265

Configuration Elements for Dynamic NAT ........................................................................................... 265
Configuring Dynamic IP Source NAT...................................................................................................... 266
Configuring Dynamic IP NAT with Many Pools................................................................................... 271
Configure NAT Pools ...................................................................................................................................................... 272
Configure LIDs ................................................................................................................................................................... 272
Configure a Class List ..................................................................................................................................................... 272
Class List Syntax ........................................................................................................................................................ 272
Importing a Class List ............................................................................................................................................ 273
Configuring a Class List Using the CLI ........................................................................................................ 273
Enable Inside Source NAT ........................................................................................................................................... 274
Configuring Static NAT ........................................................................................................... 277

Configuration Elements for Static NAT .................................................................................................. 277
Configuring Static IP Source NAT............................................................................................................. 277
NAT ALG Support for PPTP .................................................................................................... 281

Overview of NAT ALG Support for PPTP................................................................................................ 281
Configure NAT ALG Support for PPTP .................................................................................................... 282
Additional NAT Configuration Features ........................................................................... 285

Faster Timeout for TCP/UDP IP NAT Translations............................................................................... 285
Mapping Allocation Method..................................................................................................................... 285
Fast Aging for IP NATted ICMP and DNS Sessions ............................................................................. 286
Client and Server TCP Resets for NATted TCP Sessions.................................................................... 287
Requirements for Translation of DNS Traffic........................................................................................ 288
Pool-specific TCP Maximum Segment Life........................................................................................... 288
IP NAT Use in Transparent Mode in Multi-Netted Environment ................................................... 289
NAT Range List Requires ACOS Device Interface
or Route Within the Global Subnet......................................................................................................... 290
Contents
IP NAT in HA Configurations...................................................................................................................... 290

Disable/Enable Option for Static NAT Mappings ............................................................................... 290
VRRP-A High Availability ............................................................................... 293
Overview of VRRP-A ................................................................................................................. 295

Virtual Router ID............................................................................................................................................. 295
Partition Support .............................................................................................................................................................. 296
Default VRID ........................................................................................................................................................................ 297
Non-Default VRID ............................................................................................................................................................. 297
Leader and Follower VRIDs ......................................................................................................................................... 297
VRID Virtual MAC Addresses ...................................................................................................................................... 297
Floating IP Addresses................................................................................................................................... 298
Configuration Synchronization ................................................................................................................ 299
Session Synchronization............................................................................................................................. 299
Active / Standby Device Selection .......................................................................................................... 299
Failover .............................................................................................................................................................. 301
Policy-based Failover ..................................................................................................................................................... 302
VRRP-A Hello Messages ................................................................................................................................................ 302
Hello Message Timers ........................................................................................................................................... 302
Multicast Hello Message Destination Addresses ................................................................................. 302
Unicast Hello Message Destination Addresses ..................................................................................... 302
Dynamic Priority Reduction ...................................................................................................................................... 303
Priority Calculation ................................................................................................................................................. 304
Track Event Delay .................................................................................................................................................... 305
Pre-emption ............................................................................................................................................................... 305
Force-self-standby .................................................................................................................................................. 305
VRRP-A Interfaces .......................................................................................................................................... 306
Explicitly Configured VRRP-A Interfaces (optional) ..................................................................................... 306
VRRP-A Interface Types and VRRP-A State ............................................................................................... 306
Preferred Receive Interface for Session Synchronization ........................................................................ 307
VRRP-A Parameters ....................................................................................................................................... 307
Deploying VRRP-A .................................................................................................................... 311

Specify the VRRP-A Device ID.................................................................................................................... 311
Configuring Floating IP Addresses for VRRP-A VRIDs....................................................................... 311
Enable VRRP-A ................................................................................................................................................ 311
Force-Self-Standby Reload or Restart Persistence............................................................................. 312
Command Example ........................................................................................................................................................ 312
Contents
Displaying VRRP-A Information................................................................................................................ 312

Manually Synchronizing the Configuration......................................................................................... 313
VRRP-A Information Included ................................................................................................................................... 313
Peer IP Address Option ................................................................................................................................................. 314
To Configure Preemption Delay: .................................................................................................................... 316
Configuration Examples.............................................................................................................................. 317
Simple Deployment ....................................................................................................................................................... 317
Deployment with Custom Priority Settings .................................................................................................... 317
Configuration of Tracking Options ....................................................................................................................... 319
Ethernet Interface Tracking ............................................................................................................................... 319
Trunk Tracking ........................................................................................................................................................... 319
VLAN Tracking ........................................................................................................................................................... 319
Gateway Tracking .................................................................................................................................................... 319
Route Tracking .......................................................................................................................................................... 320
Server Health Tracking ......................................................................................................................................... 320
Preemption Delay ................................................................................................................................................... 320
Increased VLANs for VRRP-A Failover Tracking ...................................................................................... 320
Additional VRID Configuration ................................................................................................................. 323
Configuring the Non-Default VRID ....................................................................................................................... 323
Configuring a Leader and Follower VRID .......................................................................................................... 323
Configuration Example - Configuring a Leader and Follower VRID ......................................... 324
Configuration Example - Configuring a Leader in the Shared Partition ............................... 324
Configuring VRRP-A VRID Lead Switching ........................................................................................................ 325
Manual VRID Lead Switching Using Manual Configuration ......................................................... 326
Automatic VRID Lead Switching Using aVCS ......................................................................................... 327
VRRP-A Status in CLI Prompt ..................................................................................................................... 327
VRRP-A GUI Configuration and Monitoring .................................................................... 329

Configuration.................................................................................................................................................. 329
Configuring VRRP-A Global Parameters ............................................................................................................. 330
General ........................................................................................................................................................................... 331
VRID .................................................................................................................................................................................. 332
Floating IP Address ................................................................................................................................................. 333
VRRP-A Tracking ....................................................................................................................................................... 334
Preferred Session Sync Port ............................................................................................................................... 336
VRID Leader ................................................................................................................................................................. 337
Force Self Standby .................................................................................................................................................. 338
Configuring VRRP-A Interface Parameters ........................................................................................................ 338
Contents
GUI Configuration Examples ..................................................................................................................................... 340

Simple GUI Deployment ..................................................................................................................................... 340
Deployment with Custom Priority Settings .................................................................................................... 341
Monitoring....................................................................................................................................................... 347
Configuration of GUI Tracking Options .............................................................................................................. 347
Gateway Tracking .................................................................................................................................................... 347
VLAN Tracking ........................................................................................................................................................... 349
Trunk Tracking ........................................................................................................................................................... 350
Interface Tracking .................................................................................................................................................... 351
Route Tracking .......................................................................................................................................................... 351
Server Health Tracking ......................................................................................................................................... 353
Monitoring the VRRP-A VRID ..................................................................................................................................... 355
Monitoring VRRP-A Status .......................................................................................................................................... 355
VRRP-A Policy-Based Failover Template ........................................................................... 357

Current VRRP-A Implementation............................................................................................................. 357
Implementation in Previous Releases.................................................................................................... 357
Event Tracking for Weight and Priority.................................................................................................. 358
Template Rules for Shared and Private Partitions.............................................................................. 358
Preemption and Levels................................................................................................................................ 359
Precedence Causing a Failover ................................................................................................................. 359
Higher Weight Scenario ............................................................................................................................................... 359
Higher Priority Scenario ............................................................................................................................................... 360
Equal Weight and Priority Scenario ...................................................................................................................... 361
Events Tracked for Weight via the Templates...................................................................................... 362
Configuring VRRP-A Policy-Based Failovers......................................................................................... 363
Failover Policy Template Error Message ............................................................................................................. 369
VRRP-A Failover Policy Template Configuration Examples ............................................................ 370
Failover Policy Template in a Private Partition ................................................................................................ 370
Show Command Configuration Examples ........................................................................................... 371
High Availability (HA)..................................................................................... 375
Overview of High Availability .............................................................................................. 377

HA on Your ACOS Device ............................................................................................................................ 377
Types of HA Deployment............................................................................................................................ 378
Layer 3 Active-Standby HA ........................................................................................................................................ 379
Layer 3 Active-Active HA ............................................................................................................................................. 381
Layer 2 Active-Standby HA (Inline Deployment) ......................................................................................... 382
Contents
Restrictions .................................................................................................................................................................. 384

Preferred HA Port ..................................................................................................................................................... 384
Port Restart .................................................................................................................................................................. 385
Layer 3 Active-Standby HA (Inline Deployment) ......................................................................................... 386
Comparison to Layer 2 Inline Mode ............................................................................................................ 387
Restrictions .................................................................................................................................................................. 387
HA Messages ................................................................................................................................................... 387
HA Heartbeat Messages .............................................................................................................................................. 387
Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6) .............................................. 388
HA Interfaces................................................................................................................................................... 388
VLAN ID Requirement ................................................................................................................................................... 389
Session Synchronization............................................................................................................................. 390
Optional Failover Triggers .......................................................................................................................... 390
VLAN-Based Failover ....................................................................................................................................................... 390
Gateway-Based Failover ............................................................................................................................................... 391
Route-Based Failover ..................................................................................................................................................... 392
Real Server or Port Health-Based Failover ......................................................................................................... 392
VIP-Based Failover ............................................................................................................................................................ 392
How the Active ACOS Device Is Selected.............................................................................................. 394
HA Pre-Emption ............................................................................................................................................. 396
HA Sets .............................................................................................................................................................. 396
HA Configuration Parameters .............................................................................................. 399
Configuring HA ......................................................................................................................... 407

Configuring Layer 3 HA ............................................................................................................................... 407
Configuring Layer 2 HA (Inline Mode) ................................................................................................... 417
Layer 2 Inline HA Configuration Example ......................................................................................................... 417
Configuring Layer 3 HA (Inline Mode) ................................................................................................... 424
Layer 3 Inline HA Configuration Example ......................................................................................................... 425
Configuring Optional Failover Triggers ................................................................................................. 429
VLAN-Based Failover Example .................................................................................................................................. 429
Gateway-Based Failover Example .......................................................................................................................... 430
Route-Based Failover Example ................................................................................................................................ 431
CLI Examples .............................................................................................................................................................. 431
VIP-Based Failover Example ....................................................................................................................................... 431
Forcing Active Groups to Change to Standby Status ....................................................................... 433
Enabling Session Synchronization .......................................................................................................... 433
Manually Synchronizing Configuration Information........................................................................ 434
Contents
Manual Session Sync Requirements .................................................................................................................... 435

Configuration Items That Are Backed Up ......................................................................................................... 435
Configuration Items That Are Not Backed Up ............................................................................................... 435
Reload of the Target ACOS Device ........................................................................................................................ 436
Caveats ................................................................................................................................................................................... 436
Performing HA Synchronization ............................................................................................................................. 437
Using the GUI ............................................................................................................................................................. 437
Using the CLI .............................................................................................................................................................. 437
Tip for Ensuring Fast HA Failover ............................................................................................................. 437
HA Status Indicators ..................................................................................................................................... 439
Viewing HA Status in the GUI ................................................................................................................................... 439
Viewing HA Status in the CLI .................................................................................................................................... 439
HA Status in CLI Commands ............................................................................................................................ 440
HA Status in the CLI Prompt ............................................................................................................................. 440
Viewing Config-Sync Status....................................................................................................................... 440
Viewing Config Sync Status in the GUI ............................................................................................................... 440
Viewing Config-Sync Status in the CLI ................................................................................................................ 440
HA To VRRP-A Migration ........................................................................................................ 445

Migration Exceptions ..................................................................................................................................................... 445
Comparison of VRRP-A and HA ................................................................................................................ 446
Differences between HA and VRRP-A ................................................................................................................. 447
Migrating from HA to VRRP-A .................................................................................................................................. 448
Reverting to HA from VRRP-A ................................................................................................................................... 452
ACOS Virtual Chassis Systems (aVCS) ........................................................... 453
Overview of aVCS ..................................................................................................................... 455

Configuration Management ..................................................................................................................................... 457
Software Version Management .............................................................................................................................. 457
VRRP-A .................................................................................................................................................................................... 458
High Availability ................................................................................................................................................................ 458
vMaster Election ............................................................................................................................................ 458
First-Time Deployment ................................................................................................................................................. 459
Dynamic Priority ............................................................................................................................................................... 462
Heartbeat Messages ....................................................................................................................................................... 462
Split Chassis ......................................................................................................................................................................... 464
Forced vMaster Takeover ............................................................................................................................................. 464
Automated Configuration Synchronization ........................................................................................ 465
Contents
Manual Configuration Synchronization ................................................................................................ 468

Software Image Synchronization ............................................................................................................ 468
Virtual Chassis Management Interface.................................................................................................. 469
Requirements.................................................................................................................................................. 469
Layer 2 Connectivity ....................................................................................................................................................... 469
aVCS Image Location ..................................................................................................................................................... 469
Memory Requirements for aVCS with Layer 3 Virtualization ................................................................ 470
Changing the System Time in an aVCS Virtual Chassis ............................................................................ 470
aVCS Parameters............................................................................................................................................ 471
Deploying a Virtual Chassis .................................................................................................. 473

Details for step 1 ............................................................................................................................................................... 473
First-Time Deployment Example ............................................................................................................................ 481
Forcing vMaster Takeover........................................................................................................................... 482
Determining a Device’s aVCS ID............................................................................................................... 483
Displaying aVCS Information .................................................................................................................... 484
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 .............................................................. 487
Examples ....................................................................................................................................................................... 488
Commands That Support the active-vrid Option ............................................................................... 489
Option to Disable Syncing of SNMP syscontact OID ................................................................................. 490
vMaster Maintenance Mode ..................................................................................................................................... 490
Configurable aVCS Message Buffer ....................................................................................................................... 491
Enabling Active Monitoring for Configuration Synchronization ........................................................ 491
Replacing a Device in a Virtual Chassis.................................................................................................. 494
Upgrading a Virtual Chassis....................................................................................................................... 494
Adding a Device to a Virtual Chassis ................................................................................. 495

Overview of Adding a Device to a Virtual Chassis............................................................................. 495
Procedure for Adding a Device to a Virtual Chassis .......................................................................... 500
Configuration Synchronization without Reload ........................................................... 501

VRRP-A with aVCS Deployment Example ......................................................................................................... 501
HA with aVCS Deployment Example ................................................................................................................... 503
Note Regarding HA Group ID ................................................................................................................................... 503
Application Delivery Partitions (ADPs)......................................................... 505
Contents
Overview of Application Delivery Partitions .................................................................. 507

Partition Benefits ........................................................................................................................................... 508
Types of Partitions......................................................................................................................................... 509
Hardware-Supported Number of Partitions........................................................................................ 511
Supported RBA and L3V Partitions Per ACOS Device....................................................................... 511
Partition Logos ............................................................................................................................................... 512
Partition-Based Logging ............................................................................................................................. 512
Partition-Based Banners.............................................................................................................................. 513
Limiting Resources for Partitions Using Templates........................................................................... 513
Administering Private Partitions .............................................................................................................. 513
Administrative Roles ...................................................................................................................................................... 513
Administering the Shared Partition ...................................................................................................................... 514
Additional Administrative Capabilities ....................................................................................................... 516
Configuring a Custom GUI Access Role ............................................................................................................. 516
Configuring Partition Admin Accounts .............................................................................................................. 517
Disabling Private Partition Admin Access to the Shared Partition .................................................... 518
Configuring Private Partitions .................................................................................................................................. 519
Deleting a Partition ......................................................................................................................................................... 519
Viewing and Saving the Configuration ................................................................................................. 520
Viewing the Configuration ......................................................................................................................................... 520
Saving the Configuration ............................................................................................................................................ 521
Switching To Another Partition ................................................................................................................ 521
Synchronizing the Configuration ............................................................................................................ 522
Manual Synchronization .............................................................................................................................................. 522
Operator Management of Real Servers ................................................................................................. 524
To Disable or Re-Enable Servers ..................................................................................................................... 526
To Disable or Re-Enable Real Service Ports ............................................................................................. 527
Private Partition Session Limits ................................................................................................................ 527
Configuration Notes ....................................................................................................................................................... 528
Configuring Partition Session Limits .................................................................................................................... 528
Using the GUI ............................................................................................................................................................. 528
Using the CLI .............................................................................................................................................................. 528
Role Based Administration Private Partitions ................................................................. 531

Overview .......................................................................................................................................................... 531
Resources Contained in RBA Private Partitions ............................................................................................. 531
Migrating Resources Between Partitions .......................................................................................................... 533
Simple RBA Partition Configuration ....................................................................................................... 533
Creating Private Partitions .................................................................................................................................. 533
Contents
Example 1: RBA Partition Configuration .................................................................................................... 535

Example 2: Multiple RBA Partition Configuration ................................................................................ 536
Layer 3 Virtualization of Private Partitions ...................................................................... 539

Overview .......................................................................................................................................................... 539
L3V Advantages ................................................................................................................................................................ 540
Resources Contained in L3V Private Partitions .............................................................................................. 540
Layer 3 Virtualization ...................................................................................................................................................... 541
Requirements ............................................................................................................................................................ 542
Per-partition Feature Support for Layer 3 Virtualization ................................................................. 544
Per-partition Default SLB Templates for Layer 3 Virtualization .................................................... 545
Limitations ................................................................................................................................................................... 546
L3V Partition Configuration ....................................................................................................................... 546
Creating Private Partitions .................................................................................................................................. 547
Shared Management VLAN in L3V Private Partitions ....................................................................... 549
Independent SNMP Configuration Expansion for Partitions......................................................... 550
Disabling SNMP Traps for Private Partition .......................................................................................... 551
Configuration ..................................................................................................................................................................... 551
Configuration Examples.............................................................................................................................. 552
Example 1: Simple L3V Partition Configuration .................................................................................... 552
Example 2: Enabling Layer 3 Virtualization .............................................................................................. 554
Example 3: Configuring Partition-Specific Layer 3 Resources ..................................................... 555
Resource Templates for L3V Partitions .................................................................................................. 558
Resource Template Parameters ............................................................................................................................... 559
Application Resource Parameters ................................................................................................................. 560
Network Resource Parameters ........................................................................................................................ 560
System Resource Parameters ........................................................................................................................... 561
Creating a System Resource Template ............................................................................................................... 562
Assigning Resource Limits ................................................................................................................................. 563
Applying a System Resource Template to a Partition ............................................................................... 564
Removing a Resource Template from a Partition ........................................................................................ 565
Contradictory Resource Usage Scenario ........................................................................................................... 566
Monitoring L3V Resource Templates ................................................................................................................... 566
SNMP and Logging Thresholds for Shared and Private Partition Resource Utilization 566
System Logging Rate in Resource Template .......................................................................................... 567
Simultaneous Logging Capabilities for Log Servers in Shared and Private Partitions .. 568
Inter-Partition Routing ........................................................................................................... 569

Overview of Inter-Partition Routing ....................................................................................................... 569
Contents
Configuring Inter-Partition Routing ....................................................................................................... 570

Configuration in the Shared Partition ................................................................................................................. 570
IP SLB Partition Redirect Configuration ..................................................................................................... 571
Configuration Example ........................................................................................................................................ 571
Configuration in the Private Partition .................................................................................................................. 572
Configuring the Default Route—Private Partition to Shared Partition .................................. 572
Configuring SLB Within a Private Partition .............................................................................................. 573
1
System Overview
The following topics are covered in this chapter:
• ACOS Architecture
• Hardware Interfaces
• Software User Interfaces
• Server Load Balancing
• Where Do I Start?
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 configuration.
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 mul-
tiple Virtual LANs (VLANs).
• Route mode – Each ACOS interface is in a separate IP subnet.
1.
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 pro-
cess does the following:
• Brings user-space processes up and down.

• Monitors all its child processes and restarts a process and all dependent 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 exter-
nal 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 process 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.
• 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.
Hardware Interfaces
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 specific ACOS device.
Software User Interfaces

The ACOS device supports the following software user interfaces that can be used to access and configure the device:
• Graphical User Interface (GUI). For more information, see the GUI online help.
• Command Line Interface (CLI) accessible using console, Telnet, or Secure Shell (v1 and v2). For more information, see
the Command Line Interface Reference.
• Simple Network Management Protocol (SNMP) v1, v2c, and v3. For more information, see the MIB Reference.
• XML Application Programming Interface (aXAPI). For more information, see the aXAPI Reference.
Server Load Balancing

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 perspective of a client who accesses services, requests go to and arrive from a single IP address. The cli-
ent 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 1 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 com-
mon settings once and use them in multiple service configurations. The ACOS device provides templates 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 configuration 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 ses-
sions 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 Protocol [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
Where Do I Start?
• 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 virtual 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 Protocol (SIP) traffic
• SMPP – Configures load balancing for Short Message Peer to Peer (SMPP).
• SMTP – Configures STARTTLS support for Simple Mail Transfer Protocol (SMTP) clients
• Streaming-media – Directs client requests based on the requested content
Where applicable, the ACOS device automatically applies a default template 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 applica-
tion, you can configure a different template and apply that one instead. The configuration examples in this guide show how
to do this.
Outbound Next Hop Load Distributor

Outbound Next Hop Load Distributor (NHLD) balances client-server traffic across a set of WAN links. In outbound NHLD, the
clients are located on the internal side of the network. The servers are located on the external side of the network.
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?
• To configure basic system settings, see “Common Setup Tasks” on page 39.
• To configure network settings, see “Network Configuration” on page 167.
• To configure management access security features, see the Management Access Security Guide.
• To configure and secure application delivery and load balancing features, see the following:
• Application Delivery and Server Load Balancing Guide
Where Do I Start?
• Application Access Management and DDoS Mitigation Guide

• Web Application Firewall Guide
Where Do I Start?
FIPS Support
The A10 Thunder Series and the AX Series support Federal Information Processing Standards (FIPS).
The following sections describe the FIPS support in this release.
• FIPS-Compliant and FIPS-Certified ACOS Devices
• FIPS Compliance for Hardware
• FIPS Compliance for SSL
• FIPS Compliance for Software
• GUI Support for FIPS Compliance
• CLI Support for FIPS Compliance
• FIPS-Compliant Web Server
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 5200-11/3000-11-GCF/2600-GCF/2500 (with or without SSL cards)
• AX 5630/3530/3400/3200-12/3030/1030
• AX 5630/3530 (with Nitrox3 SSL cards)
• Thunder 6430S/5430S/3030S/1030S
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 features the following:
• SSL Modules
• Tamper-Proof Seals
• Changes to ACOS Device Chassis
SSL Modules
FIPS-compliant ACOS devices come with a preset number of SSL modules. ACOS devices that are installed with regular SSL
modules are FIPS Level 2.
Hardware Security Module (HSM)

Beginning in Release 2.7.2, ACOS supports Cavium’s Hardware Security Module (HSM). The ACOS devices can support up to
four HSM cards: a single card, a duo card, or a quad card.
The HSM is an SSL device. At FIPS Level 3, the HSM has an increased probability of recognizing outside attempts at physical
access, use of, or modifications to the cryptographic module. Attempts at physical access to the HSM will zeroize all plaintext
CSPs.
NOTE: The FIPS Level 3 HSM currently is supported only on Thunder 5630.
The core function of the HSM is to guard security keys. Keys must first be imported into the ACOS device or else created on
the ACOS device. They are then imported into the HSM device. The HSM locks the keys and only allows certain cipher-suites
and certain key sizes. FIPS compliance does not support 512 bit keys or smaller.
Tamper-Proof Seals
To enhance security, one or more tamper-evident labels* with a serial number and company ID are affixed to the ACOS
device chassis. (See Figure 2, “A10 FIPS-approved Tamper-proof Labels,” on page 31.)
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 2 A10 FIPS-approved Tamper-proof Labels
As shown in Figure 3, “Position of Tamper-proof Labels on AX 2500/2600/3000,” on page 31 and Figure 4, “Position of Tamper-
proof Labels on AX 5100/5200,” on page 32, 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 3 Position of Tamper-proof Labels on AX 2500/2600/3000
FIGURE 4 Position of Tamper-proof Labels on AX 5100/5200
Figure 5, “Position of Tamper-proof Labels on Thunder 1030S/3030S,” on page 33 and Figure 6, “Position of Tamper-proof
Labels on Thunder 5430S/6430S,” on page 33 show the same for some A10 Thunder Series ACOS devices.
FIGURE 5 Position of Tamper-proof Labels on Thunder 1030S/3030S
FIGURE 6 Position of Tamper-proof Labels on Thunder 5430S/6430S
Changes to ACOS Device Chassis

To ensure that internal electronic components cannot be seen through ventilation 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
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-compli-
ant, are not supported.
• 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.
• 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 FIPS Level 3 HSM

• HSM is auto-initialized. Within the HSM, you can import or delete keys. Only 3 ciphers are supported in FIPS mode:
• RSA_WITH_3DES_EDE_CBC_SHA - DES-CBC3-SHA
• RSA_WITH_AES_128_CBC_SHA - AES128-SHA
• RSA_WITH_AES_256_CBC_SHA - AES256-SHA
• Only TLS 1.0 is supported. SSLv3 is not supported.
NOTE: HA-VCS, aVCS, and L3V synchronization of HSM keys currently is not supported.
FIPS Compliance for Software
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 deter-
mined 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 Authori-
zation (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.
CAUTION: Running this command will remove all keys from the system, including 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.
GUI Support for FIPS Compliance
GUI 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 passwords be at least 3 characters long. FIPS-com-
pliance requires that passwords must be at least 6 characters long. As a related change, the default password has
been changed from “a10” to “a10$pass” for FIPS-compliant 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 dis-
able on FIPS-compliant devices: TFTP, FTP, RCP.
• For the FIPS Level 3 HSM, a key must be imported under “Security > HSM.” To save a key to the HSM, follow the steps
below:
a. Select the SSL key from the drop-down menu, and then click the “Add” button on the right-hand side.
b. In the SSL Key List, select the checkbox next to the key you want to import.
• Click the “Import” button to import the key into the HSM.
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 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) commu-
nication 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.
For the FIPS Level 3 HSM with ACOS Release 2.7.2, the following CLI commands can be used:
• To import keys into the HSM device, first make sure that the key has already been imported on the ACOS device or
else created on the ACOS device. Enter the following command at the global configuration level:
hsm import key key-name
NOTE: Currently, only HTTPS supports support HSM keys.
FIPS-Compliant Web Server
• To delete keys on the HSM device, enter the following command at the global configuration level:
hsm delete key key-name
• To erase all content from the HSM cards and restore factory default state, enter the following command at the global
configuration level:
hsm zeroize
Once finished, you must reboot the system.
NOTE: This command will erase all content on HSM cards. The preferred method of deleting
SSL data is to delete the desired keys, rather than to zeroize the card.
• Use the following command to verify that there are HSM cards installed on your device:
show hardware
• To view the status of the HSM or to view the operational statistics of the HSM, use the following commands:
show hsm-status
show slb hsm-stats
• If you have issues reading or accessing the keys imported onto the HSM card, ACOS can print error information when
you enter the following command:
hsm check key [key-name]

The A10 Thunder Series and the AX Series’ web server is FIPS-compliant. As part of this compliance, the following Cryp-
tographic 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 cryptographic 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
Part I
Common Setup Tasks
The following topics are covered in this section:

• “Logging On” on page 41
• “Configuring Basic System Parameters” on page 47
• “Deployment Examples” on page 63
• “vThunder” on page 71
• “Thunder HVA” on page 77
Logging On
This chapter contains the following topics to help you log on to your ACOS device:
• User Interfaces
• Logging On to the CLI
• Logging On to the GUI
• Disabling HTTP-to-HTTPS Redirection
• Console Restart
User Interfaces
ACOS devices provide the following user 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 values to configure or manage the device. You can access the GUI using either of the follow-
ing 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 Representational State Transfer (REST) architec-
ture. 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 ACOS aXAPI Reference.)
NOTE: By default, Telnet access is disabled on all interfaces, including the management inter-
face. 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 sessions.
Logging On to the CLI
Federal Information Processing Standards (FIPS) Compliance
To comply with FIPS security standards, access to the ACOS device’s user interfaces 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 support SSHv2. SSHv1 is not supported. The SSHv2 cli-
ent must support one of the following encryption ciphers:
• 3des-cbc
• aes128-cbc
• aes192-cbc
• aes256-cbc
Other ciphers are not supported.
Logging On to the CLI

NOTE: The ACOS provides advanced features for securing management access to the device.
This section assumes that only the basic security settings are in place.
To log on to the CLI using SSH:
1. On a device connected to a network that can access the ACOS device’s management interface, open an SSH connec-
tion 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 pos-
sible to configure the same value for both passwords.)
If the enable password is correct, the command prompt for the Privileged EXEC level of the CLI appears: ACOS#
Logging On to the GUI
6. To access the global configuration level, enter the config command. The following command prompt appears:
ACOS(config)#
Logging On to the GUI

To access the ACOS device using the GUI:
1. On a device connected to a network that can access the ACOS device’s management interface, open a browser the
enter the IP address of the management interface.
NOTE: See the Release Notes for more information about supported browsers and additional
requirements for using the GUI.
2. If the browser displays a certificate warning, select the option to continue to the server (the ACOS device).
NOTE: To prevent the certificate warning from appearing in the future, you can install a certifi-
cate signed by a Certificate Authority. See “Replace the Web Certificate” on page 56.
3. A login page is displayed in Figure 1. The name and appearance of the dialog depends on the browser you are using.
FIGURE 1 GUI Login Dialog (Firefox)
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.
Disabling HTTP-to-HTTPS Redirection
FIGURE 2 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 termi-
nate a GUI session, click Logout.
For more information about the GUI, refer to the GUI online help.
Disabling HTTP-to-HTTPS Redirection

By default, redirection of HTTP to HTTPS is enabled for access to the management GUI. As a result, even if both HTTP and
HTTPS Web access are enabled on an interface, HTTP requests sent to the interface will be redirected to HTTPS.
To disable redirection of HTTP to HTTPS for Web management access, enter the no web-service auto-redir command
at the global configuration level of the CLI.
Console Restart
If you are already logged into the GUI and want to change the setting for the next login, you can disable redirection from
within the GUI:
1. Select Config > System > Settings > Web.
2. Select the Disabled option in the Redirect HTTP to HTTPS field.
3. Click Apply.
Console Restart
Use the clear console command to terminate the current login process and start a new one:
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 rimacli 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.
Console Restart
Configuring Basic System Parameters
This chapter 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 con-
figuration access to most of the system parameters described in this chapter. For infor-
mation, navigate to Config Mode > Get Started > Basic System, then click Help.
• Set the Hostname and Other DNS Parameters
• Set the CLI Banners
• Set the Time and Date Parameters
• Replace the Web Certificate
• Configure Increased I/O Buffer Support
• Configure the Management Interface
Set 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. The ACOS device will use the text after the
period as the DNS suffix instead of the DNS suffix you configure.
Use the GUI to Set the Hostname and DNS Parameters

To use the GUI to set the hostname and DNS parameters:
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 (Thunder Series) belongs.
4. In the Primary DNS field, enter the IP address of the external DNS server the Thunder Series should use for resolving
DNS queries.
Set the Hostname and Other DNS Parameters
5. In the Secondary DNS field, enter the IP address of an external backup DNS server the Thunder Series should use if the
primary DNS server is unavailable.
6. Click OK.
Figure 3 shows an example:
FIGURE 3 Config Mode > Network > DNS
Use the CLI to Set the Hostname and DNS Parameters

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 to “ACOS-SLB2”:”

ACOS(config)# hostname ACOS-SLB2
ACOS-SLB2(config)#
After you enter this command, note that the command prompt is changed to reflect the new hostname.
NOTE: The “ > ” or “ # ” character and characters in parentheses before “ # ” indicate the CLI level
you are on and are not part of the hostname.
3. To set the default domain name (DNS suffix) for host names on the ACOS device, use the following command (the DNS
suffix “ourcorp” is used in this example):
ACOS(config)# ip dns suffix ourcorp
4. To specify the DNS servers the ACOS device should use for resolving DNS requests, use the following commands:
The following commands sets 10.10.20.25 as the primary DNS server; the ACOS device will always try to use this serve
first:
ACOS(config)# ip dns primary 10.10.20.25
If the primary DNS server is unavailable, the following command sets 192.168.1.25 as the secondary DNS server:
ACOS(config)# ip dns secondary 192.168.1.25
Set the CLI Banners
Set 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.
Use the GUI to Set the CLI Banners

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 message. The GUI automatically places the end marker at the end of the message text in the config-
uration.
3. If you are configuring both messages, repeat step 2 for the other message.
4. Click OK.
Use the CLI to Set the CLI Banners

To change one or both banners, use the banner command.
The following sets the login banner to “welcome to login mode.” This banner will be seen after you enter the admin user-
name:
Set the Time and Date Parameters
ACOS(config)# banner login “welcome to login mode”
The following command sets the exec banner to “welcome to exec mode.” This banner is displayed after you enter the admin
password:
ACOS(config)# banner login “welcome to exec mode”
To use blank spaces within the banner, enclose the entire banner string with double quotation marks.

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. An NTP
server can be configured with or without authentication. You can also specify one preferred NTP server.
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.
Use the GUI to Set Time and Date Parameters

Select Config Mode > System > Settings > Time to view the Date/Time page.
• 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 calendar.
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.
• To select the timezone:
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.
Use the CLI to Set Time and Date Parameters

Use the clock timezone commands set the timezone:
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
Use the show clock command to verify the timezone selected for this device.
Use the ntp command to set NTP parameters. The NTP server that the ACOS device will use is 10.1.4.20:
ACOS-SLB2(config)#ntp server 10.1.4.20
Set the NTP Server Authentication

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 different authentication key ID num-
bers, NTP server authentication will always fail.
NOTE: Currently, aXAPI is not supported for SHA and SHA1 authentication of NTP servers.
Using the GUI

Perform the following steps to enable NTP server authentication:
1. Navigate to Config Mode > System > Settings > Time.
2. Select the “Automatically Synchronize with Internet Time Server (NTP)” check box.
3. In the NTP Authentication Key section, enter a number from 1-65535 to be used as an ID. For Type, select MD5, SHA or
SHA1. Select the Trusted check box. For String, enter the string, either as plain text, or in hex form. Click Add.
4. Repeat the above step for each trusted key you would like to add.
5. Configure an NTP server in the NTP section. Select one of the trusted authentication keys from the drop-down menu to
assign to the NTP server. Click Add.
6. Click Okay at the bottom of the page.
GUI Example
The following example shows a set of SHA1 NTP authentication keys that have been configuring using the GUI.
Using the CLI
Create Authentication Keys
Enter the following command to create an authentication key using MD5:
[no] ntp auth-key num M [hex] string
Configures an MD5 authentication key.
Enter the following command to create an authentication key using SHA:
[no] ntp auth-key num sha [hex] string
Enter the following command to create an authentication key using SHA1:
[no] ntp auth-key num sha1 [hex] string
For num, enter a value between 1-65535. This value applies an identification 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 alphanumeric characters for the key. This value is stored in the system using the A10 encryption
algorithm. The value string can be 1-20 characters in length, if the hex parameter is not included.
The addition of the hex parameter allows you to enter the key and string in HEX format. If hex is indicated, the value of string
can be 21-40 characters in length.
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 | host-name] [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.
Removing NTP Server Authentication Keys
To remove NTP server authentication, simply enter the following command in the CLI:
ntp server [ip-addr | host-name]
NOTE: The command no ntp server [ip-addr | host-name] key num will remove the NTP server
from the ACOS device.
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 modifier 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/5o10esBTDwQjLjV2wDnPBCMuNXbAOc8EIy41dsA5zwQjL-
jV2wDn
ntp trusted-key 1001 1012 1337
ntp server 10.10.3.18 key 1337
Set 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 deter-
mined by an internal calculation.
Use the GUI to Set the NTP Server Preference

In order to select a preferred NTP server, follow the steps listed below:
1. Navigate to Config Mode > System > Settings > Time
2. Enter the IP address of an NTP server and select the Prefer checkbox. Click Add.
3. Click Okay at the bottom of the page.
Replace the Web Certificate
FIGURE 4 Selecting a Preferred NTP Server in the GUI
Use the CLI to Set the NTP Server Preference

The following commands create an NTP server at 11.12.13.14 and verifies this configuration with the show run command.
The prefer parameter causes the ACOS device to use this as the default NTP server.
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
!
...
Replace the Web Certificate

You can replace the web certificate shipped with the ACOS device. Replacing the certificate with a CA-signed certificate pre-
vents the certificate warning from being displayed by your browser when you log onto the GUI.
Configure Increased I/O Buffer Support
Use the GUI to Replace the Web Certificate

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 connection to the remote device, select Use Manage-
ment 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.
Use the CLI to Replace the Web Certificate

Use the following command at the global configuration level of the CLI:
ACOS(config)# web-service certificate-reset
Configure Increased I/O Buffer Support

The AX 5200-11 and 5630 models 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 command.
Use the GUI to Configure I/O Buffers

In the current release, enabling this feature is not supported from the GUI.
Configure the Management Interface
Use the CLI to Configure I/O Buffers

Enter the following command to enable more I/O buffers for the system:
ACOS(config)# big-buff pool
Use the no version of the command to remove a larger buffer for the system:
ACOS(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)?:
Use the show system platform buffer-stats command to view statistics for the I/O buffer pool:
ACOS(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

The management interface (MGMT) is an Ethernet interface to which you can assign a single IPv4 address and a single IPv6
address. The management interface is separate from the Ethernet data interfaces.
Figure 5 shows an example of the management interface on an Thunder Series device.
FIGURE 5 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 management connections
instead. (For information, see “Source Interface for Management Traffic” on page 89.)
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) deploy-
ments, 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.
Use the GUI to Configure the Management Interface

This section describes how to use the GUI to configure the management interface.
1. Log in to 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 6.)
Figure 6 shows the GUI screen used to configure the management IP addresses shown in Figure 5. Here and elsewhere
in this guide, the command paths used to access a GUI screen are listed in the figure caption.
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 6 Config Mode > Network > Interface > Management
Use the CLI to Configure the Management Interface

The following commands access the global configuration level of the CLI:
login as: admin

Welcome to ACOS
Password:***
[type ? for help]
ACOS>enable
Password:(just press Enter on a new system)
ACOS#
ACOS#config
ACOS(config)#
The following commands configure IPv6 access on the management interface:
ACOS(config)#interface management
ACOS(config-if:mgmt)#ipv6 address 2001:db8::2/32

ACOS(config-if:mgmt)#ipv6 default-gateway 2001:db8::1
The following commands configure IPv4 access on the management interface:
ACOS(config)#interface management
ACOS(config-if:mgmt)#ip address 192.168.2.228 /24
ACOS(config-if:mgmt)#ip default-gateway 192.168.2.1
The following commands verify the configuration:
ACOS(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
Deployment Examples
The ACOS device has a management interface and data interfaces. The management interface is a physical Ethernet port. A
data interface is a physical 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.
Transparent Mode Deployment

Figure 7 shows an example of an Thunder Series device deployed in transparent mode.
FIGURE 7 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.
Configuration Example
This section shows the GUI screens and CLI commands needed to deploy the ACOS device as shown in Figure 7.
Using the GUI

1. Select Config Mode > Network > Interface > Transparent. (See Figure 8.)
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 9.)
5. Select the checkbox next to each Ethernet data interface to enable.
6. Click Enable.
FIGURE 8 Config Mode > Network > Interface > Transparent
FIGURE 9 Config Mode > Network > Interface > LAN
Using the CLI

The following commands configure the global IP address and default :
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 example:
AOCS(config)#interface ethernet 1
AOCS(config-if:ethernet1)#enable
AOCS(config-if:ethernet1)#interface ethernet 2
AOCS(config-if:ethernet3)#exit
Routed Mode Deployment

Figure 10 shows an example of an ACOS device deployed in route mode.
NOTE: Route mode is also called “gateway” mode.
FIGURE 10 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 config-
ured 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 gateway, 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 Availability (HA)” on page 375.)
This section shows the GUI screens and CLI commands needed to implement the configuration shown in Figure 10.
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 11.)
FIGURE 11 Config Mode > Network > Interface > LAN - Ethernet data port 1 selected
3. To assign an IPv4 address, click “IPv4” to display the configuration fields for that section, and enter the address informa-
tion.
4. To assign an IPv6 address, click “IPv6” to display the configuration fields for that section, and enter the address informa-
tion.
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 12.)
3. Click OK.
FIGURE 12 Config Mode > Network > Route > IPv4 Static
FIGURE 13 Config Mode > Network > Route > IPv6 Static
Using the CLI

The following commands enable the Ethernet interfaces used in the example 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
vThunder
vThunder is a fully operational software-only version of A10 Networks’ line of A10 Thunder Series and AX Series Advanced
Traffic Managers / Server Load Balancers.
• vThunder for Multiple Hypervisors
• vThunder Installation
• vThunder Feature Support
• vThunder for Citrix XenServer 5.6
• Application Delivery Partition Support
• Single-Interface Mode for vThunder (VMware only)
vThunder for Multiple Hypervisors

ACOS release 2.6.1 first introduced support vThunder for VMware ESX/ESXi. Support for additional hypervisors was added in
subsequent releases, and the current release added support for vThunder 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)
Figure 14 shows the network topology in which a vThunder can be installed on one of the hypervisors listed above.
vThunder for Multiple Hypervisors
FIGURE 14 vThunder for Multiple Hypervisors
The hypervisor is installed on top of commodity hardware, and the virtualized vThunder instance sits on top of the hypervi-
sor layer. Functionality of vThunder is, for the most part, the same as a hardware-based ACOS device.
vThunder Installation
vThunder Installation
The vThunder software can be downloaded as an ISO image. Multiple vThunder instances can be installed in a single hard-
ware platform, such as a PC, with each instance running independently from the others.
• VMware—vThunder for VMware is available as a virtual machine image in Open Virtualization Format (OVF). You can
install vThunder for VMware on a hardware platform running VMware ESX 4.0 or higher, or ESXi 4.0 or higher.
• KVM—vThunder for KVM instance can be installed and run on Fedora 15 (qemu-kvm-0.14.0) with hypervisor 0.8.8 ver-
sion of ‘libvirt’.
• Xen (Citrix)—vThunder for Xen is installed as a fully virtualized virtual machine in a Xen system, such as XenServer,
Xen Cloud Platform (XCP), or Xen Hypervisor.
• HyperV—vThunder 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 vThunder instance is installed must meet certain minimum requirements.
For details, refer to the individual vThunder Installation Guides.
Management of vThunder
vThunder can be managed from the ACOS CLI or GUI, which is the same as any standard hardware-based ACOS device.
vThunder Feature Support

vThunder supports most of the same features as the Thunder and AX Series hardware-based models, but the exact set of
supported features varies based on whether vThunder is running an SLB release or an IPv6 Migration release. Feature support
can also vary based on the underlying hypervisor.
vThunder Features in SLB Releases

When vThunder is running an SLB release, it supports most of the same features supported by the A10 Thunder and AX
Series hardware-based models.
For specific details about feature limitations, refer to the individual vThunder Installation Guides.
vThunder for Citrix XenServer 5.6
vThunder Features in IPv6 Migration Releases

When vThunder is running an IPv6 Migration release, it supports most of the same features supported by the A10 Thunder
and AX Series hardware-based models, such as Large-scale NAT, DS-Lite, NAT64/DNS64, and Lightweight 4over6.
For specific details about feature limitations, refer to the individual vThunder Installation Guides.
Standardized Parameter Limits for vThunder Models

vThunder versions vary by price according to the amount of bandwidth offered. A10 Networks offers a Lab/Developer Edi-
tion, as well as the following paid versions, which can be used in production environments:
• Entry Level/Lab Editions:
• 200 Mbps
• 1 Gbps
• High-performance Editions:
• 4 Gbps
• 8 Gbps
System parameters such as the Maximum number of SSL VIPs or the maximum number of Layer 4 sessions supported, are
identical for the Entry Level edition (with 200-Mbps throughput) as for the High-performance edition (with 8-Gbps through-
put).
This applies to both publicly available parameters, 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.
vThunder for Citrix XenServer 5.6

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

vThunder administrators can configure up to 32 private partitions for each vThunder instance.
L3V offers administrators virtualized management of network resources and SLB resources, which are based on administra-
tive domains or partitions. Layer 3 virtualization can be enabled or disabled on a per-partition basis, allowing each private
partition to own its network resources.
Single-Interface Mode for vThunder (VMware only)
For more information, see “Application Delivery Partitions (ADPs)” on page 505.

To simplify deployment, vThunder for VMware can be configured to use a single interface for management and data traffic.
While vThunder is typically deployed with a separate management and data interface, “single-interface mode” requires con-
solidating the functionality of both the data and management interfaces into one unified interface.
You can configure vThunder 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.
Take note of the following prerequisites:
• This functionality is only supported for vThunder running on the VMware hypervisor, and it is not supported on any of
the other hypervisors.
• The vThunder interface type must be set to “vmxnet3” for single-interface mode.
For more information on configuring Single-interface Mode, see the vThunder for VMware Installation Guide.
Thunder HVA
A10 Networks’ Thunder Hybrid Virtual Appliance (HVA) is a hybrid device that has many virtual instances of the ACOS load
balancers running in one appliance. This hybrid solution offers the power and performance of A10 Networks’ Thunder Series
of Application Delivery Controllers (ADCs), along with the flexibility of a virtual appliance.
Thunder HVA appliances have up to 40 vThunder virtual appliances running on a dedicated hardware platform. For a discus-
sion on vThunder virtual appliances, please see “vThunder” on page 71. The Thunder HVA models support multi-tenancy.
The vThunder instances are strongly isolated from each other, and each virtual appliance has its own instance of the ACOS
operating system, as well as dedicated compute resources.
A10 Networks currently offers two Thunder HVA appliances:
• Thunder 3030S HVA
• Thunder 3530S HVA
The two models are similar, but the 3530S can support up to 40 vThunder virtual machine instances, while the 3030S can
support only 8 vThunder instances. In addition, there are differences in the aggregate throughput supported by the two
devices. While the 3530S appliance supports up to 100 Gbps, the 3030S offers throughput of 35 Gbps.
The Thunder 3530S/3030S HVA appliances enable you to respond to changing traffic volume by provisioning or de-provi-
sioning multiple, higher-performance vThunder virtual appliances as required. You can configure multiple vThunder
instances on the Thunder 3530S/3030S HVA using HA or VRRP-A for redundancy, thus providing complete software failover
capability in a single platform or across multiple platforms.
For more information about Thunder HVA, along with system specifications and installation instructions, refer to the Thunder
3530S/3030S HVA Installation Guide.
Part II
Configuration Management
This following topics are covered in this section:

• “Backing Up System Information” on page 81
• “Source Interface for Management Traffic” on page 89
• “Boot Options” on page 95
• “Power On Auto Provisioning” on page 103
• “System Center Operations Manager Support” on page 105
• “Fail-Safe Automatic Recovery” on page 109
Backing Up System Information
By default, when you click the Save button in the GUI or enter the write memory command in the CLI, all unsaved configu-
ration changes are saved to the startup-config. The next time the ACOS device is rebooted, the configuration 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 Partitions” on page 531.
For information about managing configurations for separate partitions on an ACOS

device configured for Layer 3 virtualization (L3V) partition, see “Layer 3 Virtualization of
Private Partitions” on page 539.
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 Synchronizing the Con-
figuration” on page 313.
• Older implementation of HA –“Manually Synchronizing Configuration Information”
on page 434.
For upgrade instructions, see the release notes for the ACOS release to which you plan to upgrade.
Overview of System Backup

The ACOS device allows you to back up the system, individual configuration 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)
Overview of System Backup
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 management 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_sys-
tem.tar”), specify the new name at the end of the path.
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.
Saving Multiple Configuration Files Locally
The use-mgmt-port option allows you to indicate the use of the management interface as the source interface for the con-
nection to the remote device.
The url option specifies the file transfer protocol, username, and directory path. You can enter the entire URL on the com-
mand 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 commands 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 configuration profiles on the ACOS device. The configuration management commands described in this sec-
tion 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 system configura-
tion, 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 to Work with Configuration Profiles

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. Differences between the two configurations are high-
lighted:
• Yellow – Indicates a configuration section that is present in each device’s configuration, but does not contain exactly
the same configuration 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 configuration 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 configuration shown on the left.
Using the CLI to Work with Configuration Profiles
Saving the Configuration

To manage multiple locally stored configurations, use the write memory or write force commands. Refer to the Com-
mand Line Interface Reference for more information about these commands.
Viewing the Configuration

To view the contents of the startup-config use the show startup-config command. Refer to the Command Line Inter-
face Reference for more information about this command.
Copying the Configuration

To copy a configuration from one area to another (for example, the running-config to a specific profile) use the copy com-
mand. Refer to the Command Line Interface Reference for more information about this command.
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 81.)
Viewing Configuration Differences

To view a side-by-side comparison of the commands in a pair of configurations, use the diff command. Refer to the Com-
mand Line Interface Reference for more information about this command.
Linking a Configuration Profile to the Startup-Config

Use the link command to link the “startup-config” token to a specified configuration 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 replacing the configuration stored in the image area.
Refer to the Command Line Interface Reference for more information about this command.
Deleting a Configuration Profile

Use the delete startup-config command to specify a configuration profile you want to delete. Refer to the Command
Line Interface Reference for more information about this command.
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 specify.
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 example 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
Source Interface for Management Traffic
By default, the ACOS device uses data interfaces as the source for management traffic. Optionally, you can configure the
device to use only the following 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 management 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 management 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 management 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.
Management Interface as the Source for Management Traffic
NOTE: Static routes whose next hop is the management interface are duplicated in the man-
agement 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 subnet, 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 management 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 automated 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 management 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 earlier, it is possible to
lose access to the ACOS device after you downgrade. 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 manage-
ment default gateway.
If this is the case, before you downgrade, remove the TACACS+ configuration 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 automated management traffic is disabled.
To enable it, use the ip control-apps-use-mgmt-port command at the configuration level for the management interface:
ACOS(config-if:management)#ip control-apps-use-mgmt-port
Management Interface as Source Interface for Manually Generated

Management Traffic
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 use-mgmt-port option for all applicable commands.
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 manage-
ment 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+ traf-
fic. SSH also applies to file import and export using SCP.
Web applies to GUI login.
NOTE: Some notes to consider for loopback interfaces:
• Loopback interface IP address – The loopback interface you specify when configur-
ing 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 man-
agement traffic is also enabled, the loopback interface takes precedence over the
management interface. The loopback interface’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 manage-
ment 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 inter-
face selection by specifying a loopback or other type of interface as part of the ping
command. (See the Command Line Interface Reference for syntax information.)
• Layer 3 Virtualization – This feature is supported only for loopback interfaces that
belong to the shared partition. When this feature is configured, 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 ip mgmt-
traffic command at the global configuration level of the CLI.
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 interface 2 as the source interface for management
traffic of all types listed above:
ACOS(config)#ip mgmt-traffic all loopback 2
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 instruc-
tions, 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 1.
FIGURE 1 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 recov-
ery.
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 primary 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 Networks.
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 2 on page 44). The following
graphic shows a detailed view of the System Information section on the Summary page, which shows the software image
versions installed in each of the storage areas.
FIGURE 2 Software Images—Detailed View
System Images
Above the highlighted fields, the Startup Mode field lists the storage area used for the most recent reboot. The Software Ver-
sion field lists the currently 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 version.
ACOS#show version
AX Series Advanced Traffic Manager AX5100
Copyright 2007-2016 by A10 Networks, Inc. All A10 Networks products are
protected by one or more of the following US patents:
9294503, 9294467, 9270774, 9270705, 9258332, 9253152, 9219751, 9215275
9154584, 9154577, 9124550, 9122853, 9118620, 9118618, 9106561, 9094364
9060003, 9032502, 8977749, 8943577, 8918857, 8914871, 8904512, 8897154
8868765, 8849938, 8826372, 8813180, 8782751, 8782221, 8595819, 8595791
8595383, 8584199, 8464333, 8423676, 8387128, 8332925, 8312507, 8291487
8266235, 8151322, 8079077, 7979585, 7804956, 7716378, 7665138, 7647635
7627672, 7596695, 7577833, 7552126, 7392241, 7236491, 7139267, 6748084
6658114, 6535516, 6363075, 6324286, RE44701, 8392563, 8103770, 7831712
7606912, 7346695, 7287084, 6970933, 6473802, 6374300
64-bit Advanced Core OS (ACOS) version 2.7.2-P8, build 132 (May-24-2016,06

:46)
Booted from Hard Disk primary image
Serial Number: AX51051110360007

Firmware version: 0.26
aFleX version: 2.0.0
aXAPI version: 2.1
Hard Disk primary image (default) version 2.7.2-P8, build 132
Hard Disk secondary image version 4.1.0-P2, build 30
Compact Flash primary image (default) version 2.6.1-GR1-P7, build 51
Compact Flash secondary image version 2.6.1-GR1-P7, build 51
Last configuration saved at May-24-2016, 20:25
Build Type: Internal
Hardware: 16 CPUs(Stepping 5), Single 62G Hard disk
Memory 23689 Mbyte, Free Memory 7357 Mbyte
Hardware Manufacturing Code: 103600
Current time is May-24-2016, 22:06
The system has been up 0 day, 0 hour, 40 minutes
ACOS#
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.
Booting from a Different Storage Area
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 Networks.
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.2-P8.132 (*)
Hard Disk secondary 4.1.0-P2.30
Compact Flash primary 2.6.1-GR1-P7.51 (*)
Compact Flash secondary 2.6.1-GR1-P7.51

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 secondary 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 configura-
tion 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 proce-
dures in “Permanently Changing the Storage Location for Future Reboots” on
page 100 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 automatically 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.
# # ### # #
# # ## # # ## # ###### ##### # # #### ##### # # ####
# # # # # # # # # # # # # # # # # # # #
# # # # # # # # ##### # # # # # # # #### ####
####### # # # # # # # # # ## # # # ##### # # #
# # # # # # ## # # ## ## # # # # # # # #
# # ##### ### # # ###### # # # #### # # # # ####
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 98.
CAUTION: Each storage area has its own version of the startup-config. When you save configura-
tion 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 proce-
dures 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 3 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-con-
fig replace the commands that were displayed 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 compact flash. How-
ever, 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 command.
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
Compact Flash primary 2.4.3-P8-SP3.2 (*)
Compact Flash secondary 2.4.3-P8-SP3.2
The following commands save the configuration and copy it to the other storage area:
ACOS(config)#write memory
Building configuration...
[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 setting:
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 (*)
Compact Flash primary 2.4.3-P8-SP3.2 (*)
Compact Flash secondary 2.4.3-P8-SP3.2
Power On Auto Provisioning
Overview
The ACOS Power On Auto Provisioning (POAP) feature automates the process 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 4 shows how the POAP process works.
FIGURE 4 Power On Auto Provisioning Process
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.
Configuration
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
Below are the 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 pre-
caution, 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 existing file “poap_startup.original”.
Using the CLI

POAP mode is enabled by default on vThunder virtual appliances, but the feature is disabled by default on all physical
devices. To enable POAP mode on a physical device, use the poap command at the Global config level.
You can use the following CLI command to show the status (enabled or disabled) of POAP mode:
ACOS# show poap

POAP Mode Enabled
System Center Operations Manager Support
This chapter describes how the ACOS device can be integrated with Microsoft’s System Center Operations Manager (SCOM).
• Overview of SCOM Integration
• Configure SCOM Integration
Overview of SCOM Integration

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 administrators with centralized man-
agement and the ability to monitor large numbers of network devices. The tool displays device status, health, and perfor-
mance 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, ser-
vice 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 following:
• Near real-time performance monitoring
• Customized network map views
• Flexible reporting engine
• Customizable thresholds and alerts
• Historical data collection
Configure SCOM Integration
Figure 5 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 Operat-
ing System (OS).
The PowerShell “cmdlet” pulls updates from the ACOS device and displays critical metrics within the SCOM Dashboard.
FIGURE 5 SCOM topology

The ACOS device SCOM management pack is installed as a snap-in. When performing this installation, please observe the
following system requirements.
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 service-group member within managed A10 device. However, before you can perform these oper-
ations, 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
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.
This chapter contains the following:
• Error Types Monitored by Automatic Recovery
• Configure Fail-Safe Automatic Recovery
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 disabled.
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 buffers 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.)
Configure Fail-Safe Automatic Recovery
On ACOS device models that use FPGAs hardware, the FPGA is logically 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 config-
ured 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 trig-
gering a recovery. The default recovery timeout for software errors is 3 minutes. You can change it to 1-1440 minutes.
Total Memory Decrease

At device reload or reboot, the fail-safe feature provides a mechanism to check the total memory decrease when the ACOS
device boots up and loads the startup configuration. If the total memory size has decreased, and if the size is less than the
configured memory size, a message will be logged (if you have configured the log option) or the ACOS device will shut
down after logging a message (if you have configured the kill option).
When the configured expected physical memory size is larger than the current memory size, a reboot or log message record-
ing the discrepancy will be triggered. The device will remain always in a “loading” state after it reboots or reloads.

This section describes how to configure the fail-safe feature.
Use the GUI to Configure Fail-Safe

Configuration of this feature using the GUI is not supported at this time.
Use the CLI to Configure Fail-Safe

The following commands configure some fail-safe settings and verify the changes.
Trigger the fail-safe recovery if the amount of free memory on your system remains below 30% long enough for the recovery
timeout to occur:
ACOS(config)#fail-safe session-memory-recovery-threshold 30
Trigger the fail-safe recovery if the number of free (available) FPGA buffers drops below 2 long enough for the recovery time-
out to occur:
ACOS(config)#fail-safe fpga-buff-recovery-threshold 2
Trigger the fail-safe recovery if a software error remains in effect for longer than 3 mimutes:
ACOS(config)#fail-safe sw-error-recovery-timeout 3
Verify the configuration:
ACOS(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 show fail-safe command output differs between models that use FPGAs in hardware and models that do not. The
following command shows fail-safe settings and statistics on an ACOS device model that uses FPGAs in hardware:
ACOS(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
The following command shows fail-safe settings and statistics on an ACOS device model that does not use FPGAs in hard-
ware. (The FPGA buffer is an I/O buffer instead.)
ACOS(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
Refer to “show fail-safe” in the Command Line Interface Reference for details about the fields in the output.
Example of Fail-safe for Total Memory Decrease
In the following example, the fail-safe feature will be triggered when the total memory size is less than 5 GB. When this hap-
pens, this event will be logged:
ACOS(config)#fail-safe total-memory-size-check 5 log
The following example helps you decipher if you have a problem with your system memory.
Use the show version command to see the current memory size of your system. The current memory is shown as high-
lighted:
ACOS# show version

AX Series Advanced Traffic Manager AX3200-12
protected by one or more of the following US patents:
8595819, 8595791, 8595383, 8584199, 8464333, 8423676, 8387128, 8332925, 8312507
8291487, 8266235, 8151322, 8079077, 7979585, 7804956, 7716378, 7665138, 7647635
7627672, 7596695, 7577833, 7552126, 7392241, 7236491, 7139267, 6748084, 6658114
6535516, 6363075, 6324286, 5875185, RE44701, 8392563, 8103770, 7831712, 7606912
7346695, 7287084, 6970933, 6473802, 6374300
64-bit Advanced Core OS (ACOS) version 2.7.2-P1, build 46 (Apr-25-2014,05:32)

Booted from Hard Disk primary image
Serial Number: AX32021211480009

aFleX version: 2.0.0
aXAPI version: 2.1
Hard Disk primary image (default) version 2.7.2-P1, build 46
Hard Disk secondary image version 2.6.1-GR1-P4, build 22
Compact Flash primary image (default) version 2.6.1-P2, build 87
Compact Flash secondary image version 2.4.3-p6, build 27
Last configuration saved at Apr-25-2014, 18:57
Hardware: 8 CPUs(Stepping 5), Single 78G Hard disk
Memory 12327 Mbyte, Free Memory 3441 Mbyte
Hardware Manufacturing Code: 102800
Current time is Apr-25-2014, 23:53
The system has been up 0 day, 4 hours, 53 minutes
The current system memory is shown as 12G. In case you configure the fail-safe memory monitoring to be 5G, as shown
below, your system will continue to operate normally, since 5G of memory is less than the 12G of memory that your device
has at its disposal:
ACOS(config)#fail-safe total-memory-size-check 5 kill
However, if you use the above command and configure a memory size of 14G (and you save your configuration by issuing
the write memory command) since 14G exceeds your current device memory size of 12G, your device will experience a
problem. When the device reloads, the fail-safe mechanism will be triggered, traffic will be stopped, and the device will be
shut down. The abnormal state of the device will be evident in the following log message:
[SYSTEM]:Current memory size 12G, less than monitor number 14G. Please check memory.
To correct this issue, use the fail-safe total-memory-check size kill command and specify a memory size that is
less than or equal to the current memory size. The next time your device reloads, it will operate normally.
Part III
Monitoring Tools
The ACOS device can send alerts to administrators through the following methods:
• “System Log Messages” on page 117

• “Emailing Log Messages” on page 123
• “Simple Network Management Protocol (SNMP)” on page 129
In order to monitor the health of the network and its nodes, you can implement the following monitoring tools:
• “Link Monitoring” on page 137

• “Gateway Health Monitoring” on page 143
• “Multiple Port-Monitoring Mirror Ports” on page 147
• “NetFlow v9 and v10(IPFIX)” on page 151
• “sFlow” on page 159
System Log Messages
The ACOS device logs system events with system log (Syslog) messages.
• Destinations for Syslog Messages
• Syslog Message Severity Levels
• Configurable Syslog Parameters
• Configure Single-Priority Logging
• Configure Log Rate Limiting
Destinations for Syslog Messages

The ACOS device can send Syslog messages to the following places:
• Local buffer (default level: Debugging - 7)
• Console CLI session (default level: Error - 3)
• 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. Logging to other places requires additional configura-
tion.
Syslog Message Severity Levels

The standard Syslog message severity levels are supported:
• Emergency – 0
• Alert – 1
• Critical – 2
• Error – 3
Configurable Syslog Parameters
• Warning – 4
• Notification – 5
• Information – 6
• Debugging – 7
Configurable Syslog Parameters

Table 1 lists the configurable Syslog parameters.
TABLE 1 Configurable System Log Settings

Parameter Description Supported Values
Disposition Output options for each message level. For each mes- The following message levels can be
sage level, you can select which of the following output individually selected for each output
(message target)
options to enable: option:
• Console – Messages are displayed in Console sessions. • Emergency (0)
• Buffered – Messages are stored in the system log buf- • Alert (1)
fer. • Critical (2)
• Email – Messages are sent to the email addresses in • Error (3)
the Email To list. (See below.)
• Warning (4)
• SNMP – SNMP traps are generated and sent to the
SNMP receivers. • Notification (5)
• Syslog – Messages are sent to the external log servers • Information (6)
specified in the Log Server fields. (See below.) • Debug (7)
• Monitor – Messages are displayed in Telnet and SSH Only Emergency, Alert, and Critical can
sessions. be selected for SNMP.
Note: For information about emailing log messages, see
Only Emergency, Alert, Critical, and Noti-
“Emailing Log Messages” on page 123. fication can be selected for Email.
Logging Email Settings for sending log messages by email. See “Emailing Log Messages” on
Filter page 123.
Logging Email
Buffer Number
Logging Email
Buffer Time
Facility Standard Syslog facility to use. Standard Syslog facilities listed in RFC
3164.
Log Buffer Entries Maximum number of log entries the log buffer can store. 10000 to 50000 entries
Default: 30000
Configure Single-Priority Logging
TABLE 1 Configurable System Log Settings (Continued)

Parameter Description Supported Values
Log Server IP addresses or fully-qualified domain names of external Any valid IP address or fully-qualified
log servers. domain name.
Only the message levels for which Syslog is selected in Default: None configured
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 servers through
the management port, see “Source Interface for Man-
agement Traffic” on page 89.
Log Server Port Protocol port to which log messages sent to external log Any valid protocol port number
servers are addressed.
Default: 514
Email To Email addresses to which to send log messages. Valid email address. Click the down
arrow next to the input field to add
Only the message levels for which Email is selected in
another address (up to 10).
the Disposition list are sent to log servers.
Each email address can be a maximum
of 31 characters long.
SMTP Server IP address or fully-qualified domain name of an email Any valid IP address or fully-qualified
server using Simple Message Transfer Protocol. domain name.
Note: By default, the ACOS device can reach SMTP serv- Default: None configured
ers 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 man-
agement port, see “Source Interface for Management
Traffic” on page 89.
SMTP Server Port Protocol port to which email messages sent to the SMTP Any valid protocol port number
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
Configure Single-Priority Logging

Single-priority logging allows you to identify one specific severity level to be logged from among the standard syslog mes-
sage severity levels (See “Syslog Message Severity Levels” on page 117).
Configure Log Rate Limiting
This 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; for exam-
ple, there was no way to display severity level 5 log messages without also seeing messages from severity levels 4–0.
Single-priority logging offers more granular control of syslog messages.
To configure single-priority logging, use the logging single-priority command. The following example logs only level 3
(error) messages:
ACOS(config)# logging single-priority 3
You can also specify the severity name instead of number. For example, to log only warnings:
ACOS(config)# logging single-priority warning

The ACOS device uses a log rate limiting mechanism to ensure against overflow of external log servers and the internal log-
ging 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.
Use the GUI to Configure Log Rate Limiting

To configure log rate limiting using the GUI:
1. Select Config Mode > System > Settings > Log.
2. Change settings as needed. (For descriptions of the settings, see Table 1 on page 118.)
3. Click OK.
Use the CLI to Configure Log Rate Limiting

Use the logging command to configure log rate limiting using the CLI.
For example, to change the severity level of messages logged in the local buffer to level 4:
ACOS(config)# logging buffered 4
Replace buffered with a different destination, as desired (see “Destinations for Syslog Messages” on page 117).
NOTE: Only severity levels emergency, alert, critical, and notification can be sent by email.
Sending log messages by email requires additional configuration. See “Emailing Log
Messages” on page 123.
To configure the ACOS device to send log messages to an external Syslog server, use the logging host command to specify
the server:
ACOS(config)# logging host 20.20.10.8

logging host ipaddr [ipaddr...]
[port protocol-port]
You can enter more than one server names or IP addresses in a single command. 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 command. Each time you enter the logging host command, it replaces any set of servers and syslog
port configured by the previous logging host command.
To configure the ACOS device to send log messages by email, use the following commands to specify the email server and
the email addresses:
ACOS(config)# smtp 10.10.10.5

ACOS(config)# logging syslog@myexamplecompany.com
The smtp command specified the mail server; by default it will use port 25 to send Email; you can customize this with the
optional port parameter.
To send event messages to an external SNMP server, see “Simple Network Management Protocol (SNMP)” on page 129.
Emailing Log Messages
You can configure the ACOS device to email log messages, using email log filters. By default, emailing of log messages is dis-
abled.
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 sever-
ity 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, messages 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 sup-
ported. 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 123”.)
• 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 following 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_no-
tation.)
Configuration
Configuration
Using the GUI
1. Select Config Mode > System > Settings > Log.
FIGURE 1 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 buffering 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.
Configuration
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 fil-
ter 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 num-
ber 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 operational commands.
d. In the Audit Buffer Size menu, indicate the number of entries the audit log can hold.
FIGURE 2 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:
Configuration
FIGURE 3 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 mes-
sages. 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 messages.
[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, information, 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.
Configuration
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
The severity-level can be one or more of the following: 0, 1, 2, 5, emergency, 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 messages 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 trigger 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
Configuration
Simple Network Management Protocol (SNMP)
This chapter describes how to enable SNMP to monitor and manage your network.
The following topics are covered:
• SNMP Support on the ACOS Device
• Configure Encryption for SNMPv3 Users
• Enable SNMP Traps
• SNMP Communities and Views
• Configure SNMP
• Configure the Source Interface for SNMP Notifications
SNMP Support on the ACOS Device

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 sup-
ported.
For more detailed information about SNMP, please see the MIB Reference.
The following list of items clarifies the current implementation of SNMP:
• Limit the number of SNMP polling requests to two or three instances. Several concurrent “snmpwalk” requests, will
result in delays, unfinished requests, time out, or error messages.
• Certain SNMP objects, such as the “CPU Per Partition” value, might not work in the current release.
• The ACOS device will limit your ability to change the default SNMP port for traps from port 162. You cannot configure
another port to receive SNMP traps.
• Since the ACOS device generates the SNMP community string for private partitions, you are not allowed to configure
or change the community string.
• The SNMP process may consume 100% of the Control CPU cycles.
Configure Encryption for SNMPv3 Users
Configure Encryption for SNMPv3 Users

ACOS 2.7.2 supports the ability to add encryption at the snmp “user” level. This feature extends overall security with support
for SNMPv3 notifications (traps). SNMPv3 traps are authenticated and encrypted, using the same options already supported
for SNMPv3 in previous releases.
NOTE: After changing the encryption for an SNMP-server user, SNMP must be restarted in order
to reload the configuration. This process will take some time before the SNMP service
becomes available.
Use the GUI to Configure Encryption for SNMPv3 Users

This ACOS release does not support this feature in the GUI.
Use the CLI to Configure Encryption for SNMPv3 Users

To add encryption at the snmp “user” level, use the snmp-server command at the global config level.
The following example shows how to configure an SNMP user “jon”, who is a member in “group1”, using MD5 encryption for
authentication and “jon_password1” as the password:
ACOS(config)# snmp-server user jon group group1 v3 auth md5 jon_password1
The following example shows how to configure an SNMP user “janet”, who is a member in “group2”, using SHA encryption for
authentication and “janet_password1” as the password:
ACOS(config)# snmp-server user janet group group2 v3 auth sha janet_password1
NOTE: The user password can also be specified using the pw-encrypted optional parameter;
do NOT use the encrypted option unless directed to do so by A10 support. This pass-
word is an A10-reserved keyword.
More information about the snmp-server command can be found in the CLI Reference.
Enable SNMP Traps

In order to start receiving SNMP traps, you must enable SNMP traps on a configured SNMP server. You can enable any of the
individual traps, or a category of new SNMP traps. Follow the steps below to enable SNMP traps. All traps are disabled by
default.
For a list of all SNMP traps supported on the ACOS device, see the MIB Reference.
For a list of all CLI commands used for enabling SNMP traps, see the CLI Reference.
Enable SNMP Traps
For information about configuring SNMP traps on L3V partitions, please see “Independent SNMP Configuration Expansion for
Partitions” on page 550 and “Disabling SNMP Traps for Private Partition” on page 551.
Use the GUI to Enable SNMP Traps

Use the CLI to Enable SNMP Traps

The snmp-server enable traps command allows you to enable SNMP traps.
NOTE: Take note of the following:
• In order to begin receiving ssl-cert-expire SNMP traps, you must enable email notifi-
cation of SSL certificate expiration. To do so, use the logging email-address com-
mand from the global configuration level in the CLI. For more information, refer to
the CLI Reference.
• In order to begin receiving resource-usage-warning SNMP traps, you must set
resource utilization thresholds for partitions. For more information, see “SNMP and
Logging Thresholds for Shared and Private Partition Resource Utilization” on
page 566.
• If you have a DNS anycast configuration, all ports of a given virtual server must to be
down before an SNMP trap will be sent.
The following CLI command enables SNMP traps for all SLB events. Note that using the ? allows you to see all SNMP traps
within the category before activating that category.
ACOS(config)#snmp enable traps slb ?

application-buffer-limit Enable application buffer reach limit trap
server-conn-limit Enable SLB server connection limit trap
server-conn-resume Enable SLB server connection resume trap
server-down Enable SLB server-down trap
server-selection-failure Enable SLB server selection failure trap
server-up Enable SLB server-up trap
service-conn-limit Enable SLB service connection limit trap
service-conn-resume Enable SLB service connection resume trap
service-down Enable SLB service-down trap
service-up Enable SLB service-up trap
vip-connlimit Enable the virtual server reach conn-limit trap
vip-connratelimit Enable the virtual server reach conn-rate-limit trap
vip-down Enable SLB virtual server down trap
vip-port-connlimit Enable the virtual port reach conn-limit trap
vip-port-connratelimit Enable the virtual port reach conn-rate-limit trap
vip-port-down Enable SLB virtual port down trap
vip-port-up Enable SLB virtual port up trap
vip-up Enable SLB virtual server up trap
<cr>
SNMP Communities and Views
ACOS(config)#snmp enable traps slb
The following CLI command enables SNMP traps for all SLB changes. An SNMP trap will be sent whenever a change has been
made to the SLB configuration. This includes the creation or deletion of virtual or real servers or ports, and changes to or near
expiration of SSL certificates.
ACOS(config)#snmp enable traps slb-change
The following CLI commands only enable SNMP traps for the creation or removal of virtual and real servers and ports.
ACOS(config)# snmp enable traps slb-change server

ACOS(config)# snmp enable traps slb-change server-port
ACOS(config)# snmp enable traps slb-change vip
ACOS(config)# snmp enable traps slb-change vip-port
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 com-
munity 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 Thunder Series objects is 1.3.6.1.4.1.22610.
The community string is encrypted in the output of the show running-config command and cannot be viewed as readable
text.
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 authenti-
cation 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.
Configure SNMP
Configure SNMP
By default, SNMP service is disabled for all data interfaces. See “Default Management Access Settings” in the Management
Access and Security Guide for more information.
To configure SNMP:
1. If desired, configure location and contact information.
2. If desired, configure external SNMP trap receivers.
3. If desired, configure one or more read-only communities.
4. If desired, 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.
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 hostname 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 management 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:
Configure SNMP
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 or 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 configuration level of the CLI.
1. To configure location and contact information, use the following commands:
snmp-server location location
snmp-server contact contact-name
2. To configure external SNMP trap receivers, use the following command:
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:
Configure the Source Interface for SNMP Notifications
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 command:
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

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 command:
[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)#
Link Monitoring
The ACOS device supports link monitoring with automated link disable or session clear.
This chapter contains the following:
• Overview of Link Monitoring
• Link Monitoring Actions
• Link Monitor Template Sequence Numbers
• Link Monitor Template Logical Operators
• Configure Link Monitor
Overview of Link Monitoring

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 195.)
NOTE: You can configure the feature for individual Ethernet data ports. Configuration 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 monitored Ethernet data interface:
• Clear sessions
• Disable the link on one or more other interfaces
• Enable the link on one or more other interfaces
Link Monitor Template Sequence Numbers
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.
Link Monitor Template 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 Ether-
net data interface.
• Action entries – An action entry specifies the action to take when monitored 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 traffic 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. Normally, it is recom-
mended 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.
Link Monitor Template Logical Operators

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.
Configure Link Monitor

To configure link monitoring with automated link disable or session clear:
1. Configure a monitoring template. Within the template, specify the following 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 template 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 configuration 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 137.)
Logical Operator Configuration

Use the following command to specify the logical operator to use:
[no] {monitor-and monitor-or}
(See “Link Monitor Template Logical Operators” on page 138.)
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 Ethernet 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 sessions, use clear
sessions all.
(For another example, see “LACP Passthrough” on page 195.)
Gateway Health Monitoring
This chapter describes how to configure gateway health monitoring.
For information about health monitoring of servers in Server Load Balancing (SLB) configurations, see the “Health Monitor-
ing” chapter in the Application Delivery and Server Load Balancing Guide.
NOTE: The following items clarify the implementation of gateway health monitoring on your
ACOS device:
• 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 unre-
sponsive gateways. If there is only one gateway, this feature is not useful.
• Gateway health monitoring and SLB server health monitoring are independent fea-
tures. 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 Availability (HA), a dif-
ferent configuration option is required. See “Gateway-Based Failover” on page 391
(for the older implementation of HA) or “Dynamic Priority Reduction” on page 303
(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 gateway, 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 gateway does not respond to any request before the timeout expires, the ACOS device selects
another gateway and begins the health monitoring process again.
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 configurable.
• 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.
Overview
Using the default gateway health monitoring settings, a gateway must respond to a gateway health check within 15 sec-
onds. Figure 4 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 4 Gateway Health Check Using Default Settings – Timeout
Figure 5 shows an example in which a gateway responds before the timeout.
FIGURE 5 Gateway Health Check Using Default Settings – Gateway Responds
Configure Gateway Health Monitoring

Gateway health monitoring is disabled by default. To enable it, use the CLI.
Use the GUI to Configure Gateway Health Monitoring

Configuration of this feature using the GUI is not supported at the time.
Use the CLI to Configure Gateway Health Monitoring

To enable gateway health monitoring, use the slb gateway-health-check command at the global configuration level of the
CLI. The following command enables gateway health monitoring with the default settings:
ACOS(config)#slb gateway-health-check
You can use the optional interval and timeout parameters to further customize your gateway timeout settings.
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
Multiple Port-Monitoring Mirror Ports
Overview
The ACOS software provides support for multiple mirror ports for each traffic direction (inbound, outbound) in addition to
support for a single mirror 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 only supported on A10 Thunder Series and AX Series FPGA-enabled plat-
forms.
Configure Mirror Ports

The following sections describe how to configure mirror ports.
Use the GUI to Configure Mirror Ports

The current release does not support this feature.
Use the CLI to Configure Mirror Ports

To configure mirror ports, use the mirror-port command at the global configuration level:
The following commands configure 4 mirror ports. The output parameter causes egress traffic on the monitored port(s) is
mirrored to the mirror port. The input parameter causes ingress traffic on the monitored port(s) is mirrored to the mirror port.
If neither is specified traffic in both directions is monitored and mirrored to the mirror port.
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 show mirror command verifies the mirror configuration:
ACOS(config)#show mirror
Configure Mirror Ports
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 Ether-
net interface 1 and enable monitoring of its traffic.
ACOS(config)#interface ethernet 1
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 configura-
tion is not valid, because mirror 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
Port Monitoring and Mirroring for aVCS Devices

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 mirroring and monitoring is supported in an aVCS setup.
For more information about configuring aVCS, see “ACOS Virtual Chassis Systems (aVCS)” on page 453.
Configuration
Use the following 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:
ACOS-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:
ACOS-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
NetFlow v9 and v10(IPFIX)
Overview
An ACOS device can act as a NetFlow exporter. The NetFlow exporter (ACOS device) monitors traffic and sends the data to
one or more NetFlow collectors, where the information can be stored and analyzed by a network administrator.
NOTE: NetFlow support for SLB does not support VCS.
FIGURE 6 NetFlow Architecture with an AX device as Exporter
CAUTION: NetFlow is a heavy user of system resources and requires more memory for each session
than is typically the case. When NetFlow is enabled, the session table capacity is
reduced to just one-third (1/3) of its original amount.
NetFlow Versions Supported

The current release supports NetFlow version 9 and NetFlow version 10 (IPFIX). This version is described in RFC 3954, Cisco
Systems NetFlow Services Export Version 9.
NetFlow Parameters
NetFlow Parameters
On an ACOS device, you can configure up to 64 NetFlow monitors. A NetFlow monitor consists of the following protocol
parameters, which can be used to configure the ACOS device to export data in the format of NetFlow v9 or NetFlow v10
(IPFIX). The default protocol is NetFlow v9.
• Export destination – External devices to export the collected data. You can specify the IP address of a single NetFlow
collector, or configure a service group that comprises multiple collectors.
• To achieve load balancing of NetFlow traffic among two or more collectors, they must be placed within the same
service group.
• You can give one collector a higher priority within the service group than the other collector. This will direct Net-
Flow traffic to the primary collector, and the lower priority collector will only be used as a backup.
• If two or more NetFlow collectors are configured using only IP addresses and are not included in a service group,
and if they are configured with the same NetFlow properties (record types), then NetFlow traffic will be duplicated
to both places and the NetFlow traffic will not be load balanced.
NOTE: NetFlow information is sent from the ACOS device through a data port that is dynami-
cally selected and is based upon information in the routing table.
• Record type – Types of data to export. NetFlow exporters use the following types of messages to send collected data
to a collector server:
• Templates – A NetFlow template defines the set of data to be collected, and the order in which that information will
appear in the data messages.
• Data – NetFlow data messages contain the collected data, such as flow information. Packets for data messages can
contain data for more than one flow.
Each NetFlow monitor can use one or more NetFlow templates. This release includes some predefined NetFlow tem-
plates. (See “Predefined NetFlow Templates” on page 153.)
• Monitoring filters – Specific type of resources to monitor. You can specify monitoring of the following resource:
Ethernet data ports – Specify the list of ports to monitor. Flow information for the monitored interfaces is sent to the
NetFlow collector(s).
By default, no filters are in effect. Traffic on all interfaces and Virtual Ethernet (VE) interfaces are monitored.
• Flow timeout – This is the interval for sending flow records for long-lived sessions. (For short-lived sessions, any flow
records are sent upon termination of the session.) For long-lived sessions, the flow timeout default value is 10 min-
utes. After this amount of time has elapsed, the ACOS device will send any flow records to the NetFlow collector, even
if the flow is still active. The flow timeout can be set to 0-1440 minutes. If this is set to 0, this essentially disables the
flow timeout feature. Regardless of how long-lived a flow might be, the ACOS device waits until the flow has ended
and the session is deleted before it sends any flow records for it.
NOTE: This parameter applies only to templates for flows. These are the templates listed in the
“Templates for A10 Flow Records with NAT Addresses” section of Table 2 on page 154.
Predefined NetFlow Templates
• Template transmission options – The ACOS device periodically resends the NetFlow templates to the collector(s). The
following counters control when the templates are resent:
• Number of data records sent – this is a running counter of the total number of data messages that have been sent
to the NetFlow collector. After the specified number of data records are sent, the ACOS device resends the template
that describes the data (as a way to refresh the template). The default is 1000 records. You can set the set template
interval to 0-1000000 records. Set to 0 to disable.
• Number of seconds since the last time the template was sent – After the specified number of seconds has passed,
the ACOS device resends the template to perform a refresh of the template on the collector. The default is 1800 sec-
onds. You can set it to 0-86400 seconds. After the template is resent, this counter is set back to 0 seconds. Set to 0 to
disable.
• Management interface – Uses the IP of the ACOS management interface, instead of the IP of the data interfaces when
sending traffic to the NetFlow collectors. By default, the ACOS device sends NetFlow traffic out the data interface.
When the Management Interface option is enabled, the NetFlow information is still sent via a data interface that is
dynamically (and automatically) selected based upon the routing table, but the source IP of the packets will be the IP
of the management port.
• Monitor state – Enabled or disabled. By default, a NetFlow monitor is enabled.
Predefined NetFlow Templates

In the current release, the ACOS device includes the following two pre-defined NetFlow templates:
• Cisco NetFlow V5 record, for IPv4 (netflow-v5)
• Cisco NetFlow V5 Extended record, for IPv6 (netflow-v5-ext)
Configuring NetFlow
Table 2 includes details about these templates..
TABLE 2 ACOS NetFlow Template Types

Template Name Key Fields Non-Key Fields
netflow-v5 • IP Protocol • IP Source AS
• IPv4 Source Address • IP Destination AS
• IPv4 Destination Address • IPv4 Next Hop Address
• Source Port • IPv4 Source Mask
• Destination Port • IPv4 Destination Mask
• IP ToS
• TCP Flags
• Interface Input
• Interface Output
• Counter Bytes
• Counter Packets
• Timestamp First Packet
• Timestamp Last Packet
netflow-v5-ext • Protocol • Traffic Class
• IPv6 Source Address • Routing Source AS
• IPv6 Destination Address • Routing Destination AS
• Transport Source Port • Routing Next-hop Address
• Transport Destination Port Protocol • IP Source Mask
• IPv6 Source Address • IP Destination Mask
• IPv6 Destination Address • Transport TCP Flags
• Transport Source Port • Interface Input
• Transport Destination Port • Interface Output
• Flow Direction
• Counter Bytes
• Counter Packets
• Timestamp First Packet
• Timestamp Last Packet
Configuring NetFlow
1. If using multiple NetFlow collectors, create a server configuration for each collector, and add the server configurations
to a service group.
Make sure to disable the Layer 4 health check on the UDP port.
2. Configure a NetFlow monitor. Within the monitor, specify the following:
• The destination, which can be one of the following:

• Host address, if using a single NetFlow collector
• Service-group name, if using multiple NetFlow collectors
Configuring NetFlow
• The record types to export. (Specify them by NetFlow template type.)

• (Optional) The Ethernet interfaces from which to collect NetFlow information. By default, information is collected
for all interfaces.
• (Optional) Adjust the flow timeout.
• (Optional) Adjust the template resend counters.
• (Optional) Adjust the maximum packet queue time.
NOTE: If you plan to use only a single NetFlow collector, you do not need to perform step 1.
You can specify the NetFlow collector’s IP address when configuring the NetFlow moni-
tor (in step 2).
Using the GUI

1. Select Config Mode > IP Source NAT > NetFlow Monitor.
2. Click the Add button. The NetFlow Monitor Create page appears.
3. Enter a name for the NetFlow monitor in the Name field.
4. Configure the following fields and options:
• The Destination, which can be one of the following:

• Host address, if using a single NetFlow collector
• Service-group name, if using multiple NetFlow collectors
• (Optional) Adjust the flow timeout. Default is 10 minutes.
• (Optional) Adjust the Records to Resend Template. The default is 1000 records, after which the template will be re-
sent to the collector and the counter will be reset to 0.
• (Optional) Adjust the Timeout to Resend Template. The default is 1800 seconds, after which the template is re-sent
to the collector.
• (Optional) Select the Source IP Use MGMT checkbox to use the IP address of the management port of the ACOS
device as the source IP of the NetFlow packets, even when packets are sent out the data interface.
• Select the Protocol version. The default is NetFlow Version 9, but you can also select NetFlow Version 10.
• The record types to export. (Specify them by NetFlow template type.)
5. When finished, click OK to save your changes.
Using the CLI
Configure the NetFlow Servers and Service Group (if using multiple NetFlow Collectors)
NOTE: If you plan to use only a single collector, skip this section and go to “Configure the Net-
Flow Monitors” on page 156.
1. Use the following commands to create the real server configurations.

[no] slb server server-name ipaddr
Configuring NetFlow
This command creates the server and accesses the configuration level for it.
Use the following command to add the protocol port on which the collector listens for NetFlow traffic.
[no] port portnum {tcp | udp}
This command adds the port to the server configuration, and accesses the configuration level for the port. At this level,
use the following command to disable the Layer 4 health check for the port:
no health check
NOTE: Layer 4 health checks are not supported by NetFlow, so if a Layer 4 health check were
sent to the collector, it would be rejected and the ACOS device, (failing to receive the
expected response from the collector), would mark the collector as “down”.
2. Use the following commands to create a service group and add the NetFlow servers to it.
[no] slb service-group group-name {tcp | udp}
For tcp | udp, specify the same protocol specified for the ports on the servers.
This command creates the service group and accesses the configuration level for it. At this level, use the following com-
mand to add the servers and NetFlow ports to the service group:
[no] member server-name:portnum
Configure the NetFlow Monitors
The following command configures a NetFlow monitor and changes the CLI to the configuration level for the NetFlow mon-
itor.
[no] netflow monitor name
At the NetFlow configuration level, the following command specifies the type of NetFlow records to export.
[no] record netflow-template-type
The netflow-template-type refers to the NetFlow template that defines the NetFlow records to export, and it includes the fol-
lowing template types:
• netflow-v5
• netflow-v5-ext
See Table 2 on page 154 for more details about NetFlow template types.
The option to specify both, creation, and deletion allows you to determine which types of events will be exported:
The command below configures filters to specify the type of traffic to be monitored:
[no] monitor
{
ethernet portnum [...] |
global |
ve interface-number
}
Configuring NetFlow
The traffic monitors include the following:
• The ethernet option monitors specific Ethernet data ports.
• The global option monitors all interfaces and NAT pools. This is the default configuration.
• The ve option monitors the specified VE interface.
The following command specifies the NetFlow collectors upon which to export the data.
[no] destination
{ipaddr portnum | service-group group-name}
• If you plan to use only one NetFlow collector, you can specify its IP address and NetFlow port number with this com-
mand.
• If you plan to use multiple NetFlow collectors, use the service-group group-name option to specify the name of the
group that contains the NetFlow collectors.
[no] source-ip-use-mgmt
This command does not change the ACOS port from which NetFlow traffic is exported, but configures the ACOS device to
use the management port’s IP as the source IP for the NetFlow packets.
[no] source-address { ip ipv4addr | ipv6 ipv6addr }
This command specifies the source IP address for the NetFlow packets.
[no] flow-timeout minutes
This command specifies the interval for sending data records for long-lived flows. (See “NetFlow Parameters” on page 152.)
[no] resend-template records num
[no] resend-template timeout seconds
These commands specify the counters by which the ACOS device resends the templates to the collectors. (See “NetFlow
Parameters” on page 152.)
enable | disable
Enables or disables the NetFlow monitor. By default, NetFlow monitors are enabled.
At the global configuration level, the following command adjusts the maximum NetFlow packet queue time:
[no] netflow maximum-packet-queue-time num
For num, you can specify 0-50. The maximum packet queue time will be num multiplied by 20ms. The default maximum
packet queue time is 50 * 20ms, or 1 second.
Displaying NetFlow Information
To display NetFlow information, use the following command:
Configuring NetFlow
show netflow monitor [monitor-name]
CLI Example
The following example shows one single monitor that is used to collect all NetFlow v5 compatible flow records and export
them to the host at IP 10.10.3.2.
ACOS(config)#netflow monitor test

ACOS(config-netflow-monitor)#record netflow-v5
ACOS(config-netflow-monitor)#record netflow-v5-ext
ACOS(config-netflow-monitor)#destination 10.10.3.2
ACOS(config-netflow-monitor)#show netflow monitor
Netflow Monitor test
Protocol Netflow v9
Status: Enable
Filter: Global
Destination: 10.10.3.2:9996
Source IP Use MGMT: No
Flow Timeout: 60 Minutes
Resend Template Per Records: 1000
Resend Template Timeout: 1800 Seconds
Sent: 45 (Pkts) / 8360 (Bytes)
Records:
netflow-v5: 86 (records) / 0 (fails)
netflow-v5-ext: 0 (records) / 0 (fails)
sFlow
ACOS can act as an sFlow agent by sampling random packets and sending statistics in an sFlow datagram to an external
sFlow collector for analysis.
NOTE: Note the following:
• sFlow data collection is supported only for individual Ethernet data ports and VE
interfaces. Data collection cannot be performed on trunk interfaces, loopback inter-
faces, or on the management interface of ACOS.
• Host resource sampling is not supported:
• Application behavior sampling is not supported
• Configuration of sFlow agent behavior using SNMP is not supported
sFlow Sampling Types

sFlow supports two types of sampling. One type of sampling uses a time-based approach to retrieve statistics for a specific
interface, while the other approach samples information from the packet header of every Nth packet.
Details
• You can enable one or both sampling types on a single Ethernet data port – the sampling types are not mutually
exclusive.
• The sFlow datagram includes information about the incoming interface but not the outgoing interface where sam-
pling occurred.
• sFlow data can be exported to up to 4 sFlow collectors. This offers the benefit of redundancy, as well as the ability to
send sFlow datagrams to different destinations.
• By default, the sFlow datagrams use the management IP of ACOS as the source address, but you can modify the
exported sFlow datagrams to the source address of your choice.
Counter Polling Interval

This is a counter sampling method that is based on time. Statistics for an interface are gathered periodically and sent to the
sFlow collector. You can specify the time interval (frequency) with which the counter interfaces statistics are gathered and
sent. This global configuration will apply to all interfaces where sFlow is enabled unless a more granular value is configured
at the interface level. You can enter a value ranging from 1–200 seconds. By default, this interval is set to 20 seconds.
Information Included in sFlow Datagrams
Once ACOS has sampled statistics from a target interface, the information is collected and sent in an sFlow datagram to one
or more sFlow collectors. The sFlow datagrams are listed in the Received and Transmitted counter fields in show interface
CLI output, or on the Monitor Mode > Network > Interface page of the GUI.
Packet Sampling Rate

This is a sampling method that is based on the number of incoming packets. This sampling rate value essentially means that
one packet is sampled out of every N packets. When expressed as a ratio, the packet sampling rate looks like 1/N. You can
enter a value for N (the denominator) ranging from 10–1000000 packets. By default, N is equal to 1000, meaning that one
packet is sampled out of every 1000 packets arriving at that interface. This global configuration will apply to all interfaces
where sFlow data is collected, unless a more granular value has been configured at the interface level.
Unlike the other time-based sampling method, which gathers counter statistics for an interface, this packet-volume sam-
pling approach gathers data about specific packets arriving at an interface. Information is extracted from the first 128 bytes
in the header of the sampled packet, beginning with the MAC header. Once ACOS has sampled packets from a specified tar-
get interface, the information is collected and sent in an sFlow datagram to one or more sFlow collectors.
Information Included in sFlow Datagrams

The following information is included in sFlow datagrams:
• Discarded packets
Information about the discarded packets is included in the sFlow datagrams. For a list of Destination Unreachable
codes associated with discarded packets, see section “Input/Output Port Information” in the following RFC:
http://sflow.org/sflow_version_5.txt
• Export CPU and Memory information
CPU and memory information are included in the “Processor information” section of the exported sFlow datagram.
Configuration
Below are the high-level steps involved in configuring the sFlow data
collection feature on an AX device:
1. Specify the sFlow collector where data will be exported.
2. (Optional) Enable use of the management interface’s IP as the source address for outbound sFlow packets. This may be
beneficial for filtering at the collector or to maintain consistency in the source address of the sFlow packets.
3. Specify the individual Ethernet data interfaces that will be sampled.
4. (Optional) Change the default data sampling rate or polling interval.
Using the GUI

1. Select Config Mode > System > sFlow. The sFlow create page appears.
Configuration
2. (Optional) Enter an IP address for the sFlow agent. By default, the management IP of ACOS is used, but you may enter a
different address if desired.
NOTE: This information will appear in the Layer 4 information section of the sFlow datagram.
Although the information is “textual” and is not used for routing decisions, it may be
helpful in identifying which sFlow agent a particular packet came from, particularly in
complex networks that have more than one sFlow agent.
3. (Optional) Select the Source IP Use MGMT checkbox if you wish to use the AX device’s management IP as the source
address for exported sFlow datagrams. This changes the source address on the sFlow datagrams but has no effect on
which interface the AX device selects for exporting sFlow datagrams.
4. (Optional) In the Counter Polling Interval field, specify the time interval at which the counter of interface statistics will
be sampled. (See “Counter Polling Interval” on page 159 for more information.)
5. (Optional) In the Packet Sampling Rate field, alter the default value if desired. Smaller numbers increase the sampling
frequency, and larger numbers decrease the sampling frequency. (See “Packet Sampling Rate” on page 160 for more
information.)
6. In the Collector area of the page, enter an IPv4 or IPv6 address in the IP address field, and then select the IPv4 or IPv6
radio button.
7. Enter a value in the Port field. This is the port on the collector where sFlow traffic will be sent. By default, traffic is sent to
UDP port 6343.
8. Click Add to add the sFlow collector’s information, and then click OK to save your changes.
9. Next, select Config Mode > Network > Interface > LAN, and then click on the interface upon which you would like to
enable sampling.
A page similar to the one shown below appears.
10. Select the sFlow Counter Polling Interval checkbox to use a time-based approach sampling. By default, the globally
configured polling interval (configured in step 4) is used. To configure a value that is specific to this interface, enter a
new value ranging from 1–200 seconds in the field and select the associated radio button.
11. Select the sFlow Packet Sampling Rate checkbox to use a traffic volume-based approach to sampling. By default, the
globally configured packet sampling rate (configured in step 5) is used. You can enter a new sampling rate value of one
packet per N packets (where N ranges from 10–1000000).
12. When finished, scroll down and click OK to save your changes.
Using the CLI

Use the following commands to configure sFlow support on the AX device.
Configuring an sFlow Agent
To configure an sFlow agent address, use the following command at the global configuration level of the CLI:
[no] sflow agent address ipaddr
The ipaddr value can be any valid IPv4 or IPv6 address. By default, sFlow datagrams use the management IP of ACOS as
the source address, but you can specify a different IP address, if desired. The information will appear in the Layer 4 infor-
mation section of the sFlow datagram, and it is not used to make routing decisions.
Configuration
Configuring an sFlow Collector
To configure an sFlow collector, use the following command at the global configuration level of the CLI:
[no] sflow collector ipaddr [portnum]
The ipaddr value can be any valid IPv4 or IPv6 address, and you can configure up to a total of 4 collectors. For the portnum
parameter, you can enter any valid port number between 1-65535. The default protocol port number for sFlow is 6343.
Configuring the Global Counter Polling Interval
By default, the counter-polling-interval is set to 20 seconds. If desired, you can modify this value by using the follow-
ing command at the global configuration level of the CLI:
[no] sflow counter-polling-interval seconds
The seconds option specifies the interval at which an incoming packet will be sampled from the interface. The interval value
can range from 1-200 seconds.
Configuring the Global Packet Sampling Rate
By default, the packet-sampling-rate samples one packet out of every 1000 incoming packets. If desired, you can mod-
ify this value by using the following command at the global configuration level of the CLI:
[no] sflow packet-sampling-rate num
The num option specifies the value of N, where N is the value of the denominator in the ratio 1/N. This ratio says that one
packet will be sampled out of N packets (denominator), and the value of N can range from 10-1000000. The default is 1000,
meaning one packet out of every 1000 packets will be sampled.
Enabling sFlow On a Specific Interface
You can enable sFlow on an interface (while relying on the globally configured sFlow sampling values) using one of the fol-
lowing commands.
To enable time-based sFlow sampling, use the following command at the global configuration level of the CLI:
[no] sflow polling ethernet port-num
To enable packet volume-based sFlow sampling, use the following command at the global configuration level of the CLI:
[no] sflow sampling ethernet port-num
NOTE: Despite the differences in syntax (“polling” versus “sampling”), both of the commands
above enable sampling on an interfaces. The time-based sampling approach (with “poll-
ing” syntax), samples a counter of interface statistics at a regular time interval, while the
other command (with “sampling” syntax), samples the headers from packets as they
arrive at an interface.
With either command, the port-num option specifies the target Ethernet interface.
Configuration
Changing the Default Counter Polling Interval for an Interface
If sFlow is enabled on an interface, but the counter polling interval has not been specified, then the globally-configured
counter polling interval will be applied. You can configure a different counter polling interval for this specific interface by
using the following command at the global configuration level of the CLI:
[no] sflow polling

{ethernet port-num | ve interface-num}
[to port-num]
interval seconds
The port-num option specifies the target ethernet interface. The interface-num option specifies the target virtual ethernet
interface. The seconds option specifies the frequency with which the counter data for an interface will be sampled, and it can
range from 1-200 seconds.
Changing the Default Packet Sampling Rate for an Interface
If sFlow is enabled on an interface but the packet sampling rate has not been specified, then the globally-configured packet
sampling rate is applied. You can configure a different packet sampling rate value for a specific interface by using the follow-
ing command at the global configuration level of the CLI:
[no] sflow sampling

{ethernet port-num | ve interface-num}
[to port-num]
rate sampling-num
The port-num option specifies the target ethernet interface.The interface-num option specifies the target virtual ethernet
interface. The sample-num option specifies the denominator in the ratio for the packet sampling, 10-1000000. The globally
configured packet sampling rate is one packet out of every 1000.
Configuring Management IP as Source Address
To enable use of the management interface’s IP as the source IP for the sFlow datagrams sent to collectors, use the following
command:
[no] sflow source-ip-use-mgmt
Displaying sFlow Information
To display the sFlow configuration, use the following command:
show sflow configuration [ethernet portnum]
To display sFlow statistics, use the following command:
show sflow statistics [ethernet portnum]
To clear sFlow statistics, use the following command:
clear sflow statistics
CLI Examples
The following commands specify the sFlow collector, and enable use of the management interface’s IP as the source IP for
the data samples sent to the sFlow collector:
Configuration
ACOS(config)#sflow collector 192.168.100.3

ACOS(config)#sflow source-ip-use-mgmt
The following command enables counter polling for several Ethernet data interfaces, and uses the globally configured sam-
pling rate by default:
ACOS(config)#sflow polling ethernet 1 2 5 6 8 10 11
The following command enables counter polling for several Ethernet data interfaces, but uses a custom sampling rate of 24
seconds:
ACOS(config)#sflow polling ethernet 3 4 7 9 12 interval 24
The following command enables packet flow sampling for two Ethernet interfaces, with a sampling rate of 500, meaning
that one packet out of every 500 will be sampled:
ACOS(config)#sflow sampling ethernet 1 2 rate 500
The following command enables packet sampling for a range of Ethernet interfaces, with a packet sampling rate of 12,
meaning that one packet out of every 12 will be sampled:
ACOS(config)#sflow sampling ethernet 3 to 5 rate 12
The following command displays the sFlow configuration:
AACOSconfig)#show sflow configuration

sFlow collector(s)
address 0: 192.168.100.3 /6343
source-ip-use-mgmt: true
sFlow agent address: not set, use management ip address
sFlow default parameter

counter polling interval: 20
packet sampling rate: 1000
sflow polling ethernet 1 2 5 6 8 10 11

sflow polling ethernet 3 4 7 9 12 interval 24
sflow sampling ethernet 1 2 rate 500

sflow sampling ethernet 3 to 5 rate 12
The following command displays sFlow data collection statistics:
ACOS(config)#show sflow statistics

Interface Packet Sample Records Counter Sample Records
-------------------------------------------------------------------
1 3461 81
2 20801 81
3 0 81
4 0 81
Configuration
5 0 81
6 0 81
7 0 81
8 0 81
9 0 81
10 0 81
11 0 81
12 0 81
-------------------------------------------------------------------
sflow total statistics
Packet sample records: 24262
Counter sample records: 972
Sflow packets sent: 16257
The following command displays sFlow data collection statistics specifically for Ethernet data port 4:
ACOS(config)#show sflow statistics ethernet 4

sflow statistics on ethernet 4
packet sample records: 0
counter sample records: 82
Configuration
Part IV
Network Configuration
ACOS devices can be inserted into your network with minimal or no changes to your existing network. See the following
chapters for information about network configuration:
• “Virtual LAN Support” on page 169
• “Jumbo Frames” on page 175
• “Link Trunking” on page 181
• “Link Layer Discovery Protocol” on page 203
• “Open Shortest Path First (OSPF)” on page 207
• “Border Gateway Protocol (BGP)” on page 219
• “Bidirectional Forwarding Detection” on page 231
• “Dynamic Host Configuration Protocol (DHCP)” on page 243
• “Internet Group Multicast Protocol (IGMP) Queries” on page 249
• “Configuring a Software Defined Network” on page 253
Virtual LAN Support
This chapter describes support for VLAN and for VLAN-to-VLAN bridging.
Overview
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 mem-
bers of VLAN 1.
NOTE: A port actually can be an untagged member of a single VLAN, and also a tagged mem-
ber 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 single 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 deploy-
ing in route mode (also called “gateway mode”). If you deploy in transparent mode
instead, in which the ACOS device has a single IP address for all data interfaces, Layer 2
forwarding is left enabled by default on VLAN 1.
VLAN-to-VLAN Bridging
Virtual Ethernet Interfaces

On ACOS devices deployed in route mode (Layer 3 mode), you can configure IP interfaces on VLANs. To configure an IP inter-
face 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 3 virtualization (both FPGA and non-FPGA models): 32 VEs on a single port
VLAN-to-VLAN bridging allows an ACOS device to selectively bridge traffic among multiple VLANs. The ACOS device selec-
tively 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).
NOTE: VLAN-to-VLAN bridging is not supported with VRRP-A high availability configurations or
L3V partitions.
Each VLAN to be bridged must be configured on the ACOS device. The normal rules for tagging apply:
*.
An exception is model AX 5200, which supports 384.
• 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.
Each bridge VLAN group can have a maximum of 8 member VLANs. Traffic 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 following 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.
[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 command:
show bridge-vlan-group [group-id]
CLI Example – Transparent Mode
The commands in this section configure an ACOS device deployed in transparent 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
CLI Example – Gateway Mode
The commands in this section configure an ACOS device deployed in gateway 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)#interface ve 1
ACOS(config-if:ve1)#ip address 192.168.1.100 /24
ACOS(config-if:ve1)#exit
Jumbo Frames
The current release adds support for jumbo frames. A jumbo frame is an Ethernet frame that is more than 1522 bytes long.
Support for jumbo frames is offered on Layer 4 VIPs, as well as Layer 7 VIPs that handle application-layer traffic, such as HTTP.
NOTE: In prior ACOS releases, support for jumbo frames was limited to Layer 4 protocols, such
as TCP, but this release expands that support to Layer 7. HTTP is the only Layer 7 protocol
for which jumbo frames are supported.
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.
Notes:
• Jumbo support is disabled by default. You can enable jumbo frame support on a global basis. In this case, the maxi-
mum transmission unit (MTU) is not automatically changed on any of the interfaces and must be explicitly configured
on those that will be used for jumbo frames.
• On FTA models, you can increase the MTU on individual Ethernet interfaces up to 12000 bytes.
• On non-FTA models, you can increase the MTU on individual Ethernet interfaces up to 9216 bytes.
• The Jumbo Frame checkbox that appeared under Config Mode > Network > Interface > Global was deprecated in
this release. Jumbo frame support can only be enabled or disabled at the global config level through the CLI.
• Jumbo frames (L4 and L7) are supported on most 64-bit models and are not supported on 32-bit models.
• If your configuration uses VEs, you must enable jumbo on the individual 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.
• Jumbo support is not recommended on 10/100 Mbps ports.
• On FTA 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 incoming packets to the same value. (This is the max-
imum receive unit [MRU]).
• In previous releases, the default MTU is 1500 and can not be set to a higher value.
• For additional information about which models support jumbo frames, see Table 1 on page 176.
The table below lists the various models and indicates whether the model supports jumbo frames in this release:
TABLE 1 Jumbo Frame support for ACOS models

FTA Model? Model Jumbo Frame support?
Yes. Thunder 6630 Yes
These models feature the Flexible Traf- Thunder 6430 Yes
fic ASIC (FTA).
Thunder 6430S Yes
Thunder 5630 Yes
Thunder 5430S Yes
Thunder 5430-11 Yes
Thunder 5430S-11 Yes
Thunder 4430 Yes
Thunder 4430S Yes
AX 5630 Yes
AX 5200-11 Yes
AX 5200 No
AX 5100 No
AX 3400 Yes
AX 3200-12 Yes
No. Thunder 3030S Yes
These models do not use FTAs. Thunder 1030S No
Thunder 930 No
AX 3530 Yes
AX 3030 Yes
AX 3000-11-GCF Yes
AX 3000 No
AX 2600 No
AX 2500 No
AX 1030 No
Virtual Devices:
vThunder No (except KVM with SR-IOV)
Thunder 3030S HVA Yes
Thunder 3530S HVA Yes
CAUTION: On non-FTA models, after you enable (or disable) jumbo frame support, you must save
the configuration and reboot to place the change into effect.
Configuration
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.
Configuration
Use the following steps to enable jumbo frame support.
NOTE: Jumbo frame support cannot be enabled or disabled at the global level through the GUI
and must be set using the CLI. Once jumbo frame has been globally enabled, you can
use the GUI to explicitly set the MTU on the interfaces where jumbo frames are
expected.
Using the GUI
Changing the MTU on an Interface
To change the MTU on an interface:
2. Click on the interface number, in the Interface column. The configuration page for the interface appears.
3. Edit the value in the MTU field.
4. Click OK.
Disabling Jumbo Support (FTA models)
On each interface with an MTU higher than 1500 bytes:
2. Click on the 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.
Disabling Jumbo Support (non-FTA models)
If you are using a non-FTA 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.
Configuration
5. Repeat for each interface on which the MTU is greater than 1500 bytes.
6. Click Save at the top of the GUI window to save the configuration change.
7. Select Config Mode > System > Settings > Action > Reboot.
CAUTION: On non-FTA 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 (FTA models)
To globally enable jumbo support, enter the enable-jumbo command at the global configuration level of the CLI.
Enabling Jumbo Support (non-FTA models)
If you are using a non-FTA model (see above):
1. Enter the enable-jumbo command at the global configuration level of the CLI.
2. Enter the write memory command to save the configuration.
3. Use the reboot command at the Privileged EXEC level to 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
Create a TCP-proxy Template
To create a TCP-proxy template, use the following command at the global configuration level:
slb template tcp-proxy template-name

mss num
Apply TCP-proxy Template to VIP
To apply the template to a VIP, use the following command at the configuration level for a virtual port on a previously config-
ured VIP:
template tcp-proxy template-name
Disabling Jumbo Support (FTA models)
TO disable jumbo frame support on FTA models:
1. On each interface with an MTU higher than 1500 bytes, enter the no mtu command.
Configuration
2. At the global configuration level of the CLI, enter the no enable-jumbo command.
Disabling Jumbo Support (non-FTA models)
If you are using a non-FTA model:
1. On each interface with an MTU higher than 1500 bytes, enter the no mtu command.
2. At the global configuration level of the CLI, enter the no enable-jumbo command.
3. Enter the write memory command to save the configuration.
4. Use the reboot command at the Privileged EXEC level to reboot.
CAUTION: On non-FTA 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:
ACOS(config-if:ethernet15)#mtu 6000
ACOS(config-if:ethernet15)#interface ethernet 16
ACOS(config-if:ethernet16)#mtu 6000
ACOS(config-if:ethernet16)#vlan 300
ACOS(config-vlan:300)#tagged ethernet 15 to 16
ACOS(config-vlan:300)#router-interface ve 300
ACOS(config-vlan:300)#interface ve 300
ACOS(config-if:ve300)#mtu 6000
ACOS(config-if:ve300)#exit
ACOS(config)#slb template tcp-proxy jumbo_TP
ACOS(config-tcp proxy)#mss 8960
ACOS(config-tcp proxy)#exit
ACOS(config)#slb virtual-server IPV4_VIRTUAL_SERVER 192.168.255.2
ACOS(config-slb vserver)#port 80 http
ACOS(config-slb vserver-vport)#service-group IPV4_HTTP_SERVER
ACOS(config-slb vserver-vport)#template tcp-proxy jumbo_TP
The following commands show detailed information for the interfaces, which includes the MTU settings:
ACOS(config-if:ve300)#show interface ve 300

VirtualEthernet 300 is down, line protocol is down
Hardware is VirtualEthernet, Address is 001f.a005.53e6
Configuration

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
ACOS(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
ACOS(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
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 providing 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 pro-
vided by the multiple links in the trunk. If an individual port in the trunk goes down, the trunk link continues 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. On the A10
Thunder Series 6430(S) device, up to 16 port members can be configured per static or dynamic trunk.
• 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 Ethernet data ports.
Using the GUI

To configure a static trunk:
1. Go to Config Mode > Network > Trunk.
2. Click Add to create a static trunk.
The following window appears:
3. Indicate a Trunk ID from 1-4096.
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 number 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 threshold is not met. You can
set the ports-threshold timer to 1-300 seconds. 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 along with a trunk ID of 1-4096 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 for-
warding 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 disable 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 disable 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 command 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 disabled 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 auto-
matically 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 disabled 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
Enter this command at the global configuration level of the CLI. This command changes the CLI to the interface configura-
tion 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 con-
trol all forwarding on the trunk, use the disable or enable command at the trunk con-
figuration 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
Dynamic Trunk Configuration
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 inter-
face:
ACOS(config)#interface trunk 7
ACOS(config-if:trunk7)#ipv6 address 2001:db8::7/32

Link Aggregation Control Protocol (LACP) dynamically creates trunk links.
The ACOS implementation of LACP is based on the 802.3ad IEEE specification.
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 settings on the device with the
higher priority are used.
You can specify 1-65535. A low priority number indicates a high priority 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 configured 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 con-
figured 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 formation 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 1-4096.
• 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
interface goes down.
You can specify 1-65535. A low priority number indicates a high priority 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 Passive Mode. The Active mode initiates link forma-
tion 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 initiate 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 187.)
UDLD
When UDLD is enabled, the UDLD uses LACP protocol packets as heartbeat 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 prob-
lem 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 timeout). 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 establish 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
Configure the global LACP parameter:
1. Go to Config Mode > Network > Interface > LAN.
2. Choose an Ethernet number
This will cause the interface configuration page to appear.
3. Scroll down and click on the LACP tab.
4. Enter the Trunk ID.
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.
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 operational members of a trunk goes below the config-
ured 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 following.
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 Adminis-
tration Guide.
1. Go to Config Mode > Network > Trunk.
The following window will appear:
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 dis-
played for informational purposes only. If you want to add any interfaces to this LACP trunk, you must add these inter-
faces from the System > LAN > Interfaces 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 number 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 threshold is not met. You can
set the ports-threshold timer to 1-300 seconds. 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 following 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 com-
mand:
[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 command:
[no] lacp udld-timeout {fast | slow} num
You can specify fast (100-1000 milliseconds) or slow (1-60 seconds). The default is slow 1.
Configuring LACP
1. (Optional) Set the LACP system priority, using the following command at the global configuration level of the CLI:
[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 con-
figuration 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 thresh-
old 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
Enter this command at the global configuration level of the CLI. This command changes the CLI to the interface configura-
tion 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 con-
trol all forwarding on the trunk, use the disable or enable command at the trunk con-
figuration 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 1 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 con-
nected 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
On each ACOS device, the following LACP tunnels are configured:
• Ethernet ports 5 and 6
LACP Passthrough
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 connections 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 Ethernet (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” on page 137.)
• Similarly, the nexthop devices that connect the ACOS device to the clients 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.
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 Monitoring” on page 137.)
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 lacp-passthrough command at the global configuration level of the CLI.
To display LACP information, use the show lacp commands:
• Use the show lacp sys-id 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.
LACP Passthrough
• Use the show lacp counter command to display statistics.
• Use the show lacp trunk command to show configuration and status information for LACP.
To clear LACP statistics counters, use the clear lacp commands at the Privileged EXEC level of the CLI.
The following CLI example enables LACP on physical Ethernet data ports 1-3 and 6.
The following commands configure LACP parameters on the ports:
ACOS(config-if:ethernet1)#lacp trunk 5 admin-key 10001 mode active
ACOS(config-if:ethernet1)#lacp timeout long
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
The following commands configure LACP passthrough between interfaces 6 (connected to client) and 5 (connected to
server), and between interfaces 10 and 9:
ACOS(config)# lacp-passthrough ethernet 6 ethernet 5

ACOS(config)# lacp-passthrough ethernet 10 ethernet 9
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
LACP Passthrough
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

LACP Passthrough
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
LACP Passthrough
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
LACP Passthrough

!
slb template monitor 2
monitor-or
!
Monitor template 1 monitors for link-down events on Ethernet data interfaces 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 interfaces 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

LACP Passthrough
Link Layer Discovery Protocol
The Link Layer Discovery Protocol (LLDP) enables network devices to advertise their identity, capabilities, and neighbors on
the network. This feature is based on the IEEE 802.1AB standard.
This chapter contains the following topics:
• Overview of LLDP
• Configure LLDP
Overview of LLDP
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 identifies the kind of information that is
transmitted, length contains the string of octets, and value is the actual content that is being transmitted. The mandatory
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 immediately. As the name suggests, the
End of LLDP data packet indicates that completion of the LLDP packet.
Configure LLDP
Configure LLDP
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

To enable the LLDP feature via the CLI, enable the feature from the global level:
ACOS(config)#lldp enable rx tx
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
Configure LLDP
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
Configure LLDP
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 Command Line Interface Reference.
NOTE: It is recommended to set a fixed router-ID for all dynamic routing protocols you plan to
use on the ACOS device, to prevent router-ID changes caused by HA or VRRP-A failover.
• Support for Multiple OSPFv2 and OSPFv3 Processes
• Support for OSPFv2 and OSPFv3 on the Same Interface or Link
• OSPF MIB Support
• OSPF Configuration Example
• Configuring OSPF-Related HA Parameters
• OSPF Logging
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
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
ipv6 router ospf area 0 tag 1
!
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 neighbors.
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 process to run on the device, and can be 1-65535.
• process-tag—The process-tag specifies the IPv6 OSPFv3 process 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 interface name for a specific neighbor.
Use the following commands to effect changes to clear OSPF neighbor information. To clear all neighbors, issue the follow-
ing 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:
clear ipv6 ospf [process-tag] neighbor interface-name
To clear all neighbors on a specified interface to a specific router:
clear ipv6 ospf [process-tag] neighbor interface-name neighbor-router-id
Configuration Examples
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 specified 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
Configuring OSPF-Related HA Parameters
Configuring OSPF-Related HA Parameters

The following sections describe how to configure OSPF-related HA parameters.
OSPF Awareness of HA
The ACOS device uses HA-aware VIPs, floating IPs, IP NAT pools, and IP range lists with route 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, following HA failover of an ACOS device, other OSPF routers might continue for-
warding 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 213.)
You can assign an additional cost to an ACOS device’s OSPF interfaces when the HA status for any group on the device is
Standby. If failover of one or more HA groups from Active to Standby occurs, the ACOS device does the following:
• Updates the cost of all its OSPF interfaces
• Sends Link-State Advertisement (LSA) updates to its OSPF neighbors advertising the interface cost change
After an OSPF neighbor receives the LSA update, the neighbor updates its OSPF link-state database with the increased cost
of the links. The increased cost biases route selection away from paths that use the Standby ACOS device.
Similarly, if a failover results in HA status Active for all HA groups on an ACOS device, the device removes the additional cost
added for Standby status from all its OSPF interfaces and sends LSA updates to advertise the change. The reduced cost
biases route selection toward paths that use the Active ACOS device and away from paths that use the Standby ACOS device.
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 addi-
tional cost remains in effect for all OSPF interfaces on the device.
Enabling OSPF Awareness of HA
To enable OSPF awareness of HA, use the following command at the OSPF configuration level.
[no] ha-standby-extra-cost num
The num option specifies the extra cost to add to the ACOS device’s OSPF interfaces, if the HA status of one or more of the
device’s HA groups is Standby. You can specify 1-65535. If the resulting cost value is more than 65535, the cost is set to 65535.
Enter the command on each of the ACOS devices in the HA pair.
OSPF Logging
OSPF Support on Standby ACOS Device in Layer 3 Inline Mode

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

To enable output to the terminal, use the following command at the global configuration level of the CLI:
router log stdout
To enable output to the local logging buffer, use the following command at the global configuration level of the CLI:
OSPF Logging
router log syslog
To enable output to a local file, use the following command at the global configuration level of the CLI:
[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 global configuration level of the CLI:
logging host ipaddr [ipaddr...]

[port protocol-port]
Up to 10 remote logging servers are supported.
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 con-
figuration 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 configu-
ration level of the CLI:
logging syslog severity-level
OSPF Logging
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 configuration level of the CLI:
logging facility facility-name
The facility-name can be one of the following:
• local0
• local1
• local2
• local3
• local4
• local5
• local6
• local7
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 network parameters.
• packet – Enables debugging for OSPF packets.
• route – Enables debugging for OSPF routes.
For each level, both debug commands are required.
OSPF Logging
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-protocol option will log messages for each routing pro-
tocol 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
OSPF Logging
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
...
OSPF Logging
Border Gateway Protocol (BGP)
The ACOS device supports the following BGP versions:
• BGP4+ for IPv4
• BGP4+ for IPv6
This chapter provides configuration examples. For detailed CLI syntax information, see the CLI Reference.
NOTE: It is recommended to set a fixed router-ID for all dynamic routing protocols you plan to
use on the ACOS device, to prevent router-ID changes caused by HA or VRRP-A failover.
BGP Route Redistributions

The routers in a BGP autonomous system (AS) advertise their routes to other BGP speakers (either internally or externally)
through updates exchanged during peering sessions. These updates, or BGP route redistributions, can be used to distribute
information about the topology and metrics for the neighboring routers.
The route redistributions can be for either static routes, which are manually-configured by an admin, or the route redistribu-
tions can be for dynamic routes that the router has acquired through the normal operation of the BGP protocol, such as
routes learned through BGP peering sessions with other routers.
Using BGP Route Maps to Permit or Deny Updates

A BGP route map functions much like a filter. Route maps offer a way to permit or deny the exchange of information to
neighboring BGP peers, and route maps can be used by network administrators to reduce the amount of information that is
exchanged during BGP peering sessions. (Without route maps, every router on the Internet would share all of its information
about every other router to which it is connected, and the sheer volume of traffic would bring the Internet to a grinding halt,
so route maps offer a way to throttle the amount of information that is shared among BGP peers.)*
Route maps are configured with one or more rules. Each rule consists of a set of match criteria and an associated action (per-
mit or deny). The route map can have multiple rules, which are categorized in ascending order. Once the BGP route map is
placed into action, it can be used to filter inbound or outbound routing traffic. If traffic is received and there is a positive
*.
BGP route summarization, or route aggregation, offers another way to reduce the number of routes that are shared by consolidating
blocks of IP addresses before redistribution. This prevents excessive fragmentation of blocks of IP addresses and gives ISPs more con-
trol over the blocks of IP addresses they own. Route aggregation also helps to conserve the precious IPv4 addresses.
Using BGP Route Maps for Traffic Engineering
match for the criteria in one of the rules, then the action associated with that match criteria will be applied. Assuming the
associated action is to alter the local preference for routes from that peer, then ACOS will make this change before redistrib-
uting these route to other BGP peers.
Using BGP Route Maps for Traffic Engineering

The rules in the route map are not just used to “permit” or “deny” peering sessions in the binary manner described above.
Route maps can also be used for “traffic engineering”. This is accomplished by modifying the information a BGP speaker
receives from other BGP peers before the altered information is propagated via the route redistribution process. In other
words, route maps can be configured to modify the properties of the routing information they receive before sending that
modified data on its way.
For example, if you know that a neighboring autonomous system has old equipment that could impede or slow your com-
pany’s traffic, it might be beneficial if you could administratively tell the equipment in your autonomous system to avoid that
other network.
Route maps allow you to accomplish this goal by rewriting the properties or metrics associated with the paths to this other
network.
You could set up one or more match criteria to identify traffic from this slower and older network, and if there is a positive
match, you could increase the cost or decrease the weight for the paths to this other network in order to bias traffic toward
other paths and other BGP peers in the network.
In this way, ACOS does not flat-out refuse to accept the route redistributions it receives from the BGP peers within this slower
network, but rather than accepting the routing information at face value, ACOS “tweaks” or rewrites the metrics associated
with these paths to make them less attractive before passing them along to the surrounding BGP peers.
Route Selection Based on Local Preference

ACOS 2.7.2 allows you to use the local preference as a match criteria in a route map. While vetting route updates, if there is a
positive match for the criteria, this triggers an action associated with the match criteria and helps determine whether BGP
updates will be sent to one or more BGP peers.
A route map acts as a filter for the redistribution of BGP routes sent to peers. Rules are set up within the route map, consisting
of match criteria (the metric upon which we are searching) and an associated action (for example, setting the local prefer-
ence value). If a positive match is found then the action associated with that rule is applied.
For example, you could set a rule within a route map to look for updates from a particular BGP peer (based on IP address,
router , or perhaps all routers in a particular Autonomous System Number), and you could then prevent ACOS from propa-
gating, or redistributing, these updates to the other BGP peers in its ASN.
Instead of completely blocking routing updates from a nearby ASN, you could specify an action within the route map that
would modify the various metrics to make the associated paths less preferred. For example, if you knew that a particular BGP
peer is an older router that could hinder network performance, you could increase the cost of the paths to/from that router
by increasing the cost of those paths by increasing the metric number. Similarly, you could achieve the same goal (of reduc-
ing the attractiveness of the paths associated with this older router and thus directing traffic away from it) by decreasing the
weight for routes learned from this router.
Globally-Enabled Default Route Origination
Using the GUI

BGP configuration is not supported in the GUI.
Using the CLI

To use the local preference as a filter parameter, use the following command at the configuration level for the route map:
[no] match local-preference num
The num value can be 0-4294967295. There is no default. For a positive match to occur, there must be an exact match upon
the specified number.
CLI Example
The following commands configure a route map called “RED”. The sequence number for this route-map is “10”. The rule
looks for route updates that have a local preference value of exactly 5000. If a match occurs, then the action for this route
map is to “permit” BGP updates to occur with this router.
ACOS(config)#route-map RED permit 10

ACOS(config-route-map)#match local-preference 5000
At this point, you could apply the route map to an ACOS device that has BGP enabled. You could specify the AS that this
ACOS device belongs to (“333”), the BGP neighbor (10.1.1.1), the name of the route map (“RED”), and specify whether
this route map is affecting inbound or outbound route updates (in), as shown in the sample commands below.
router bgp 333

redistribute dynamic
neighbor 10.1.1.1 remote-as 333
neighbor 10.1.1.1 route-map RED in
Globally-Enabled Default Route Origination

When you are in router BGP mode, the default-information originate CLI command is available to advertise the default
route.
Use the GUI to Configure Globally-Enabled Default Route Origination

BGP configuration is not supported in the GUI.
Use the CLI to Configure Globally-Enabled Default Route Origination

To configure a BGP routing process to distribute a default route, use the default-information originate command in the
address family or router configuration mode. A valid default route must exist and be verified to complete this configuration
or the default route will not be advertised:
ACOS(config)#router bgp 10
ACOS(config-route)#default-information originate
Equal-Cost Multi-path ECMP Support

ACOS 2.7.2 enables equal-cost multi-path (ECMP) support for BGP. By default, ECMP support is disabled. You can enable sup-
port for up to 10 equal-cost paths per route destination. Traffic to the destination prefix is then shared across all the installed
paths.
Based on your configuration, BGP will install up to the maximum number of routes in the forwarding information base (FIB).
Using the GUI

This feature is currently not supported in the GUI.
Using the CLI

Use the following command at the BGP configuration level to specify the maximum number of ECMP paths to a given route
destination allowed for BGP:
[no] maximum-paths path-num
In the above command, the option path-num can take on a value from
2-10 paths.
The default maximum-path value is 1. This value will not be displayed in the show running command. With the default set-
ting (maximum-paths 1), BGP will install the single best ECMP route into the FIB used by the ACOS device to forward traffic.
Use the following two commands to display BGP ECMP-related information.
• The show ip bgp command shows the routes are marked as BGP ECMP routes.
• The show ip fib command shows the ECMP routes installed and used by the device to forward traffic.
The example below shows the BGP portion of an ACOS device configuration. The new maximum-paths command shown
in bold. The first set of output shows a device running IPv4 while the second set of output shows a device running IPv6. In
the IPv4 output, the lines of output “neighbor 10.10.10.197 remote-as 197” through “neighbor
60.60.60.197 remote-as 197” show that the ACOS routing engine learned of this route from multiple neighbors.
ACOS#show run
router bgp 100
bgp router-id 100.100.100.100
maximum-paths 8 <---------------------- new maximum ECMP paths command
neighbor 3310::197 remote-as 197

ACOS#show run
address-family ipv6
maximum-paths 7 <---------------------- new maximum ECMP paths command
neighbor 3310::197 activate
exit-address-family
The show ip fib command shows that the ACOS device’s forwarding information base (FIB) was able to learn of 6 different
routes to the same destination (7.7.7.0/ 24). Each route had an equal cost (distance = 20), and each route was learned
through a different Ethernet port.
ACOS#show ip fib
Prefix Next Hop Interface Distance
------------------------------------------------------------------------
7.7.7.0 /24 60.60.60.197 ethernet6 20
7.7.7.0 /24 50.50.50.197 ethernet5 20
7.7.7.0 /24 40.40.40.197 ethernet4 20
7.7.7.0 /24 30.30.30.197 ethernet3 20
7.7.7.0 /24 20.20.20.197 ethernet2 20
7.7.7.0 /24 10.10.10.197 ethernet1 20
The show ip bgp command displays paths learned through BGP. The ACOS device was connected to 6 different routes, and
the Metric column shows that the cost is the same for all routes.
ACOS#show ip bgp
BGP table version is 14, local router is 98.98.98.98
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path

*> 7.7.7.0/24 10.10.10.197 0 0 197 ?
*m 20.20.20.197 0 0 197 ?
*m 30.30.30.197 0 0 197 ?
*m 40.40.40.197 0 0 197 ?
BGP Support with HA and VRRP-A
*m 50.50.50.197 0 0 197 ?
*m 60.60.60.197 0 0 197 ?
The show ip route database command displays essentially the same information as shown above. The ACOS device has a
FIB that is populated with 6 different routes, of equal cost, to the same destination.
ACOS#show ip route database

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
> - selected route, * - FIB route, p - stale info
B *> 7.7.7.0/24 [20/0] via 10.10.10.197, ethernet 1, 00:13:38

*> [20/0] via 20.20.20.197, ethernet 2, 00:13:38
*> [20/0] via 30.30.30.197, ethernet 3, 00:13:38
*> [20/0] via 40.40.40.197, ethernet 4, 00:13:38
*> [20/0] via 50.50.50.197, ethernet 5, 00:13:38
*> [20/0] via 60.60.60.197, ethernet 6, 00:13:38

This section contains the following topics:
• Matching on VRRP-A VRID or HA Group Status
• Tracking the BGP State Using HA or VRRP-A
Matching on VRRP-A VRID or HA Group Status

ACOS 2.7.2 provides a new route-map option that performs matching on the VRRP-A VRID or HA group, and on whether the
device is the active or standby in the pair. The new option may be used to control BGP route redistribution and advertise-
ment decisions based on the ACOS device’s HA state.
In previous releases, a route map could perform filtering based on metrics such as BGP community, IP address, or metric
value. However, this is the first ACOS release in which filtering (or matching) can be performed based on the HA/VRRP-A and
status of an ACOS device that is in a high availability paired configuration.
This new mechanism can be useful in certain network environments, such as if a network environment uses HA or VRRP-A for
redundancy, and the active ACOS device in the pair is to be upgraded. Such an upgrade requires the active ACOS device to
change its status to standby, and the standby device must become the active load balancer.
In this common scenario, this ability to perform route map matching based on HA status offers a unique way to use BGP
route redistribution to advertise the paths to the newly-active ACOS device after the HA switchover has occurred.
You can use the BGP protocol to modify some of the route settings by way of the route map. By changing the weights or
local preference of certain routing paths, you can influence the routes that are advertised or withdrawn in route updates
from the ACOS device to its BGP neighbors.
Alternatively, you can just wait for the old routes to time out and be automatically withdrawn from the routing table of the
neighboring routers. This will also result in the network traffic being guided to the new active ACOS device.
Figure 2 shows a hypothetical network topology, which is based on the use case scenario presented in the overview at the
beginning of this section. This network diagram has two ACOS devices, which are using VRRP-A for redundancy. Here are a
few other noteworthy points:
• The leftmost ACOS device is Active and the rightmost ACOS device is Standby.
• The diagram shows two Layer 3 routers above the ACOS devices, which are using BGP to perform updates and to
share routing information with the ACOS load balancers (which are also running BGP).
• Static routes connect the ACOS devices to a Layer 3 router, which directs traffic to/from the real servers.
FIGURE 2 Topology using BGP route map (with HA matching)
In a network environment like that shown above in Figure 2 on page 226, in order to upgrade the Active ACOS device, it
must be relegated to “standby” mode. The Standby device must also be made “active”. When this switchover occurs, it is
imperative that the routers running BGP receive updated routing information. This updated routing information will cause
the routes to the formerly-active ACOS device to be avoided, and the routers must also be provided with new routing infor-
mation about the paths traffic can use to reach the newly active ACOS device.
Using the GUI

Using the CLI

The following gives an example of a route map configuration. It is based on the network diagram shown in Figure 2 on
page 226, which has two ACOS devices using VRRP-A for redundancy. To upgrade the active ACOS device, its status must be
changed to standby (and the standby device must be made active). Then, the routing information must be pushed to the
two routers running BGP.
Configurations on the Active ACOS device
The CLI commands below are used to configure VRRP-A on the first (Active) ACOS device.
vrrp-a device-id 1
vrrp-a set-id 1
vrrp-a enable
The following CLI commands assign an IP address of 20.1.1.1 to Ethernet interface 1 on the ACOS device.
interface eth 1
ip address 20.1.1.1
The following CLI commands are used to create a route map called “test1” with a sequence number of 10. A rule is added
that checks for a positive match for the active ACOS device in the HA (or VRRP-A) group 1. If a positive match is found, then
this ACOS device can share its route redistributions with any BGP peers that pass the match criteria.
route-map test1 permit 10

match group 1 active
The following CLI commands are used at the global configuration level to enable the BGP protocol and specify the Autono-
mous System (AS) number of “100” for the Active ACOS device. The outbound redistribution of static routes would be
allowed to the BGP peer at 30.1.1.1, based upon the match criteria (and associated actions) in the route-map called “test1”.
router bgp 100

redistribute static
neighbor 30.1.1.1 route-map test1 out
The following CLI commands are used to configure a static route from the Active ACOS device to the router below, which
leads to the real servers.
ip route 11.1.1.1 /24
Configurations on the Standby ACOS device
The configurations below are used to configure VRRP-A on the Standby ACOS device.
vrrp-a device-id 2
vrrp-a set-id 1
vrrp-a enable
The following CLI commands are used to assign the IP 21.1.1.1 to Ethernet interface 1 on the Standby ACOS device.
interface eth 1
ip address 21.1.1.1
The following CLI commands are used to create a route map called “test1” with a sequence number of 10. A rule is added
that checks for a positive match for the active ACOS device in the HA (or VRRP-A) group 1. If a positive match is found, then
this ACOS device can share its route redistributions with any BGP peers that pass the match criteria.
route-map test1 permit 10

match group 1 active
The following CLI commands are used at the global configuration level to enable the BGP protocol and specify an Autono-
mous System (AS) number of “100” for the Standby ACOS device. The outbound redistribution of static routes could be sent
to the BGP peer at 40.1.1.1, based upon the match criteria (and associated actions) in the route-map called “test1”.
router bgp 100

redistribute static
neighbor 40.1.1.1 route-map test1 out
The following CLI commands are used to configure a static route from the Standby ACOS device to the router below, which
leads to the real servers.
ip route 12.1.1.1 /24
NOTE: In the above configuration, only an Active ACOS device can redistribute its static routes.
The Standby ACOS device does not redistribute its static routes. The reason for this is
that the match criteria “permits” the Active device in an HA (or VRRP-A) pair to send out
(redistribute) its routes. There is no rule in the route map with an explicit “deny” action,
but the deny is implicit, because any Standby HA devices would fail to match the criteria
in the route map, so the Standby HA device would fail to match the criteria and its rout-
ing updates would not be shared.
Tracking the BGP State Using HA or VRRP-A

In a typical example topology, two VRRP-A devices, Device 1 and Device 2, are configured in a BGP environment. Device 1
announces its prefixes to the peer, and Device 2 does not announce anything.
If Device 1 fails, the virtual IP address (VIP) route stays in the routing table until Device 2 announces the VIP by using BGP or
until the router times out the Device 1 peer and deletes all of the relevant prefixes. If the VIP route stays in the routing table,
Device 2 becomes the VRRP-A active device.
When Device 1 is active again, and becomes the VRRP-A owner, the following situations might occur:
• Device 1 takes VRRP-A ownership before BGP is in the Established mode and announces the prefixes.
• Device 2 becomes the VRRP-A slave and sends a BGP Update message to withdraw the VIP route.
To resolve this issue, you can complete the following tasks:
• Track the BGP state by using VRRP-A.
• Set a time that the device waits until it sends the BGP Withdraw message when VRRP-A fails back to the main device.
• Announce the prefixes even when the device is a VRRP-A slave.
NOTE: To determine which device is active, the ACOS devices will first compare the weight of
the devices. If the weight is same, then the priority of the devices is compared. These
comparisons determine which device will be the active device. The weight, which is
configured under vrrp-a fail-over template, is like priority-cost. If you apply a
fail-over template to a VRID, the weight of the VRID drops the configured value when
tracking fails.
You can configure the same weight and tracking value for both devices. The weight is the priority value for tracking options.
The priority-cost value means that when tracking fails, the priority of the virtual router identifier (VRID) will drop the config-
ured value.
Using the GUI

This feature cannot be configured by using the GUI.
Using the CLI

This example shows how to add tracking options for the BGP status in a VRRP-A VRID.
The following is an example of configuring the fail-over-policy template:
ACOS(config)#vrrp-a fail-over-policy-template A
ACOS(config-failover-policy)#bgp 1.1.1.2 weight 200
ACOS(config-failover-policy)#exit
The following is an example of configuring the tracking-option under VRID:
ACOS(config)#vrrp-a vrid default

ACOS(config-vrid-default)#priority 200
ACOS(config-vrid-default)#fail-over-policy-template A
ACOS(config-vrid-default)#tracking-options
ACOS(config-vrid-tracking)#bgp 1.1.1.2 priority-cost 100
ACOS(config-vrid-tracking)#
To compare with the VRID weight:
Device 1 (Active):
vrrp-a device-id 1
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid default
priority 200
tracking-options
bgp 1.1.1.2 priority-cost 100
Device 2 (Standby):
vrrp-a device-id 2
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid default
priority 180
To compare with the VRID priority:
Device 1 (Active):
vrrp-a device-id 1
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid default
priority 200
Device 2 (Standby):
vrrp-a device-id 2
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid default
priority 180
Bidirectional Forwarding Detection
Bidirectional Forwarding Detection (BFD) provides very fast failure detection for routing protocols. When BFD is enabled, the
ACOS device periodically 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 recalcu-
lates 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 tim-
ers 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 following BFD support is provided:
• 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 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 settings 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 loopback 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.
Configuring BFD
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
Configuring BFD
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 configuration 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 command at the BGP configuration level:
[no] neighbor ipaddr fall-over bfd [multihop]
To display BFD information for BGP neighbors, use the following command:
show ip bgp neighbor
Configuring BFD
Displaying BFD Information

To display summarized BFD neighbor information, use the following command:
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 commands:
Configuring BFD
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 configuration:
!
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:

ACOS(config-if)#ipv6 address 2001::1/64
ACOS(config-if)#ipv6 router ospf area 0 tag 1
ACOS(config-if)#ipv6 ospf bfd
Configuring BFD

ACOS(config-if)# ipv6 ospf bfd
ACOS(config-if)#ipv6 ospf bfd
To enable BFD for all OSPFv3-enabled interfaces, enter the following commands:
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
!
Configuring BFD
Configure BFD with IS-IS (for IPv4)

To enable BFD with ISIS on an interface, enter one of the following sets of commands:
ACOS(config-if)#ip address 20.0.0.1 255.255.255.0
ACOS(config-if)#ip router isis
ACOS(config-if)#isis bfd
To enable BFD for all IS-IS-enabled interfaces, enter the following commands:
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 configuration:
!
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
Configuring BFD
!
!
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:
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 commands:
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
!
Configuring BFD
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 configuration:
!
router bgp 1
neighbor 1.2.3.4 fall-over bfd multihop
!
!
bfd enable
!
Configuring Static BFD

The following sections describe how to configure global IPv4 static BFD and both global and link-local IPv6 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 gate-
way for the static route.
IPv6 Static BFD (Global)

From the global configuration mode, use the following command to add a static BFD entry for the specified IPv6 nexthop:
ACOS(config)# ipv6 route static bfd 2001::1 2001::2
Configuring BFD
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 gate-
way for the static route.
IPv6 Static BFD (Link-Local)

From the global configuration mode, use the following command to add a 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.
Configuring 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 multiplier 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 modify the interface interval timer values:
ACOS(config-if)# bfd interval 500 min-rx 500 multiplier 4
NOTE: For a BFD session for BGP using a loopback address, for an OSPFv2 virtual link, and for an
OSPFv3 virtual link, the ACOS device will always use the global timer configuration,
immaterial of the timer that is configured at the interface level.
Configuring BFD
Enable 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) configuration 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:
Viewing BFD Status
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 inde-
pendently 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 connected 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.
For more information about the output and the fields in the output, see “show bfd” in the Command Line Interface Refer-
ence.
BFD Detailed Output

To check the BFD neighbor detailed status, from the EXEC mode, execute the show bfd neighbors detail command.
For more information about the output and the fields in the output, see “show bfd” in the Command Line Interface Refer-
ence.
Viewing BFD Statistics

Use the show bfd statistics command to view BFD statistics. For more information about the output and fields, see
“show bfd statistics” in the Command Line Interface Reference.
Dynamic Host Configuration Protocol (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.
• Virtual ethernet interfaces – Multiple IP addresses can be assigned.
• Trunk 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 combination 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 vThunder 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.
Configuring DHCP
Using the CLI
To enable DHCP on an interface, use the ip address dhcp command at the configuration level for the interface:
DHCP Relay
DHCP Relay
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 clients 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 packet to the server. When the DHCP server replies, the ACOS device forwards the response to the
client.
Notes
• 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 interface or an IP address used for SLB.
Configuring DHCP Relay

To configure DHCP relay, use the CLI.
NOTE: Two IP helper addresses per Ethernet interface can be configured.
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
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
Refer to “show ip helper-address” in the Command Line Interface Reference for information about the fields in this output.
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
DHCP Relay
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
IP Interface: ve7
------------
Helper-Address: None
Packets:
RX: 14
TX: 14
No-Relay: 0
Drops:
Invalid Dest IP : 0
Exceeded TTL : 0
Refer to “show ip helper-address” in the Command Line Interface Reference for information about the fields in this output.
DHCP Relay
The following command clears the DHCP relay counters:
ACOS#clear ip helper-address statistics
DHCP Relay
Internet Group Multicast Protocol (IGMP) Queries
The current implementation of the ACOS software supports the generation of generic Internet Group Multicast Protocol ver-
sion 2 (IGMPv2) membership query requests. The A10 Thunder™ and ACOS devices will now generate 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 Listener 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 possible.
• 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 3 IGMP Membership Queries (Routed and Non-Routed Mode)
In Routed Mode
In Figure 3, 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 interface is in routed mode, the device can be configured to generate IGMPv2 membership queries out
of this interface. However, when an IGMP membership query is received on an interface in routed mode, it will be ignored.
In Non-Routed Mode
In Figure 3, 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 config-
uration level. Use the following 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 feature) 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 indicate 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:
ACOS(config-if)#interface ethernet 2
ACOS(config-if:ethernet2)#ip address 192.168.1.1 /24
ACOS(config-if:ethernet2)#ip igmp generate-membership-query 10 max-resp-time 50
To view your IGMP membership request query configuration for a a physical interface, do the following:
ACOS(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:
ACOS(config)#vlan 50
ACOS(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:
ACOS(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 following:
ACOS(config)#trunk 2
ACOS(config-trunk:2)#ethernet 2
ACOS(config-trunk:2)#exit
ACOS(config-if:trunk2)#enable
ACOS(config-if:trunk2)#ip address 11.11.11.219 /24
ACOS(config-if:trunk2)#ip igmp generate-membership-query 20 max-resp-time 80
ACOS(config-if:trunk2)#exit
To view your IGMP membership request query configuration for a trunk, do the following:
ACOS(config)#show interfaces trunk 2

Trunk 2 is up, line protocol is up
Hardware is TrunkGroup, Address is 001f.a004.2e71

Configuring a Software Defined Network
This chapter describes how to configure and monitor overlay tunnels to create a Software Defined Network (SDN). It contains
the following sections:
• Understanding Overlay Networks
• Understanding Packet Encapsulation and Transport
• Configuring a Sample Topology
• Notes about the Current Implementation
Understanding Overlay Networks

An overlay network is a virtual network built on top of an existing physical network in order to introduce a service that is not
available in that existing network. The overlay network uses virtual links to connect various nodes of the existing physical
network. Virtual network traffic is then tunneled across the network using technologies like VXLAN (Virtual Extensible LAN)
and NVGRE (Network Virtualization using Generic Routing Encapsulation).
Both VXLAN and NVGRE serve to connect multiple Layer 3 networks and give the appearance that they all share the same
Layer 2 domain.
Consider the illustration in Figure 4:
FIGURE 4 Overlay Network
Understanding Packet Encapsulation and Transport
Host C, Host S and a Thunder Appliance are connected to each other through an overlay or tenant network. Packets are sent
through the existing underlay or provider network (labeled “L2/L3 Network”), but the tunnel endpoints in the overlay are
responsible for properly encapsulating and decapsulating packets; the configuration of the underlay network remains
unchanged.
The tunnel endpoints mark the edge of the overlay network, and the virtual servers and clients represent portions of the net-
work being extended on top of the overlay network.
The virtual appliances behind each tunnel endpoint are grouped together by segment. Each segment is uniquely identified
by a 24-bit segment identifier; VXLAN calls this a VXLAN Network Identifier (VNI), and NVGRE refers to this as a Virtual Subnet
Identifier (VSID). All virtual machines on a segment are uniquely identified by their VNI/VSID and MAC address, and only vir-
tual machines on the same VNI/VSID are able to communicate with each other. In the example above, the servers and clients
in segment 100 can communicate with each other through the overlay tunnel; however, they are not able to communicate
with the servers and clients in the other segments.
Some addressing benefits of such a topology are summarized below:
• Isolated end-to-end network domains for tenants
Because the segments are uniquely identified and isolated form each other, each network domain (segment) is able to
be configured for specific needs (for example, network traffic, network security, bandwidth, or other specialized poli-
cies).
• IP addresses, MAC addresses, and VLANs can be reused across tenants
Also because of the network (segment) isolation described above, it is possible to have duplicate IP addresses, MAC
addresses, and VLANs across different segments, but not within the same segment.
• Tenant addressing is de-coupled from physical network addressing
The physical underlay network addressing and configuration are not modified. Encapsulated packets travel through the
overlay network via the tunnel endpoints, and only pass through the existing physical underlay network. Thus, the only
network addressing configuration that needs to be performed is in the overlay network.
• Lower overhead within the existing physical network.
• Scaling benefits - a high number of virtual networks can be configured, compared to VLANs
Both VXLAN and NVGRE insert a new 24-bit identifier (VNI for VXLAN, or VSID for NVGRE) into each IP packet, meaning
that over 16 million L2 logical networks can be created, compared to the 4,094 limit with traditional VLANs.
• Provides MAC addresses table scaling in the physical network

This section contains the following:
• Understanding VXLAN Encapsulation
• Understanding NVGRE Encapsulation
• Understanding Fragmentation of Tunneled Packets
Understanding VXLAN Encapsulation

In a VXLAN network, Layer 2 packets are tunneled over a Layer 3 network using UDP/IP over IP frames, as shown in Figure 5.
FIGURE 5 VXLAN Packet Encapsulation
Table 2 describes the various fields in the VXLAN encapsulation.
TABLE 2 VXLAN Packet Encapsulation

Field Description
Outer MAC Header Contains the following:
• Destination MAC address (48 bits)
• Source MAC address (48 bits)
• VLAN type set to 0x8100 (16 bits)
• VLAN ID (16 bits)
• Ethertype of 0x0800 to designate the payload as an IPv4 packet (16 bits)
Outer IP Header Contains the following
• IP header miscellaneous data (72 bits)
• Protocol set to 0x11 to indicate UDP (8 bits)
• Header chksum (16 bits)
• Source IP address of the originating VTEP (32 bits)
• Destination IP address of the target VTEP (32 bits)
Outer UDP Header Contains the following:
• Source port (16 bits)
• VXLAN port (16 bits)
• UDP length (16 bits)
• UDP checksum (16 bits)
VXLAN Header Contains the following
• VXLAN flags. Reserved bits set to zero except for the third bit, which is set to 1 to indi-
cate a valid VNI. (8 bits)
• VNI (24 bits)
• Two sets of fields, 24 bits and 8 bits, that are reserved and set to zero.
Understanding NVGRE Encapsulation

NVGRE packets are tunneled directly over IP (as opposed to UDP in VXLAN). The outer IP header protocol field is set to 47 (the
protocol number for GRE).
Configuring a Sample Topology
FIGURE 6 NVGRE Packet Encapsulation
Table 3 describes the various fields in the NVGRE encapsulation.
TABLE 3 NVGRE Packet Encapsulation
Outer MAC Header The source and destination MAC addresses.

Out IP Header The provider addresses (PA); the source and destination IP addresses for the tunnel.
GRE Header Contains the following:
• Flag field (8 bits). The third bit (the “key” flag) is set to 1, meaning the header contains a
valid VSID. The remaining bits are set to zero.
• Protocol Type. This field is set to 0x6558 which is reserved for Transparent Ethernet
Bridging.
• 24-bit VSID. These 24 bits in the 32-bit key field in the GRE header. designate an individ-
ual NVGRE network on which virtual machines can communicate. Virtual machines in
different NVGRE networks cannot communicate with each other.
• Flow ID. These last 8 bits of key field are optional and can be used to add per-flow
entropy within the same VSID so that entire key field (32 bits) can be used for Equal-
Cost Multi-Path (ECMP) routing purposes by switches and routers. If Flow ID is not gen-
erated, it must be set to zero.
Understanding Fragmentation of Tunneled Packets

As a result of the additional header (50 bytes for VXLAN and 42 Bytes for NVGRE) added to tunneled packets, fragmentation
of the packet can occur if the host is not aware of this condition and the maximum segment size (MSS) is exceeded. The
ACOS device will automatically adjust the MSS exchanged for TCP flows to take into account this header.
To disable this automatic adjustment, use the overlay-tunnel tcp-mss-adjust-disable command. For more information,
refer to the overlay-tunnel command in the Command Line Interface Reference.

Figure 7 shows a sample topology that will be used as a sample configuration in this chapter.
FIGURE 7 Sample Overlay Tunnel Topology
The remainder of this section describes how to configure this topology:
• Configuring the Underlay/Provider Partition
• Configuring the Overlay/Tenant Partition P1
• Verifying the Configuration
NOTE: The instructions assume that you have already created the necessary L3V partitions on
your system. The overlay partition should be an L3V partition.
Configuring the Underlay/Provider Partition

This section provides the commands used to configure the provider partition. More details about each command are avail-
able in the Command Line Interface Reference.
This example is configured using VXLAN encapsulation; replace encap vxlan with encap nvgre if you want to use NVGRE
encapsulation.
Begin the tunnel configuration and specify the encapsulation

Enter configuration mode on your ACOS device and enter the following commands.
AX# config
AX(config)# overlay-tunnel vtep 1
AX(config-overlay-tunnel:1)# encap vxlan
Configure the source IP address

These commands create the binding between the user partitions (P1 and P2) and the tunnel endpoint VTEPa in the provider
partition.
NOTE: The IP address used in the configuration (in this case, 120.1.1.10) needs to be present in
the underlay partition as an interface IP or a floating IP before any traffic will pass
through.
AX(config-overlay-tunnel:1)# source-ip-address 120.1.1.10

AX(config-overlay-tunnel:1-src-vtep)# vni 100 partition P1 lif 10
AX(config-overlay-tunnel:1-src-vtep)# vni 200 partition P2 lif 20
AX(config-overlay-tunnel:1-src-vtep)# exit
AX(config-overlay-tunnel:1)#
Create the remote VTEP configuration for the clients (VTEPc)

These commands create the mapping for packets between VTEPa to VTEPc, identifying the IP address for VTEPc and the fact
that there are two VNIs behind VTEPc:
AX(config-overlay-tunnel:1)# destination-ip-address 100.1.1.10

AX(config-overlay-tunnel:1-dst-vtep)# vni 100
AX(config-overlay-tunnel:1-dst-vtep)# exit
AX(config-overlay-tunnel:1)#
Create the remote VTEP configuration for the servers (VTEPs)

These commands create the mapping for packets between VTEPa to VTEPs, identifying the IP address for VTEPs and the fact
that there are two VNIs behind VTEPs:
AX(config-overlay-tunnel:1)# destination-ip-address 110.1.1.10

AX(config-overlay-tunnel:1-dst-vtep)# exit
AX(config-overlay-tunnel:1)# exit
AX(config)#
Manually configure the host-to-destination VTEP mapping to avoid dynamic learning

By default, the ACOS device will attempt to dynamically learn the host-to-destination VTEP mapping by using unicast IP and
ARP response packets coming over the tunnel.
The host command is used to manually map the source VTEP to the logical interface behind the destination VTEP. For exam-
ple, the following command maps VTEPa to Client C1 (IP address 10.1.1.10 and MAC address 001c.011c.111c) on VNI 100
behind VTEPc (IP address 100.1.1.10):
AX(config)# host 10.1.1.10 001c.011c.111c vni 100 destination-vtep 100.1.1.10
Additional mappings between VTEPa to Client C2, Server S1, and Server S2 may be similarly configured:
AX(config)# host 20.1.1.10 002c.022c.222c vni 200 destination-vtep 100.1.1.10

AX(config)# host 10.1.1.20 001s.011s.111s vni 100 destination-vtep 110.1.1.10
AX(config)# host 20.1.1.20 002s.022s.222s vni 200 destination-vtep 110.1.1.10
Configuring the Overlay/Tenant Partition P1

This section provides the commands to configure the logical tunnel interfaces in the overlay/tenant partition:
• Configuring a Standalone LIF as a Layer 3 Interface
• Configuring a Pure Layer 2 LIF
• Configuring a LIF as a Layer 2 Interface Inside a VLAN with a Layer 3 Virtual Ethernet Endpoint
Configuring a Standalone LIF as a Layer 3 Interface

The following commands configure a standalone Layer 3 logical tunnel interface to be used for outbound traffic from parti-
tion P1 to VTEPa:
AX(config)# interface lif 10

AX(config-if:lif10)# ip address 10.1.1.1 /24
AX(config-if:lif10)# exit
AX(config)#
Configuring a Pure Layer 2 LIF

Similarly, you can configure an untagged Layer 2 logical interface in a VLAN; an example of this is shown with partition P2:
AX(config)# vlan 20
AX(config-vlan:20)# untagged lif 20
AX(config-vlan:20)# tagged ethernet 5
AX(config-vlan:20)# exit
AX(config)#
In such a configuration, when a packet is received on VLAN 20, a copy is tunneled over to the VTEP, and a second copy is sent
to ethernet interface 5.
Configuring a LIF as a Layer 2 Interface Inside a VLAN with a Layer 3 Virtual Ethernet Endpoint
Alternatively, you can make the Layer 2 LIF into a Layer 3 interface by adding the IP address to a virtual ethernet interface
configured on the VLAN:
AX(config)# vlan 20
AX(config-vlan:20)# untagged lif 20
AX(config-vlan:20)# tagged ethernet 5
AX(config-vlan:20)# router-interface ve 20
AX(config-vlan:20)# exit
AX(config)# interface ve 20
AX(config-if:ve20)# ip address 20.1.1.1 /24
AX(config-if:ve20)# exit
AX(config)#
Verifying the Configuration

To verify your configuration, you can use the following show commands. Additional information for each command is avail-
able in the Command Line Interface Reference.
To verify the configuration of the VTEP, use the show overlay-tunnel command:
ACOS# show overlay-tunnel

!
overlay-tunnel vtep 1
encap vxlan
source-ip-address 100.1.1.2
vni 100 partition p1 lif 2
destination-ip-address 90.1.1.1
encap vxlan
vni 100
!
To view packet statistics for your overlay configuration, use the show overlay-tunnel vtep statistics command:
ACOS# show overlay-tunnel vtep statistics

VTEP Global Counters:
Vtep unknown: Drop Rx 0 Vtep unknown: Drop Tx 0
lif invalid: Drop Rx 0 lif invalid: Drop Tx 0
lif not UP: Drop Rx 0 Dot1q Pkt: Drop Rx 0
Unhandled Pkts: Drop Rx 0 Unhandled Pkts: Drop Tx 0
Pkt too large: Drop Rx 0 Host => VTEP Learn Error 0
In Requeued Pkts 0 Misc Cfg Error: Drop Pkt 0
VTEP 2 Counters
Fragmented Pkts 14133380565 Reassembled Pkts 14330811744
Arp Reqs Sent 0 Host => VTEP Learned 0
lif invalid: Drop Rx 0 lif invalid: Drop Tx 0
lif not UP: Drop Rx 0 Encap unknown: Drop Tx 10121839
Unhandled Pkts: Drop Rx 0 Unhandled Pkts: Drop Tx 0
In Total Pkts 141238115020 Out Total Pkts 141038888963
In UCast Pkts 141238115020 Out Ucast Pkts 141038888963
In BCast Pkts 0 Out BCast Pkts 0
In MCast Pkts 0 Out MCast Pkts 0
In Dropped Pkts 0 Out Dropped Pkts 0
Notes about the Current Implementation
Cfg Error: Drop Pkt 0 Out Flooded Pkts 512649

In Encap Mismatch Pkts 0 In Bad Inner Chksum Pkts 0
In Bad v4 Inner len Pkts 0 In Bad v6 Inner len Pkts 0
lif 128 Partition p1:

In Total Octets 78710517251600 Out Total Octets 78501184485826
In MCast Pkts 0 Out MCastPkts 0
In Disable Dropped Pkts 0 Out Disable Dropped Pkts 0
In Total Dropped Pkts 0 Out Total Dropped Pkts 0
lif 1 Partition p1:

In Total Octets 78519119902139 Out Total Octets 78709699064881
In MCast Pkts 0 Out MCastPkts 0
In Disable Dropped Pkts 0 Out Disable Dropped Pkts 0
In Total Dropped Pkts 0 Out Total Dropped Pkts 0

The following notes clarify the current implementation of SDN.
• This feature is currently only available on non-FPGA Thunder platforms.
To determine whether or not your system has FPGA, run the show version command from the command line. If the
resulting output contains a line with the word “Firmware” then the system has FPGA and is not eligible for overlay net-
work configuration. All non-FPGA platforms do not have firmware listed in the output of the show version command.
• Only IPv4 networks, hosts and tunnels are supported, both for the overlay and the underlay. All non-IPv4 traffic going
across the overlay will need the corresponding logical interface to be configured as a Layer 2 interface.
• For VRRP-A, the VTEP IP should be configured as a floating IP. With VRRP-A configured, all VTEP and logical interface
partitions need to be part of the same VRRP group. The VTEP IP should be configured as the vrid-lead, while the vrid
resources in the logical interface partition, will need to be configured to follow the VTEP IP.
• With VRRP-A configured, the provider partition that has the VTEP configured and all related logical interface (cus-
tomer) partitions must be configured so that all of them are active or standby on the same ACOS device. VTEP-to-log-
ical interface communication between different ACOS devices is not supported.
• Forward reference for the logical interface partition as well as the logical interface is supported for the overlay-tunnel
configuration. For example, the overlay-tunnel configuration can be added without the need to first configure the
overlay partition (if different from the underlay partition) or creating the logical interface.
• Bridge VLANs with logical interfaces configured as Layer 2 interfaces are not supported.
• If the real servers are across an overlay tunnel, then the health check packets from both Active and Standby ACOS
Thunder devices will go over the overlay tunnel. Responses from the servers will only be received by the Active ACOS
device with the active Floating VTEP IP, so the real servers on the Standby will be in “down” state until switchover hap-
pens.
• Given that both Active and Standby ACOS devices will be sending health checks to the servers, if these were to go
over the tunnel, the responses are directed only to the Active ACOS device on the VTEP IP address. On the Standby
ACOS device, the Servers will be in “down” state until the switchover happens and health checks start passing.
Part V
Network Address Translation (NAT)
Network Address Translation (NAT) translates the source or destination IP address of a packet before forwarding the packet.
NOTE: This section 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 allo-
cates 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.
The ACOS device supports traditional, Layer 3 IP source NAT. IP source NAT translates internal host addresses into routable
addresses before sending 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.
The following chapters are included in this section:

• “Configuring Dynamic NAT” on page 265
• “Configuring Static NAT” on page 277
• “NAT ALG Support for PPTP” on page 281
• “Additional NAT Configuration Features” on page 285
Configuring Dynamic NAT
This chapter describes how to configure static source NAT, in which internal addresses are dynamically translated into exter-
nal addresses from a pool.
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. The addresses
within an individual pool still must be contiguous, but you can have gaps between the ending address in one pool
and the starting 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 sup-
ported.
If a pool group contains pools in different subnets, the ACOS device selects the pool that matches the outbound sub-
net. 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 available 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.
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 additional 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 1 Config Mode> Security > Network > ACL > Standard > Add
FIGURE 2 Config Mode > NAT > IPv4 Pool > Create
FIGURE 3 Config Mode > NAT > ACL Bind
FIGURE 4 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 configuration 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 con-
figuration 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 Refer-
ence.)
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 following 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
Configuring Dynamic IP NAT with Many Pools
The interface command changes the CLI to the configuration level for the interface connected to the internal hosts.
These are the hosts identified 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 connected 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

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 section.
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 configuration level of the CLI:
[no] ip nat pool pool-name start-ipaddr end-ipaddr netmask {subnet-mask | /mask-length}
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.
NOTE: When configuring a NAT pool, an interface IP address cannot be included as part of the
pool if source-nat auto is configured on the device. Additionally, if an existing NAT
pool already includes an IP address that is configured on one of the interfaces on the
device and the source-nat auto configuration is being added, it will be rejected.
Configure LIDs
A Limit ID (LID) assigns a numeric ID to a NAT pool. To configure a LID, use the following commands:
[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, user-
name (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 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
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 recom-
mended 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 individ-
ual 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:
ACOS(config-if:ethernet2)#exit
Configuring Static NAT
This chapter describes how to configure static source NAT, in which internal addresses are explicitly mapped to external
addresses.
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 exter-
nal 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 mapping or a range list before the host traffic is sent to the Internet.
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 supported 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 indi-
vidual 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 network 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 speci-
fies 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 ip nat allow-static-host command at the global configuration
level of the CLI to enable static NAT support:
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, use the following commands:
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
ACOS(config-if:ethernet2)#exit
NAT ALG Support for PPTP
This chapter describes NAT Application Layer Gateway (ALG) support for the Point-to-Point Tunneling Protocol (PPTP):
• Overview of NAT ALG Support for PPTP
• Configure NAT ALG Support for PPTP
Overview of NAT ALG Support for PPTP

NAT Application Layer Gateway (ALG) support for the Point-to-Point Tunneling 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 5 shows an example.
FIGURE 5 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.
Configure NAT ALG Support for PPTP
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 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. Therefore, 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 283.)
In Figure 5 on page 281, 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 IDfor 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 normal 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 sup-
ported. In practice, PPTP is used only for VPNs, in which case multiple concurrent calls
do not occur.

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 connected to the VPN clients.
• Enable outside IP source NAT on the ACOS device interface connected 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 configuration 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 configuration level of the CLI:
ip nat pool pool-name start-ipaddr end-ipaddr netmask {subnet-mask | /mask-length}

To configure an IP source NAT list, use the following command at the global configuration level of the CLI:
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 command at the global configuration level of the CLI:
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 configuration shown in Figure 5 on page 281.
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.
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
Additional NAT Configuration Features
This chapter describes additional NAT configuration options available on an ACOS device:
• Faster Timeout for TCP/UDP IP NAT Translations
• Mapping Allocation Method
• Fast Aging for IP NATted ICMP and DNS Sessions
• Client and Server TCP Resets for NATted TCP Sessions
• Requirements for Translation of DNS Traffic
• Pool-specific TCP Maximum Segment Life
• IP NAT Use in Transparent Mode in Multi-Netted Environment
• NAT Range List Requires ACOS Device Interface or Route Within the Global Subnet
• IP NAT in HA Configurations
• Disable/Enable Option for Static NAT Mappings
Faster Timeout for TCP/UDP IP NAT Translations

The current release supports faster timeout for TCP and UDP IP NAT translations. You can set the timeout for TCP or UDP ses-
sions to a value in one of the following ranges:
• 2-31 seconds – The timeout takes place very rapidly, as close to the configured 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 protocol 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.
Fast Aging for IP NATted ICMP and DNS Sessions
The mapping allocation method is configurable on an individual pool basis.
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.
Fast Aging for IP NATted ICMP and DNS Sessions

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 clients 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 1 summarizes the session timeouts and how to configure them.
TABLE 1 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 • Change the SLB MSL timeout.
default 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 285.
• DNS – Change the IP NAT translation UDP timeout 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 Translations” on page 285.
Using the CLI

To display the timeout that will be used for IP NATted sessions, use the following command:
show ip nat timeouts
To change the IP NAT translation timeout for ICMP, use the following command:
Client and Server TCP Resets for NATted TCP Sessions
[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 configured 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
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:
ACOS(config)# ip nat reset-idle-tcp-conn
Requirements for Translation of DNS Traffic
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 permit 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 connection sends a FIN to close the connection, that endpoint then enters the TIME-WAIT state.
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 endpoint 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 support this feature for IPv6 source
NAT pools. For information about configuring this feature for virtual ports, see the “Net-
work Address Translation for SLB” chapter in the Application Delivery and Server Load Bal-
ancing 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 configuring the ACL binding. To configure the ACL
binding, use the following command at the global configuration level of the CLI:
[no] ip nat inside source list acl-name pool pool-or-group-name msl seconds
IP NAT Use in Transparent Mode in Multi-Netted Environment
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
If the ACOS device is deployed in transparent mode, the device uses NAT IP addresses to perform health monitoring on serv-
ers 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 circumstances:
• IP source NAT is configured using a NAT range list.
• The ACOS device does not have any data interfaces or routes that contain 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

netmask {subnet-mask | /mask-length} [gateway ipaddr] [ha-group-id group-id]
[no] ipv6 nat pool pool-name start-ipv6-addr end-ipv6-addr netmask mask-length
[no] ip nat range-list list-name
source-ipaddr /mask-length nat-ipaddr /mask-length count number [ha-group-id group-id]
Disable/Enable Option for Static NAT Mappings

Using the CLI or GUI, you can modify your static NAT mappings without deleting them from the configuration. This will alle-
viate your need to either delete each static NAT mapping individually or globally disable all static NAT mappings.
If you are using the CLI, add the optional disable or enable keyword to the end of each static mapping.
If you are using the GUI, go to Config Mode > IP Source NAT > Static NAT and do the following:
• Click on the checkbox next to the Source Address.
• Click on Disable to deactivate the static NAT mapping.
• Click on Enable to activate the static NAT mapping.
Part VI
VRRP-A High Availability

• “Overview of VRRP-A” on page 295
• “Deploying VRRP-A” on page 311
• “VRRP-A GUI Configuration and Monitoring” on page 329
• “VRRP-A Policy-Based Failover Template” on page 357
Overview of VRRP-A
VRRP-A is the A10 Networks proprietary 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 implementation, is mutually exclusive of the HA feature and is configured sepa-
rately and not as part of the HA functionality.
VRRP-A simplifies configuration of multi-system redundancy, and allows up to eight ACOS devices to serve as mutual back-
ups for IP addresses.
VRRP-A is supported only on ACOS devices that are deployed in gateway (route) or one-armed mode. Transparent mode
deployments (inline deployments) are not supported. For transparent/inline deployments, use the older High Availability
(HA) feature (see “Overview of High Availability” on page 377).
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 1 shows a simple VRRP-A deployment with 2 devices.
Virtual Router ID
FIGURE 1 VRRP-A
In this example, a pair of ACOS devices are configured with private partitions. The VIPs and other IP resources in each parti-
tion 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 2.
FIGURE 2 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 in the shared partition and in L3V partitions only. VRRP-A is not supported in RBA partitions.
Layer 3 virtualization allows each L3V partition to have its own VRID, independent from the VRIDs belonging to other L3V par-
titions or the shared partition. By default, each L3V has a single, independent VRID (VRID 0); L3V partitions can have one VRID
per partition. The shared partition also has a single VRID by default, but up to 32 VRIDs are supported in the shared partition.
Virtual Router ID
Default VRID
By default, the shared partition and each L3V partition has its own VRID, named “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 partition 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 299.)
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 “Additional VRID Configuration” on
page 323.
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 and others can be configured to operate as followers. This means that only on one VRID will
you be able to configure all capabilities, such as configuring the failover policy template, the 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 fol-
lower VRID. refer to “Configuring a Leader and Follower VRID” on page 323.
VRID Virtual MAC Addresses

VRRP-A assigns a virtual MAC address to each VRID. The VRRP-A virtual 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.
Floating IP Addresses
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 3 shows a simple example.
FIGURE 3 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 interface can not be a floating IP address.
Advertisement of the Floating IP MAC Address After Failover
When a floating IP address moves from one ACOS device to another following failover, the MAC address associated with the
floating IP address changes.
To help other devices find a floating IP address following failover, the new active ACOS device sends IPv4 gratuitous ARPs (for
an IPv4 floating IP address) or ICMPv6 neighbor advertisements (for an IPv6 floating IP address). The other devices in the net-
work learn the new MAC address from the gratuitous ARPs or neighbor advertisements.
Configuration Synchronization
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 Synchronization” on page 465.
• Manual – See “Manually Synchronizing the Configuration” on page 313.
Session Synchronization
VRRP-A uses one active device and one standby device for a given VRID. If session synchronization (also called connection
mirroring) is enabled, the active device backs up active sessions on the standby device.
Session synchronization applies primarily to Layer 4 sessions. Session synchronization does not apply to DNS sessions. Since
these sessions are typically very short lived, there is no benefit to synchronizing them. Likewise, session synchronization does
not apply to NATted ICMP sessions or to any static NAT sessions. Synchronization of these sessions is not needed since the
newly active device will create a new flow for the session following failover.
Session synchronization is disabled by default and can be enabled on individual virtual ports.
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 4 shows an example.
FIGURE 4 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 priority is left set to the default value on all devices, device 1 becomes the active device for the VRID.
Active / Standby Device Selection
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 5 shows an example.
FIGURE 5 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 back-
ups.
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 6.
Failover
FIGURE 6 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 synchro-
nized 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 syn-
chronized 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 dynamically 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.
• The VRRP-A priority on the active device is manually reduced below the priority on the standby device by an adminis-
trator, and pre-emption is enabled.
• The force-self-standby option is used on the active device by an administrator.
Failover
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 preemption is disabled and the ACOS device typically would remain in a Active state, despite VRID prior-
ity changes. It allows for event-based failover once a tracked event occurs.
For more information, see “VRRP-A GUI Configuration and Monitoring” on page 329.
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 tim-
ers requires write access to the shared partition. The timers can not be configured by partition admins.
Multicast Hello Message Destination Addresses

By default, VRRP-A uses an IP multicast address as the destination for VRRP-A heartbeat messages to peers. VRRP-A sends
multicast hello messages to the following addresses:
• IPv4 multicast address 224.0.0.210, MAC address 01:00:5e:00:00:D2
• IPv6 link-local multicast address FF02::D2, MAC address 33:33:00:00:00:D2
Unicast Hello Message Destination Addresses

Instead of multicast heartbeat messages, you can configure VRRP-A to use unicast heartbeats instead for layer 3 redundancy
across subnets using VRRP-A.
To do so, configure a VRRP-A peer group on each device in the VRRP-A set. For redundancy in the peer group on each ACOS
device, you can configure multiple IP addresses for multiple data interfaces. You can configure a maximum of 16 IP addresses
on the peer group.
NOTE: At least one unicast address must be configured on a data interface per peer ACOS
device.
For reliability and redundancy, configure at least four IP Addresses in a peer-group, with each IP address belonging to a differ-
ent interface. This will enable you to allocate at least two interfaces per ACOS device. The peer group configuration on each
Failover
VRRP-A device in the set should be the same, including the device’s own IP address. When a device sends VRRP-A heartbeats
to the members of a peer group, that device skips any IP addresses that belong to itself.
The following example configure a VRRP-A peer group on an ACOS device:
ACOS-Pri(config)#vrrp-a peer-group
ACOS-Pri(config-peer-grp)#peer 10.20.10.3
ACOS-Pri(config-peer-grp)#peer 30.20.10.6
ACOS-Pri(config-peer-grp)#peer 2607:f0d0:1002:51::4
Dynamic Priority Reduction

Depending on configuration, failover can be triggered even if the active device is still operational. For each VRID, each device
begins with a statically configured priority for the VRID.
You can configure the priority of a VRID to be dynamically reduced based on changes in system or network conditions. For
example, you can configure link tracking on an Ethernet port. If the link goes down, the VRID priority on the device is
reduced by the configured amount. Figure 7 shows an example.
FIGURE 7 Failover Based on Dynamic Priority Reduction
In this example, link tracking is enabled for Ethernet port 6, and configured to reduce the VRID priority by 155 if the link goes
down. Device 1 has the higher configured priority value for VRID 0 in partition CorpB, and is the active device. However, if the
link on Ethernet port 6 goes down, the priority is dynamically reduced below the priority value on device 2. Device 2 there-
fore 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 connectivity 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.
Failover
• 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 priority 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 pri-
ority value to subtract can be specified individually for each VLAN.
• Real server health-check failure – If a real server in a virtual port’s service 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 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.
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 example, 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 configured 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.
Priority Calculation
Every few seconds, VRRP-A recalculates the priority for each VRID on the active device for the VRIDs.
To calculate the priority, VRRP-A subtracts the priority values for all optional failover trigger events that have occurred from
the configured priority value. The lowest value to which the priority can be reduced is 1.
Once the link or server health is restored, the failover trigger event is no longer occurring and the priority value is not sub-
tracted during the next priority calculation.
Failover
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 priority on one or more devices so that the active
device no longer has the highest 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 partition 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 applicable configuration
change takes effect.
This release enables you to configure a delay between VRRP-A configuration changes and the failover that occurs due to the
changes.
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). Pre-
emption delay is only triggered and used when VRRP-A is configured in a multiple ACOS device setup. Failover is only trig-
gered 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-emption delay to a longer value can help ensure
there is time for session synchronization 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 configuration and does not persist across reloads or reboots.
VRRP-A Interfaces
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 lis-
ten for hello messages. For an interface that belongs to more than 1 VLAN, the ACOS device uses the lowest VLAN ID to
which the interface belongs.
If a data interface has both IPv4 and IPv6 addresses, the primary IPv4 address is used.
Admins with write privileges for the shared partition can explicitly specify the ACOS device interfaces to use as VRRP-A inter-
faces. In this case, the specified interfaces are used as VRRP-A interfaces by the shared partition and by all private parti-
tions in which Layer 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 3 virtualization (L3V) partitions, the interface requirement differs depending on whether VRRP-A inter-
faces are explicitly configured:
• If no VRRP-A interfaces are explicitly configured (the default situation), each L3V partition must have at least one
Ethernet interface that can reach the other L3V partitions for the VRID.
• If at least one interface in the shared partition is explicitly configured as an VRRP-A interface, that interface is used for
the shared partition's VRID hello messages, and for the hello messages of all the VRIDs in the L3V partitions.
VRRP-A Interface Types and VRRP-A State

Changes to the state of a VRRP-A interface can trigger a failover. By default, the VRRP-A state of an interface can be Up or
Down. Optionally, you can specify the VRRP-A interface type as one of the 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.
VRRP-A Parameters
Preferred Receive Interface for Session Synchronization

By default, VRRP-A on a backup device automatically selects the Ethernet interface on which to receive synchronized ses-
sions. The ACOS device provides an option that enables you to specify the Ethernet interface(s) on which it is preferred to
receive synchronized sessions.
Using the GUI

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 con-
figuration level for the device that will receive the session information:
[no] vrrp-a preferred-session-sync-port ethernet portnum
VRRP-A Parameters
Table 1 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 GUI
Configuration and Monitoring” on page 329
TABLE 1 VRRP-A Parameters

Parameter Description and Syntax Supported Values
System-Wide Parameters
VRRP-A set ID VRRP-A domain. All devices that will provide backup for a 1-7
given VRID must belong to the same VRRP-A set. Default: 0
[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
VRRP-A Parameters
TABLE 1 VRRP-A Parameters (Continued)

VRID Virtual router ID. IP resources that are backed up by VRRP-A 1-31 or “default”
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.
ARP repeat count Number of additional IPv4 gratuitous ARPs or ICMPv6 neigh- 1-255
bor advertisements, in addition to the first one, an ACOS
Default: 4 additional gratuitous ARPs
device sends after transitioning from standby to active.
by default, for a total of 5.
[no] vrrp-a arp-retry num
Dead timer Number of hello intervals during which a backup device will 2-255
wait for a hello message from the active device, before begin-
Default: 5
ning 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 partition and all Enabled or disabled
default VRID in private partitions.
Default: enabled.
the shared parti-
Note: Disabling the default VRID allows you to use VRIDs 1-31
tion
instead of VRID 0 (the default VRID) in the shared partition. In
private partitions, disabling the default VRID disables VRRP-A.
[no] vrrp-a disable-default-vrid
Hello interval Interval at which the active device sends VRRP-A hello mes- 1-255 units of 100 milliseconds (ms)
sages to the backup devices. each
[no] vrrp-a hello-interval 100-msec-units Default: 200 ms
Host ID Append VRID that is used to carry the host ID information in its heart- Shared Partition – 1-31 or default
to VRID beat message.
Default: Not set
VRRP-A interfaces Interfaces used for VRRP-A management. ACOS device Ethernet interfaces
Note: This option is configurable only in the shared partition. Default: All up interfaces in a parti-
If you use this option to explicitly specify VRRP-A interfaces, tion are VRRP-A interfaces for that
the interfaces are used by the shared partition and by all pri- partition. (See “VRRP-A Interfaces”
vate partitions in which Layer 3 virtualization is enabled. on page 306.)
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.
[no] vrrp-a interface ethernet port-num
[router-interface | server-interface | both]
[no-heartbeat | vlan vlan-id]
VRRP-A Parameters

Track event delay Delay waited by the ACOS device before failover following a 100 milliseconds (ms) to 10000 ms,
dynamic priority change. The track event delay helps avoid in increments of 100 ms
unnecessary failovers caused by brief, temporary network
Default: 3000 ms (3 seconds)
changes.
(For more information, see “Dynamic Priority Reduction” on
page 303.)
[no] vrrp-a track-event-delay 100-msec-unit
VRID Parameter
Floating IP IP addresses that downstream devices should use as their Valid IPv4 or IPv6 address
address default IPv4 or IPv6 gateways. Regardless of which device is
Default: Not set
active for the VRID, downstream devices can reach their
default IPv4 or IPv6 gateway at the floating IP address. Note: Specifying the interface is
valid only for link-local IPv6
[no] floating-ip
addresses. This option is useful in
{
cases where you do not want the
ipaddr | ipv6addr [ethernet port-num |
floating IPv6 address to be associ-
ve ve-num | trunk num]
} ated with all ACOS device interfaces.
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 3 virtualization
(both FPGA and non-FPGA models):
64 VRRP-A floating IPs
Pre-emption Controls whether failovers can be caused by configuration Enabled or disabled
changes to VRRP-A priority or device ID.
Threshold: 1-255
The threshold specifies the maximum difference in priority
Defaults:
value that can exist between the active and standby devices
without failover occurring. • enabled
• threshold 0
[no] preempt-mode disable
[no] preempt-mode threshold num
VRRP-A Parameters

Priority Preference of the device to become the active device for the 1-255
VRID. The device that has the highest priority value for the
Default: 150
VRID becomes the active device for the VRID.
[no] priority num
Tracking options Tracking for dynamic priority reduction used in dynamic Priority to subtract – 1-255
failover. (See “Dynamic Priority Reduction” on page 303.)
(shared partition VLAN timeout – 2-600 seconds
only) You can configure tracking of the following network
Default: not set
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
priority-cost weight
[gateway {ipaddr | ipv6addr}]
[protocol {static | dynamic}]
[distance num]
[no] trunk num priority-cost num
[per-port-pri num]
[no] vlan vlan-id timeout seconds
priority-cost num
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 information, see “VRRP-A Parameters” on page 307.)
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 command 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]
Enable VRRP-A
[no] vrrp-a enable
Force-Self-Standby Reload or Restart Persistence
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 following command. Since you are not using the per-
sistence keyword, when the device completes a restart or software reload, it will not place VRID 2 in a self-standby state:
ACOS(config)#vrrp-a force-self-standby vrid 2
To place VRID 2 in a self-standby state even after a restart or reload, add the persistence keyword to your command:
ACOS(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:”
ACOS[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:
ACOS(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:
ACOS(config)#ha force-self-standby ha-group-id 2 persistence
Displaying VRRP-A Information

To display VRRP-A information, use the following commands:
Manually Synchronizing the Configuration
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.
show vrrp-a all-partitions [active]
This command shows the VRRP-A state for all partitions on the device. The active option shows only the active column,
which allows you to determine which partitions are active on a device.

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 synchro-
nized 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 connec-
tion 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 connection 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 GUI
Configuration and Monitoring” on page 329
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 partition, leave the Sync All Partitions checkbox unse-
lected.
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
• Floating IP addresses
• IP NAT configuration
• Access control lists (ACLs)
• Health monitors
• Policy-based SLB (black/white lists)
• SLB
• FWLB
• GSLB
• Data files (see below)
The items listed above that appear in the configuration file are copied to the other ACOS device’s running-config.
• Data Files – Copies only the SSL certificates and private-key files, aFleX files, External health 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 434.
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-startup-config [with-reload] | to-running-config}
[all-partitions | partition partition-name]
ipaddr |
[auto-authentication]
ha sync startup-config
ipaddr |
ha sync 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 at the global configuration level of the CLI:
[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 commands. 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 ACOS-1
ACOS-1(config)#vrrp-a device-id 1
ACOS-1(config)#vrrp-a enable
Commands on ACOS-2
Commands on ACOS-3
Commands on ACOS-4
Deployment with Custom Priority Settings

The following commands configure VRRP-A on 2 ACOS devices, with the priority settings shown in Figure 4 on page 299.
• 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 priority value is left set to its default (150) for CorpA and CorpC; the priority does not need to be set
since this is the default value.
• On 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 4 on page 299 does not include the floating IP
addresses. (For more on floating IP addresses, see “Floating IP Addresses” on page 298.)
Commands on ACOS-1
ACOS-1(config)#vrrp-a vrid default
ACOS-1(config-vrid)#priority 255
ACOS-1(config-vrid)#floating-ip 10.10.10.2
ACOS-1(config-vrid)#end
ACOS-1#active-partition CorpB
Currently active partition: CorpB
ACOS-1[CorpB]#config
ACOS-1[CorpB](config)#vrrp-a vrid default
ACOS-1[CorpB](config-vrid-default)#priority 255
ACOS-1[CorpB](config-vrid-default)#floating-ip 30.30.30.2
Commands on ACOS-2
ACOS-2#active-partition CorpA
Currently active partition: CorpA
ACOS-2[CorpA]#config
ACOS-2[CorpA](config)#vrrp-a vrid default
ACOS-2[CorpA](config-vrid-default)#priority 255
ACOS-2[CorpA](config-vrid-default)#floating-ip 20.20.20.2
ACOS-2[CorpA](config-vrid-default)#end
ACOS-2#active-partition CorpC
Currently active partition: CorpC
ACOS-2[CorpC]#config
ACOS-2[CorpC](config)#vrrp-a vrid default
ACOS-2[CorpC](config-vrid-default)#priority 255
ACOS-2[CorpC](config-vrid-default)#floating-ip 40.40.40.2
Configuration of Tracking Options

The following commands configure VRRP-A tracking options. For simplicity, 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.
ACOS(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.
ACOS(config)#vrrp-a vrid 1
ACOS(config-vrid)#tracking-options
ACOS(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.
ACOS(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.
ACOS(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 320 for details.
Gateway Tracking
The following commands configure tracking of gateway 10.10.10.1. If the gateway stops responding to pings, 100 is sub-
tracted from the VRID’s priority value.
ACOS(config)#health monitor gatewayhm1

ACOS(config-health:monitor)#method icmp
ACOS(config-health:monitor)#exit
ACOS(config)#slb server gateway1 10.10.10.1
ACOS(config-real server)#health-check gatewayhm1
ACOS(config-real server)#exit
ACOS(config)#vrrp-a vrid default
ACOS(config-vrid-tracking)#gateway 10.10.10.1 priority-cost 100
Route Tracking
The following command configures tracking of routes to destination network 3000::/64. If the IPv6 route table does not con-
tain any routes to the destination, 105 is subtracted from the VRID priority.
ACOS(config-vrid-tracking)#route 3000::/64 priority-cost 105
The following commands configure tracking of routes to destination network 5000::/64. If the IPv6 route table does not con-
tain any routes to the destination, 80 is subtracted from the VRID priority.
ACOS(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.
ACOS(config)#slb virtual-server vip1 192.168.1.88

ACOS(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 subtracted from the VRID’s priority.
Preemption Delay
The following command will allow you to configure the desired preemption delay value of 200 milliseconds:
ACOS(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 Policy-Based Failover Template”
on page 357) or priority assigned to the VLAN tracked event will be used in calculations that will impact VRRP-A failover deci-
sions. In previous releases, only tracking of 5 VLANs per partition was possible. Currently, 64 VLANs can be tracked per parti-
tion. For each L3V partition, you can track 64 different VLANs
If VRRP-A stops detecting traffic on a VLAN, VRRP-A reduces the priority for the VRID. The priority value to subtract can be
specified individually for each VLAN.
To configure VLAN tracking use the following command:
vlan vlan-id timeout timeout-value priority value
ACOS 2.7.2 provides two ways to track VLANs for VRRP-A:
• Using the priority tracking option—The tracking option performs failover by decreasing a VRID's priority value.
• Using failover policy templates—The failover policy template performs failover by decreasing a VRID's weight value.
You can track a total of 64 different VLANs in three possible ways:
• Configure all 64 VLANs that can be tracked using tracking options.
• Configure all 64 VLANs that can be tracked using a single failover policy template or split over multiple templates.
• Configure a mix of both options mentioned above. That is configure 32 VLANS using the tracking option and config-
ure the remaining 32 VLANs using a failover policy template.
NOTE: Tracking options and the failover policy template can track the same VLANs. For exam-
ple, 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 priority cost:
vrrp-a vrid 31
tracking-options
vlan 1000 timeout 30 priority-cost 1

Additional VRID Configuration

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
• Configuring a Leader and Follower VRID
• Configuring VRRP-A VRID Lead Switching
Configuring the Non-Default VRID

To configure any non-default VRID, specify a VRID number instead of the word default.
In any partition, use the vrrp-a vrid ? to view the number of supported partitions; for example, in the shared partition:
ACOS(config)#vrrp-a vrid ?
<1-31> Specify ha VRRP-A vrid
default Default VRRP-A vrid
Configuring a Leader and Follower VRID

This section contains the following:
• Configuration Example - Configuring a Leader and Follower VRID
• Configuration Example - Configuring a Leader in the Shared Partition
Configuration Example - Configuring a Leader and Follower VRID

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

ACOS(config)#vrrp-a vrid-lead lead1
ACOS(config-vrid-lead)#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:

ACOS#active-partition p1
b. In the currently active partition, p1, enter the following command:

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

ACOS[p1](config-vrid-follow)#show vrrp-a
vrid 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 - Configuring a Leader in the Shared Partition

To configure a leader in the shared partition, issue the following commands:
1. Define a VRID called myname as the leader:

ACOS(config)#vrrp-a vrid-lead myname
ACOS(config-vrid-lead)#partition p1 vrid default
2. Use the following show command to display your VRID leader configuration:
ACOS(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:
ACOS[p1](config)#vrrp-a vrid 3 follow vrid-lead myname
4. Observe your configuration using the show vrrp-a command:

ACOS[p1](config)#show run
vrrp-a vrid default follow vrid-lead default-vrid-lead

floating-ip 7.8.0.25
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 follower to standalone VRID again, issue the following
command:
ACOS[p1](config)#vrrp-a vrid 3
Change the role of vrid 3 from follower to standalone? (y/n)y
Again, to view your configuration, use the show run command:
ACOS[p1](config)#show 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.
Configuring VRRP-A VRID Lead Switching

This section describes how to switch lead VRIDs in a VRRP-A configuration without affecting traffic when doing so.
The example in this section utilizes the topology shown in Figure 8:
FIGURE 8 VRRP-A VRID Lead Switching Example Topology
Suppose you want to change the default VRID on partition p1 to follow AX2. Using the vrrp-a vrid default follow
vrid-lead-AX2 command could accomplish this, however there may be a disruption of the traffic on partition p1’s VRID
because of the time interval required for manual configuration on both sides.
This section provides alternative solutions that do not affect traffic:
• “Manual VRID Lead Switching Using Manual Configuration” on page 326
• “Automatic VRID Lead Switching Using aVCS” on page 327
Manual VRID Lead Switching Using Manual Configuration

To manually configure VRID lead switching without affecting traffic:
1. Use either an existing VRID whose up or down status is the same as the VRID you are configuring, or create a new VRID.
2. 2. Ensure that the new VRID’s active device is the same as the current VRID (in this example, the active device is ACOS-1).
You can accomplish this by manually setting the dynamic priority of the new VRID on ACOS-2 to a lower number than
on AOCS-1, or by using the vrrp-a force-self-standby command for the new VRID on ACOS-2.
3. 3. In partition p1 on both devices, use the vrrp-a vrid default follow vrid-lead new_vrid command to
make the traffic in the partition follow the new VRID. Since the new VRID has the same VRRP-A status as the existing
lead VRID, traffic is not impacted during this step.
4. 4. Change the dynamic priority of the new VRID on ACOS-1, or the no vrrp-a force-self-standby command for
the new VRID on ACOS-2, thus causing the new VRID to become active on ACOS-2. This switch is done my message
negotiation among peer devices, so no traffic is lost in this step.
VRRP-A Status in CLI Prompt
Automatic VRID Lead Switching Using aVCS

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

For information about how to customize the prompt to view VRRP-A and additional information, see “HA / VRRP-A / aVCS
Status in Command Prompt” in the System Configuration and Administration Guide.
VRRP-A GUI Configuration and Monitoring
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 purposes of operational famil-
iarity, 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 mutually exclusive of the HA feature and is configured sep-
arately and not as part 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
This section describes how to configure VRRP-A using the GUI.
Configuration
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 parti-
tion. In private partitions, 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 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).
Configuration
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 addi-
tional 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 nav-
igation bar) to permanently register your changes.
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 prior-
ity 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.
Configuration
NOTE: 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 high-
est priority of 255 for the primary device.
Floating IP Address
Follow these steps to configure the Floating IP Address:
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display 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 Floating 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.
Configuration
VRRP-A Tracking
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display the VRRP-A Tracking tab. Tracking for dynamic prior-
ity 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:
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.
Configuration
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-4096.

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. You must specify an existing interface.
c. Indicate a priority cost for the interface.
7. In the Route section, enter the route tracking fields:
Configuration
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.
8. 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.
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 synchronization is disabled
by default and can be enabled on individual virtual ports.
To configure the VRRP-A Preferred Session Sync Port for receiving sessions, do the following:
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display Preferred Session Sync Port tab.
2. Click on the down arrow next to expand the Preferred Session Sync Port section.
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.
Configuration
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 configuring 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 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.
Configuration
If you have private partitions configured, to configure followers for this lead VRID, you must enter the appropriate informa-
tion 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 preemp-
tion. Follow these steps to configure this option:
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display Force Self Standby tab.
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 parti-
tions or specific VRIDs. All Partitions will impact both shared partition and private partitions. If entered in the shared par-
tition, 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 configura-
tion 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.
Configuration
To configure VRRP-A interface parameters, follow these steps:
1. Select Config Mode > VRRP-A > VRRP-A Interface to display the VRRP-A Interface window:
2. Select a valid Ethernet interface and click on the interface name to launch the following VRRP-A for that particular inter-
face. 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 interface), or Both (the
upstream router and the real server are accessible through the interface). None is selected by default.
Configuration
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 configured with their IP Addresses in a partition are VRRP-A interfaces for that partition.
e. Enter a VLAN ID from 1-4094.
GUI Configuration Examples

The following sections show configuration examples for VRRP-A using the GUI. The first example shows a very basic deploy-
ment 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:
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display 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.
5. 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
To configure ACOS device 2, follow these steps:
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display 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.
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 priority value is left set to its default (150) for CorpA and CorpC. The priority does not need to be set
since this is the default value.
• On 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:
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display 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.
4. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display 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:
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
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
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 Moni-
tor Mode > VRRP-A > VRID, view the Active or Standby status of your devices or your partitions:
Monitoring
Monitoring
The following section describes how to track and monitor VRRP-A through the GUI.
Configuration of GUI Tracking Options

The following configuration displays VRRP-A tracking options. For simplicity, configuration for only a single device is shown.
Gateway Tracking
The following steps configure tracking of gateway 10.10.10.1. If the device 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.
6. Click on the server name to display the Server details.
Monitoring
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.
Monitoring
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 running configuration or Save (from the top naviga-
tion bar) to permanently register 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.
4. Click on Add.
Monitoring
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.
1. Select Config Mode > System > VRRP-A > VRRP-A Global to display the VRRP-A Tracking.
2. Click on the down arrow next to VRRP-A Tracking to expand the VRRP-A Tracking section. In the Trunk section, enter the
trunk tracking fields.
3. Choose VRID 1 from the drop down list.
4. Specify the Trunk ID value of 1. The ID must refer to an existing truck.
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.
1. Select Config Mode > VRRP-A > Setting > VRRP-A Global to display the VRRP-A Tracking option.
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. The ID must refer to an existing truck.
5. Indicate the Priority Cost of 150.
Monitoring
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 pri-
ority value.
1. Select Config Mode > System > VRRP-A > VRRP-A Global to display 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.
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 destination, 100 is subtracted from the VRID priority.
3. From the Route section, choose the default VRID from the drop down list.
Monitoring
4. Choose the IPv6 radio button and enter 3000::/64 as the IPv6 Address.
6. Click on Add.
Monitoring
The following steps configure tracking of routes to destination network 5000::/64. If the IPv6 route table does not contain any
routes to the destination, 80 is subtracted from the VRID priority.
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 tracking:
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:
1. Select Config Mode > SLB > Service > Virtual Server.
2. Click on Add to create a new Virtual Server.
3. Indicate a Name of your virtual server.
Monitoring
4. Indicate a valid IP Address or CIDR Subnet. 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: 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.
If more than one server fails its health check, 10 is subtracted for each server. For exam-
ple, if 3 servers fail their health checks, a total of 30 is subtracted from the VRID’s priority.
Monitoring
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 displays the peer priority and
whether or not the device is in a Forced Standby state.
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
configuration:
Based on configuration, the VRRP-A status window provides information on peers (Peer ID), IP Addresses, Ports, missed Heart-
beats, and Total Packets received.
Monitoring
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 priority 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 maintained 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 status 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 oth-
ers 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 preemption 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
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 priority assigned the VRID for an ACOS device which is
configurable. A failed event will result in a deduction of the weight assigned to the event from the fixed total weight for the
VRID. Since the weight of each VRID is tallied to figure out the weight and/or priority of an ACOS device, when multiple
devices are configured with VRRP-A, this value is used to gauge the device that will serve as the Active or the Standby device.
When the weight for all VRRP-A enabled devices are unequal, the device with the highest weight will serve as the Active
device, the rest will be placed in a Standby state.
Template Rules for Shared and Private Partitions

When creating templates in the shared partition, adhere to the following rules:
• You may create multiple templates, however only one template can be associated with a particular VRID. For example,
if you create two templates called “template1” and “template2,” you can only associate either template1 or template2
with VRID1. Assuming template1 and template2 have different events configured and you want template1 (that
tracks for VLANs and gateways) to also address the events that template2 tracks (for interfaces and routes), edit tem-
plate1 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 tem-
plate1.
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 templates called “template1” and “template2,” you can only associate either template1 or template2
with VRID1. Assuming template1 and template2 have different events configured and you want template1 (that
tracks for VLANs and gateways) to also address the events that template2 tracks (for interfaces and routes), edit tem-
plate1 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.
Preemption and Levels
• 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 contain 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 “Higher Weight Scenario” on page 359.
• If all ACOS devices have equal weight, the ACOS device with the higher priority will be the Active device. Refer to
“Higher Priority Scenario” on page 360.
• If the two ACOS devices have equal weight and equal priority, the device with the lower Device ID will be the Active
device. Refer to “Equal Weight and Priority Scenario” on page 361.
Higher Weight Scenario

Use the show vrrp-a command to view the Active/Standby status of the ACOS devices: Note that Unit 1 is the Active device
and its weight is “65534” for VRID1:
AOCS(config)#show vrrp-a
vrid 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:
ACOS(config)#show vrrp-a
vrid default
vrid 1
2 (Local) Active 65534 150 *
1 (Peer) Standby 65334 200
Higher Priority Scenario

Use the show vrrp-a command to view the Active/Standby status of the ACOS devices: Note for VRID1 that Unit 1 is the
Active device and its priority is “200:”
vrid 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

Use the show vrrp-a command to view the Active/Standby status of the ACOS devices: Note that VRID1 has an unequal
weight of “65534” and an equal priority of “150:”
vrid 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 trig-
gered 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
Events Tracked for Weight via the Templates

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, VRRP-A reduces the weight for the VRID. The
weight value to subtract 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, VRRP-A reduces the weight for the VRID. The
weight value to subtract 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.
Configuring VRRP-A Policy-Based Failovers
The following graphic visually represents where tracking can be enabled for an ACOS device:

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 358.
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 cre-
ated 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 traffic 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. Virtual 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, protocol, 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 failure:
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 private 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 failure:
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 display the different templates that you have cre-
ated. 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 configuration 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 cre-
ated:
[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
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:
ACOS(config)#vrrp-a fail-over-policy-template template1

ACOS(config-failover-policy)#interface ethernet 1 weight 200
ACOS(config-failover-policy)#gateway 20.20.20.20 weight 200
ACOS(config-failover-policy)#vlan 10 timeout 2 weight 200
ACOS(config-failover-policy)#route 20.20.20.0 /24 weight 200
ACOS(config-failover-policy)#trunk 1 weight 200
Use the show vrrp-a fail-over policy-template command to display the template configuration:
ACOS(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 “template 1” to VRID1 in the shared partition:
ACOS(config-vrid)#fail-over-policy-template template1
Show that the template is attached to the VRID group:
ACOS(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 configuration. In the following example, see that VRID1 is
now associated with the template called “interface.”
ACOS(config)#show run | section vrid 1

vrrp-a vrid 1
fail-over-policy-template interface
Failover Policy Template in a Private Partition

Configure a template in a private partition called “p1” and switch to the active partition from the privilege EXEC configura-
tion mode. Create your failover policy template called “template2-p1.” Configure the events you wish to track:
ACOS(config)#partition p1 network-partition
Show Command Configuration Examples
ACOS(config-partition)#exit
ACOS(config)#exit
Currently active partition: p1
ACOS-Active[p1](config)#vrrp-a fail-over-policy-template template2-p1
ACOS-Active[p1](config-failover-policy)#interface ethernet 1 weight 200
ACOS-Active[p1](config-failover-policy)#vlan 21 timeout 2 weight 200
ACOS-Active[p1](config-failover-policy)#gateway 21.21.21.21 weight 200
ACOS-Active[p1](config-failover-policy)#route 21.21.21.0 /24 weight 200
ACOS-Active[p1](config-failover-policy)#trunk 2 weight 200
Show private partition configuration:
ACOS-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

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:
ACOS(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 information on your current VRRP-A configuration:
ACOS(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:
ACOS(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:
ACOS(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
Use the show vrrp-a configuration command to display the entire VRRP-A configuration:
ACOS(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
interface ethernet 1 priority-cost 200
vrrp-a interface ethernet 1 vlan 31
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
Part VII
High Availability (HA)

• “Overview of High Availability” on page 377
• “HA Configuration Parameters” on page 399
• “Configuring HA” on page 407
• “HA To VRRP-A Migration” on page 445
Overview of High Availability
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.
NOTE: The version of High Availability described in this chapter is the version that is also sup-
ported in previous releases, and will be referred to as HA throughout this document. For
information about the VRRP-A High Availability implementation, see “VRRP-A High Avail-
ability” on page 293.
• HA on Your ACOS Device
• Types of HA Deployment
• HA Messages
• HA Interfaces
• Session Synchronization
• Optional Failover Triggers
• How the Active ACOS Device Is Selected
• HA Pre-Emption
• HA Sets
HA on Your ACOS Device

The following items clarify the implementation of HA on your ACOS device:
• In 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.
• The implementation of HA described in this chapter is not supported with Layer 3 virtualization. To use redundancy
with Layer 3 virtualization, use VRRP-A.
• 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
Types of HA Deployment
ACOS device. This does not occur with VRRP-A. If you use VRRP-A, all the protocol ports on NAT addresses are avail-
able.
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. For more information, see “Layer 3 Active-Standby HA” on
page 379.
• Active-Active – Each ACOS device is the primary SLB device for some of the configured virtual services, and is a hot
Standby for the other configured virtual services. For more information, see “Layer 3 Active-Active HA” on page 381.
Active-Standby is supported on ACOS devices deployed in transparent mode or route mode. Active-Active is supported only
on ACOS devices that are deployed in route mode.
Layer 3 Active-Standby HA
Figure 1 shows an example of an Active-Standby configuration.
FIGURE 1 Active-Standby HA
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 394.)
• 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 maintained without interrup-
tion.
(For a complete list of configurable HA parameters, see “HA Configuration Parameters” on page 399.)
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 3 virtualization (both FPGA and non-FPGA models): 64 floating IPs
Layer 3 Active-Active HA
Figure 2 shows an example of an Active-Active configuration.
FIGURE 2 Active-Active HA
In the Active-Active configuration, as in the Active-standby configuration. only one ACOS device is active for a given VIP. But
unlike the Active-Standby configuration, the same ACOS device does not need to be the Active ACOS device for all the VIPs.
Instead, each of the ACOS devices can be the Active ACOS device for some VIPs. In this example, AX1 is Active for VIP2 and
AX2 is Active for VIP1.
This configuration is similar to the configuration for Active-Standby shown in Figure 1, 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-emption, the device selection is
based on which of the ACOS devices comes up first.
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 example.
FIGURE 3 Topology Supported for Layer 2 Inline HA Deployment
NOTE: Beginning in AX Release 2.7.0, heartbeat messages in Layer 2 Inline mode deployments
are sent in unicast packets with the unicast MAC address and unicast IP address of the
peer ACOS device in the HA pair. They no longer are sent in IP multicast packets
addressed to IP multicast destination MAC and IP addresses. Like previous releases, they
also are not sent as broadcasts.
This applies to all ACOS device models. This change does not require any configuration
changes and should not affect the operation of your HA deployment.
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.
Each real server is connected to the router pair through a Layer 2 switch. Neither the Layer 2 switches nor the routers are run-
ning Spanning Tree Protocol (STP). The network does not have any Layer 2 loops because the Layer 2 switches are not con-
nected 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 4 Layer 2 Inline HA Deployment
Mandatory Connection-mirror IP Requirement for Layer 2 Inline Mode HA
ACOS devices require a connection mirror IP address to be configured in Layer 2 inline mode HA deployments. A connection
mirror interface is a unicast IP address on the peer ACOS device in the HA pair. This peer IP address is optional in earlier
releases but usually is configured anyway for session synchronization purposes. Beginning in AX Release 2.7.0, specifying a
connection mirror IP address is mandatory for proper operation of ACOS devices in Layer 2 Inline mode HA.
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 environment, the Standby ACOS device does not forward
traffic. In addition, the Active ACOS device in the HA pair is designed to not forward packets destined for the Standby
ACOS device. Depending on the network topology, certain traffic to the Standby ACOS device might be dropped if it
must first pass through the Active ACOS device.
Preferred HA Port
When you enable inline mode on an ACOS device, the ACOS device uses a preferred HA port for session synchronization and
for management traffic between the ACOS devices in the HA pair. For example, if you use the CLI on one ACOS device to
ping the other ACOS device, the ping packets are sent only on the preferred HA port. Likewise, the other ACOS device sends
the ping reply only on its preferred HA port.
Management traffic between ACOS devices includes any of the following types of traffic:
• Telnet
• SSH
• Ping
Optionally, you can designate the preferred HA port when you enable inline mode. In Figure 4 on page 383, Ethernet inter-
face 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. Heartbeat messages are sent out all HA interfaces unless
you disable the messages on specific interfaces.
NOTE: The preferred port must be added as an HA interface and heartbeat messages 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 4 on page 383, while AX1 is still Active, the active router (the one on the left) uses the MAC entries it
has learned on its link with AX1 to reach downstream devices. If the link with AX1 goes down, the router flushes the MAC
entries. The router then relearns the MAC addresses on the link with AX2 when it becomes the Active ACOS device.
This mechanism is applicable when the link with AX1 goes down. However, if the transition from Active to Standby does not
involve failure of the router's link with AX1, the router does not flush its learned MAC entries on the link. As a result, the router
might continue to send traffic for downstream devices through the router's link with AX1. Since AX1 is now the Standby, it
drops the traffic, thereby causing reachability issues.
For example, if you administratively force a failover by changing the HA configurations of the ACOS devices and enabling HA
pre-emption, the link between the router and AX1 remains up. In this case, the router continues to have MAC addresses
through this link.
To ensure that devices connected to the formerly Active ACOS device flush their learned MAC entries on their links with AX1,
you can enable HA port restart.
HA port restart toggles a specified set of ports on the formerly Active ACOS device by disabling the ports, waiting for a spec-
ified number of milliseconds, then re-enabling the ports. Toggling the ports causes the links to go down, which in turn
causes the devices on the other ends of the links to flush their learned MAC entries on the links. The devices then can relearn
MACs through links with the newly Active ACOS device.
NOTE: You must omit at least one port connecting the ACOS devices from the restart port-list.
This is so that heartbeat messages between the ACOS devices are maintained; other-
wise, 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.
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 5 shows an example.
FIGURE 5 Inline Mode for Layer 3 HA
In this example, each ACOS device has multiple Ethernet ports connected to the clients, and multiple Ethernet ports con-
nected 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.
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.
HA Messages
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 pro-
cessing is required on these interfaces in order to change the source IP address from the server’s real IP address back
into the VIP address.
Restrictions
• Supported for Active-Standby HA deployments only. Not supported for Active-Active HA.
• Inline mode is designed for one HA group in Hot-Standby mode. Do not configure more than one HA group on an
ACOS device running in inline mode.
• In order to prevent Layer 2 loops in a Layer 2 host-standby environment, the Standby ACOS device does not forward
traffic. In addition, the Active ACOS device in the HA pair is designed to not forward packets destined for the Standby
ACOS device. Depending on the network topology, certain traffic to the Standby ACOS device might be dropped if it
must first pass through the Active ACOS device.
HA Messages
The ACOS devices in an HA pair communicate their HA status with the following types of messages:
• HA heartbeat messages
• Gratuitous ARP requests and replies
HA Heartbeat Messages
Each of the ACOS devices regularly sends HA heartbeat messages out its HA interfaces. The Standby ACOS device listens for
the heartbeat messages. If the Standby ACOS device stops receiving heartbeat messages from the Active ACOS device, the
Standby ACOS device transitions to Active and takes over networking and SLB operations from the other ACOS device.
By default, heartbeat messages are sent every 200 milliseconds. If the Standby ACOS device does not receive a heartbeat
message for 1 second (5 times the heartbeat interval), the Standby ACOS device transitions to Active.
The heartbeat interval and retry count are configurable. (See “HA Configuration Parameters” on page 399.)
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.)
HA Interfaces
Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6)

For IPv4, when an ACOS device transitions from Standby to Active, the newly Active ACOS device sends gratuitous ARP
requests and replies (ARPs) for the IPv4 address under HA control.
Similarly, for IPv6, when an ACOS device transitions from Standby to Active, the newly Active ACOS device sends ICMPv6
neighbor advertisement for the IPv6 address under HA control.
Gratuitous ARPs or ICMPv6 neighbor advertisements are sent for the following types of addresses:
• Virtual server IP addresses, for the VIPs that are assigned to an HA group.
• Floating IP address, if configured
• NAT pool IP addresses, for NAT pools assigned to an HA group
Devices that receive the ARPs or ICMPv6 neighbor advertisements learn that the MAC address for the HA pair has moved,
and update their forwarding tables accordingly.
The Active ACOS device sends the gratuitous ARPs or ICMPv6 neighbor advertisements immediately upon becoming the
Active ACOS device. To make sure ARPs or ICMPv6 neighbor advertisements are being received by the target addresses, the
ACOS device re-sends them 4 additional times, at 500-millisecond intervals.
After this, the ACOS device sends gratuitous ARPs or ICMPv6 neighbor advertisements every 30 seconds to keep its IP infor-
mation current.
The retry count is configurable. (See “HA Configuration Parameters” on page 399.)
HA Interfaces
When configuring HA, you specify each of the interfaces that are HA interfaces. An HA interface is an interface that is con-
nected 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.
HA Interfaces
• Down – All router interfaces, or all server interfaces, or both are down. The status also is Down if both router interfaces
and server interfaces are not configured and an HA interface goes down.
If both types of interfaces (router interfaces and server interfaces) are configured, the HA interfaces for which a type has not
been configured are not included in the HA interface status determination.
During selection of the active ACOS device, the ACOS device with the highest state becomes the active ACOS device and all
HA interfaces on that ACOS device become active. For example, if one ACOS device is UP and the other ACOS device is only
Partially Up, the ACOS device that is UP becomes the active ACOS device.
If each ACOS device has the same state, the active ACOS device is selected as follows:
• If HA pre-emption is disabled (the default), the first ACOS device to come up is the active ACOS device.
• If HA pre-emption is enabled, the ACOS device with the higher HA group priority becomes active for that group. If the
group priorities on the two ACOS devices are also the same, the ACOS device that has the lowest HA ID (1 or 2)
becomes active.
NOTE: You can configure up to 31 HA groups on an ACOS device, and assign a separate HA pri-
ority 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 multicast packets. (This requirement does not apply to Layer 2 inline HA because it uses unicast to
transmit the heartbeat.)
• If a tracked interface is a member of a trunk, only the lead port in the trunk is shown in the tracking configuration and
in statistics. For example, if a trunk contains ports 1-3 and you configure tracking of port 3, the configuration will show
that tracking is enabled on port 1. Likewise, 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.
VLAN ID Requirement
Beginning in AX Release 2.7.0, in deployments that use the older implementation of High Availability (HA), if an HA interface
is a tagged member of one or more VLANs, it is required to specify one of the member VLAN IDs when configuring the inter-
face 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:
ACOS(config)# ha interface ethernet 5 vlan 2
The following command is invalid:
ACOS(config)# 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:
ACOS(config)# ha interface ethernet 5 no-heartbeat
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. Without it, a failover causes cli-
ent sessions to be terminated. Session synchronization can be enabled on individual virtual ports.
Session synchronization applies primarily to Layer 4 sessions. Session synchronization does not apply to DNS sessions. Since
these sessions are typically very short lived, there is no benefit to synchronizing them. Likewise, session synchronization does
not apply to NATted ICMP sessions or to any static NAT sessions. Synchronization of these sessions is not needed since the
newly Active ACOS device will create a new flow for the session following failover.
To enable session synchronization, see “Enabling Session Synchronization” on page 433.
Session synchronization is required for config sync. Config sync uses the session synchronization link. (For more information,
“Manually Synchronizing Configuration Information” on page 434.)
NOTE: Session synchronization is also called “connection mirroring”.
Optional Failover Triggers

In addition to HA interface-based failover, you can configure failover based on any of the following:
• Inactive VLAN (VLAN-based failover)
• Unresponsive gateway router (gateway-based failover)
• Unresponsive real servers (VIP-based failover)
VLAN-Based Failover
You can enable HA checking for individual VLANs. When HA checking is enabled for a VLAN, the active ACOS device in the
HA pair monitors traffic activity on the VLAN. If there is no traffic on the VLAN for half the duration of a configurable timeout,
the ACOS device attempts to generate traffic by issuing ping requests to servers if configured, or broadcast ARP requests
through the VLAN.
If the ACOS device does not receive any traffic on the VLAN before the timeout expires, a failover occurs. The timeout can be
2-600 seconds. You must specify the timeout. Although there is no default, A10 recommends trying 30 seconds.
This HA checking method provides a passive means to detect network health, whereas heartbeat 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 recom-
mends that you specify an HA checking interval (timeout) that is much longer than the heartbeat interval.
For a configuration example, see “VLAN-Based Failover Example” on page 429.
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.
Note the following:
• HA does not calculate a cost number based on individual health checks. While VRRP-A calculates a cost number
based on each check option, HA only has “DOWN,” “PARTIAL DOWN,” or “UP” status after calculating the result of all
health checks.
• HA is not able to check the status for individual HA groups, meaning that all HA groups share the single result of these
health checks. So a device with a “PARTIAL DOWN” status in one HA group means all HA groups will also share this
status.
• The priority is weighted in the following order of decreasing precedence:
• UP
• PARTIAL DOWN
• DOWN
• Priority value of the HA group
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 430.
Route-Based Failover
Route-based failover reduces the HA priority of all HA groups on the ACOS device, if a specific route is missing from the IPv4
or IPv6 route table.
You can configure this feature for individual IP routes. When you configure this feature for a route, you also specify the value
to subtract from the HA priority of all HA groups, if the route is missing from the route table.
You can configure this option for up to 100 IPv4 routes and up to 100 IPv6 routes. This option is valid for all types of IP routes
supported in this release (static and OSPF).
If the priority of an HA group falls below the priority for the same group on the other ACOS device in an HA pair, a failover can
be triggered.
Notes
• This feature applies only to routes in the data route table. The feature does not apply to routes in the management
route table.
• For failover to occur due to HA priority changes, the HA pre-emption option must be enabled.
For a configuration example, see “Route-Based Failover Example” on page 431.
Real Server or Port Health-Based Failover

You can configure the ACOS device to decrease the HA priority of an HA group, if a real server or port’s health status changes
to Down.
You can configure this feature on individual real servers and ports. The feature is disabled by default. To enable the feature,
assign an HA weight to the server or port. If the server or port’s health status changes to Down, the weight value is sub-
tracted 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.
If you enable the dynamic HA option on a virtual server, the ACOS device reduces the HA priority of the group assigned to
the virtual server, if a real server becomes unavailable. (A real server is unavailable if it is marked Down by the ACOS device
because the server failed its health check.) If the priority value is reduced to a value that is lower than the group’s priority
value on the other ACOS device in the HA pair, and HA pre-emption is enabled, service of the virtual serve is failed over to the
other ACOS device.
When a real server becomes available again, the weight value that was subtracted from the HA group’s priority is re-added. If
this results in the priority value being higher than on the other ACOS device, the virtual server is failed over again to the
ACOS device with the higher priority value for the group.
NOTE: Configure the same HA group ID on any floating IP addresses or Source IP NAT pools
used by the virtual server. For example, if you assign a virtual 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 431.
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 6.
FIGURE 6 Initial Selection of Active ACOS Device
After initial selection of the Active ACOS device, that device remains the Active ACOS device unless one of the following
events occurs:
• The Standby ACOS device stops receiving HA heartbeat messages from the Active ACOS device.
• The HA interface status of the Active ACOS device becomes lower than the HA interface status of the Standby ACOS
device.
• VLAN-based failover is configured and the VLAN becomes inactive.
• Gateway-based failover is configured and the gateway becomes unavailable.
• HA pre-emption is enabled, and the configured HA priority is changed to be higher on the Standby ACOS device.
Figure 7 shows the events that can cause an HA failover.
FIGURE 7 HA Failover
HA Pre-Emption
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 388.)
• VLAN-based failover is configured and the VLAN becomes inactive. (See “VLAN-Based Failover” on page 390.)
• Gateway-based failover is configured and the gateway becomes unavailable. (See “Gateway-Based Failover” on
page 391.)
• 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 392.)
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 priori-
ties and enabling pre-emption, see “Forcing Active Groups to Change to Standby Status”
on page 433.
HA Sets
Optionally, you can provide even more redundancy by configuring multiple sets of HA pairs.
FIGURE 8 Multiple HA Pairs
HA Sets
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 spec-
ified along with the HA ID. (For syntax information, see “HA Configuration Parameters” on page 399.)
HA Sets
HA Configuration Parameters
Table 1 lists the HA parameters.
TABLE 1 HA Parameters
Global HA Parameters
HA ID HA ID of the ACOS device, and HA set to which the ACOS HA ID: 1 or 2
device belongs.
and HA set ID: 1-7
The HA ID uniquely identifies the ACOS device within the HA
HA set ID Default: Neither parameter is set
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 - General
HA group ID Uniquely identifies the HA group on an individual ACOS HA group ID: 1-31
device.
Priority: 1 (low priority) to 255 (high
The priority value can be used during selection of the Active priority
ACOS device. (See“How the Active ACOS Device Is Selected”
Default: not set
on page 394.)
[no] ha group group-id priority num
Config Mode > System > HA > HA Global - Group
Floating IP IP address that downstream devices should use as their Default: not set
address 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 - Floating IP
Address
TABLE 1 HA Parameters (Continued)

HA interfaces Interfaces used for HA management. Ethernet interfaces
HA heartbeat messages are sent on HA interfaces, unless you Default: not set
use the option to disable the messages.
At least one HA interface must be specified. If the interface is
tagged, then a VLAN ID must be specified if heartbeat mes-
sages are enabled on the interface.
If you specify the interface type (server, router, or both),
changes to the interface state can control failover. (See “HA
Interfaces” on page 388 and “How the Active ACOS Device Is
Selected” on page 394.)
[no] ha interface ethernet port-num
[router-interface |
server-interface | both]
Config Mode > Network > Interface > LAN - Select the inter-
face and then click HA.
VLAN-based HA Enables the ACOS device to change its HA status based on Valid VLAN ID
the health of a VLAN.
Default: not set
When HA checking is enabled for a VLAN, the active ACOS
The timeout can be 2-600 seconds.
device in the HA pair monitors traffic activity on the VLAN. If
there is no traffic on the VLAN for half the duration of a con- Although there is no default time-
figurable timeout, the ACOS device attempts to generate traf- out, A10 recommends trying 30 sec-
fic by issuing ping requests to servers if configured, or onds.
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 sec-
onds
Config Mode > System > HA > HA Global - Status Check
Gateway-based Enables the ACOS device to change its HA status based on IP address of the gateway
HA the health of a gateway router.
Default: not set
If the gateway fails a Layer 3 (ICMP) health check, the ACOS
Additional configuration is required.
device changes its HA status to Down. If the HA status of the
(See “Gateway-Based Failover” on
other ACOS device is higher than Down, a failover occurs.
page 391.)
[no] ha check gateway ipaddr
Config Mode > System > HA > HA Global - Status Check

Session synchro- Enables the ACOS devices to share information about active IP address of the other ACOS device
nization client sessions. If a failover occurs, client sessions continue
Default: not set
uninterrupted. The Standby ACOS device, when it becomes
(Also called “con-
Active, uses the session information it received from the
nection mirror-
Active ACOS device before the failover to continue the ses-
ing”)
sions without terminating them.
To enable session synchronization, specify the IP address of
the other ACOS device in the HA pair.
Session synchronization does not apply to DNS sessions.
Since these sessions are typically very short lived, there is no
benefit to synchronizing them.
Note: This option also requires session synchronization to be
enabled on the individual virtual service ports. (See “HA
Parameters for Virtual Service Ports” below.)
[no] ha conn-mirror ip ipaddr
Pre-emption Controls whether failovers can be caused by configuration Enabled or disabled
changes to HA priority or HA ID.
Default: disabled
[no] ha preemption-enable
Config Mode > System> HA > HA Global - General
HA heartbeat Interval at which the ACOS device sends HA heartbeat mes- 1-255 units of 100 milliseconds
interval sages on its HA interfaces. (ms) each
[no] ha time-interval Default: 200 ms
100-msec-units
Retry count Number of HA heartbeat intervals the Standby device will 2-255
wait for a heartbeat message from the Active ACOS device
Default: 5
before failing over to become the Active ACOS device.
[no] ha timeout-retry-count num
ARP repeat count Number of additional gratuitous ARPs, in addition to the first 1-255
ones, an ACOS device sends after transitioning from
Default: 4 additional gratuitous
Standby to Active in an HA configuration.
ARPs, for a total of 5
[no] ha arp-retry num

Forced failover Forces HA groups to change from Active to Standby status. Valid HA group ID.
[no] ha force-self-standby If you do not specify a group ID, all
[group-id] Active groups are forced to change
from Active to Standby status.
Note: This option provides a simple method to force a
failover, without the need to change HA group priorities and
enable pre-emption. The option is not added to the configu-
ration and does not persist across reboots.
Note: The current release does not support configuration of
this parameter using the GUI.
Layer 2/3 Enables Layer 2/3 forwarding of Layer 4 traffic on the Standby Enabled or disabled
forwarding of ACOS device.
Default: Disabled. Layer 4 traffic is
Layer 4 traffic on
[no] ha forward-l4-packet-on-standby dropped by the Standby ACOS
the Standby
device.
ACOS device Note: The current release does not support configuration of
this parameter using the GUI.
Global HA Parameters for Layer 2 Inline Mode
Inline mode state Enables Layer 2 inline mode and, optionally, specifies the HA Enabled or disabled
interface to use for session synchronization and for manage-
Default: disabled
ment traffic between the ACOS devices.
When inline mode is enabled, the
[no] ha inline-mode preferred port is selected as
[preferred-port port-num]
described in “Preferred HA Port” on
Config Mode > System> HA > HA Inline Mode page 384.
Restart port list List of Ethernet interfaces on the previously Active ACOS Ethernet interfaces
device to toggle (shut down and restart) following HA
Default: not set
failover.
[no] ha restart-port-list ethernet port-
list
Config Mode > System> HA > HA Inline Mode
Port restart time Amount of time interfaces in the restart port list remain disa- 1-100 units of 100 milliseconds (ms)
bled 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

OSPF on Standby Leaves OSPF enabled on the Standby ACOS device. Enabled or disabled
ACOS device
[no] ha ospf-inline vlan vlan-id Default for all HA modes except
Layer 3 inline: disabled. OSPF is dis-
Note: This option is not configurable using the GUI.
abled on the Standby ACOS device.
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 before chang- 100 milliseconds (ms) to 10000 ms,
ing the HA state (Up, Partially Up, or Down) in response to in increments of 100 ms
link-state changes on HA 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 virtual 1-255
server.
Not set
The weight is used for VIP-based failover. (See “VIP-Based
Failover” on page 392.)
[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 before chang- 100 milliseconds (ms) to 10000 ms,
ing the HA state (Up, Partially Up, or Down) in response to in increments of 100 ms
link-state changes on HA interfaces.
[no] ha link-event-delay
100-ms-unit
Config Mode > HA > Setting - HA Inline Mode
HA Parameters for Virtual Service Ports
Session Enables active client sessions on this virtual port to continue Enabled or disabled
synchronization uninterrupted following a failover.
Default: disabled
(Also called “con- Note: This option also requires session synchronization to be
nection mirror- enabled globally. (See “Global HA Parameters” above.)
ing”)
[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 real server’s Weight: 1-255
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 configuration of Default: not set
this option using the GUI.
HA Parameters for Real Ports
Priority cost Decreases the HA priority of an HA group, if the real port’s Weight: 1-255
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 configuration of 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 continue unin- Enabled or disabled
synchronization terrupted following a failover.
Default: disabled
Note: This option also requires session synchronization to be
enabled globally. (See “Global HA Parameters” above.)
[no] ha-conn-mirror
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 inside Default: not set
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 ACOS device, Default: not set
if the specified route is missing from the IPv4 or IPv6 route
table.
For IPv4 routes:

[no] ha check route
destination-ipaddr /mask-length
[gateway ipaddr]
[distance num]
For IPv6 routes:

[no] ha check route
destination-ipv6addr/mask-length
[gateway ipv6addr]
[distance num]
Note: The current release does not support configuration of

Configuring HA
This chapter explains how to configure HA.
• Configuring Layer 3 HA
• Configuring Layer 2 HA (Inline Mode)
• Configuring Layer 3 HA (Inline Mode)
• Configuring Optional Failover Triggers
• Forcing Active Groups to Change to Standby Status
• Enabling Session Synchronization
• Manually Synchronizing Configuration Information
• Tip for Ensuring Fast HA Failover
• HA Status Indicators
• Viewing Config-Sync Status
Configuring Layer 3 HA
To configure Layer 3 HA:
1. Configure the following global HA parameters:
• HA ID
• HA group ID and priority. For an Active-Standby configuration, configure one group ID. For Active-Active, configure
multiple HA group IDs.
• Floating IP address (optional)
• Session synchronization (optional)
• HA pre-emption (optional)
2. Configure the HA interfaces.
3. Add each virtual server to an HA group.
4. If session synchronization is globally enabled, enable it on the individual virtual ports whose client sessions you want to
synchronize.
5. If IP NAT pools are configured, add each pool to an HA group.
Using the GUI
Configuring Global HA Parameters
1. Select Config Mode > System> HA.
a. In the Identifier drop-down list, select the HA ID for the ACOS device.
b. Select Enabled next to HA Status.
c. To enable pre-emption, select Enabled next to Preempt Status.
d. To enable connection mirroring, enter the IP address of the other ACOS device in the HA Mirroring IP Address field.
NOTE: Enter the real IP address of the ACOS device, not the floating IP address that down-
stream 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 prior-
ity 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 388.)
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
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 392.
4. Configure other general settings, not related to HA, if needed.
5. If you plan to use session synchronization (connection mirroring) for a service port:
a. In the Port section, click Add to add a new virtual service port or select an existing port and click Edit. The Virtual
Server Port section appears.
b. Select enabled next to HA Connection Mirror.
c. Click OK. The service port list re-appears.
NOTE: The GUI does not support enabling connection mirroring on some types of service
ports. However, you can enable connection mirroring for these service types using the
CLI.
6. Click OK to complete configuration of the virtual server.
HA Configuration of ACOS1
FIGURE 9 Config Mode > System > HA > HA Global
FIGURE 10 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 11 Config Mode > SLB > Service > Virtual Server (VIP1)
HA Configuration of ACOS2
FIGURE 13 Config Mode > System > HA > HA Global
Using the CLI

1. To configure the global HA parameters, use the following commands at the global configuration level of the CLI:
ha id {1 | 2} [set-id num]
ha group group-id priority num
floating-ip ipaddr ha-group group-id
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 command at the configuration level for the virtual port
to enable session synchronization for the port:
ha-conn-mirror
4. If IP NAT will be used, use the following option with the ip nat pool or ipv6 nat pool command when configuring the
pool.
ha-group group-id
(For the complete command syntax, see Table 1 on page 399.)
Commands on ACOS1
This examples shows the CLI commands to implement the Active-Active configuration shown in Figure 2 on page 381.
The following commands configure the HA ID and HA groups. Since this is an Active-Active configuration, both HA groups
are configured. The priority for group 1 is set to a low value. The same group will be set to a higher priority value on the other
ACOS device. Likewise, the priority of group 2 is set to a high value on this ACOS device but will be set to a lower value on the
other ACOS device.
Later in the configuration, each virtual server will need to be added to one or the other of the HA groups.
ACOS1(config)#ha id 1
ACOS1(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 s.
ACOS1(config)#floating-ip 10.10.10.1 ha-group 1

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

ACOS1(config)#ha interface ethernet 3 server-interface no-heartbeat
ACOS1(config)#ha interface ethernet 5
The following command enables session synchronization (connection mirroring). The feature also will need to be enabled
on individual virtual ports, later in the configuration. The IP address is the real address of the other ACOS device.
ACOS1(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.
ACOS1(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.)
ACOS1(config)#slb virtual-server VIP1

ACOS1(config-slb vserver)#ha-group 1
ACOS1(config-slb vserver)#port 80 tcp
ACOS1(config-slb vserver-vport)#ha-conn-mirror
ACOS1(config-slb vserver-vport)#exit
ACOS1(config-slb vserver)#exit
Commands on ACOS2
Here are the commands for ACOS2. The priority values for the groups are different from the values set on ACOS1, so that
group 1 has higher priority on this ACOS device than on ACOS1. Likewise, the priority of group 2 is set so that its priority is
higher on ACOS1.
The floating IP addresses must be the same as the ones set on ACOS1.

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

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

Configuring Layer 2 HA (Inline Mode)

• 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.
synchronize.
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 mod-
els: 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.
Layer 2 Inline HA Configuration Example

The following configuration examples implement the deployment shown in Figure 4 on page 383. 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 388.)
• 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 gate-
way 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 down-
stream 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 388.)
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 ACOS1 in Figure 4 on page 383.
FIGURE 16 Config Mode > System > HA
FIGURE 17 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 18 Config Mode > System > HA > HA Inline Mode
Using the CLI
Commands on ACOS1
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.
The following command enables inline HA mode and specifies the preferred HA port.
ACOS1(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.

ACOS1(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.
ACOS1(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 configuration. (For example, if you change the HA priority so that the other ACOS device has higher prior-
ity, this will trigger a failover, but only if pre-emption mode is enabled.)
The following command specifies the IP address of the other ACOS device, to use for session synchronization.
The following command configures the floating IP address for the real servers to use as their default gateway address.

The following commands configure a health method, real servers, a server group, and a VIP
for an HTTP service.

ACOS1(config)#health monitor myHttp interval 10 retry 2 timeout 3
ACOS1(config-health:monitor)#method http url HEAD /index.html
ACOS1(config-health:monitor)#exit
ACOS1(config)#slb server s1 172.168.10.30
ACOS1(config-real server)#port 80 tcp
ACOS1(config-real server-node port)#health-check myHttp
ACOS1(config-real server-node port)#exit
ACOS1(config-real server)#exit
ACOS1(config)#slb service-group g80 tcp
ACOS1(config-slb svc group)#member s1:80
ACOS1(config-slb svc group)#exit
ACOS1(config)#slb virtual-server v1 172.168.10.80
ACOS1(config-slb vserver-vport)#service-group g80
Commands on ACOS2
Here are the commands for implementing HA on the standby device, ACOS2. Most of the commands are the same as those
on ACOS1, with the following exceptions:
• The HA ID is 2.
• The HA priority is 1.
• The session synchronization (conn-mirror) IP address is the address of the Active ACOS device. (On the Active ACOS
device, the session synchronization IP address is the address of the Standby ACOS device.)
ACOS2(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.
synchronize.
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 5 on page 386.
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 global configuration level of the CLI:
ha l3-inline-mode
2. To enable CPU processing on an interface, use the following command at the configuration level for the interface:
cpu-process
If the interface is part of a trunk, use the command at the interface configuration level for the trunk.
Commands on ACOS1
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.
ACOS1(config)#interface ethernet 1
ACOS1(config-if:ethernet1)#enable
ACOS1(config-if:ethernet1)#interface ethernet 2
ACOS1(config-if:ethernet3)#cpu-process
ACOS1(config-if:ethernet5)#exit
ACOS1(config)#vlan 100
ACOS1(config-vlan:100)#untagged ethernet 1 to 4
ACOS1(config-vlan:100)#router-interface ve 100
ACOS1(config-vlan:100)#exit
ACOS1(config-vlan:5)#untagged ethernet 5
ACOS1(config)#interface ve 100
ACOS1(config-if:ve100)#ip address 172.168.10.2 /24

ACOS1(config-if:ve100)#interface ve 5
ACOS1(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.
The following command enables Layer 3 inline HA mode.
ACOS1(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 configuration. (For example, if you change the HA priority so that the other ACOS device has higher prior-
ity, this will trigger a failover, but only if pre-emption mode is enabled.)
The following command specifies the IP address of the other ACOS device, to use for session synchronization.
The following command configures the floating IP address for the real servers to use as their default gateway address.
The following commands configure a health method, real servers, a server group, and a VIP for an HTTP service.

Commands on ACOS2
Here are the commands for implementing HA on ACOS2. Most of the commands are the same as those on ACOS1, 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 ACOS1. (On ACOS1, the session synchronization IP
address is the address of ACOS2.)
ACOS2(config)#interface ethernet 1
ACOS2(config-if:ethernet5)#exit
ACOS2(config-vlan:100)#untagged ethernet 1 to 4
ACOS2(config-vlan:5)#untagged ethernet 5
ACOS2(config)#interface ve 100
ACOS2(config-if:ve100)#interface ve 5
ACOS2(config-if:ve5)#exit
ACOS2(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 previous sections.
NOTE: Failover based on HA interface state is also optional, and is described in other sections in
this chapter.
VLAN-Based Failover Example

To configure VLAN-based failover, use either of the following methods.
(For a description of the feature, see “VLAN-Based Failover” on page 390.)
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 try-
ing 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 ha check vlan command at the global configuration level of the CLI.
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 391.)
Using the GUI

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

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 by using the ha check route command.
For more information, see “ha check route” in the Command Line Interface Reference.
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 priority 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 subtracted from the HA priority
value for each HA group.
ACOS(config)# ha check route 10.10.10.0 /24 priority-cost 10 protocol dynamic distance 10
The following commands configure HA route awareness for an IPv6 route to 3000::/64. Based on the combination of these
commands, if the IPv6 route table does not contain any routes to the destination, 105 is subtracted from the HA priority of
each HA group.
If the IPv6 route table does contain a static route to the destination, but the next-hop gateway is not 2001::1, the ACOS
device subtracts only 5 from the HA priority of each HA group.
ACOS(config)# ha check route 3000::/64 priority-cost 100

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

To configure VIP-based failover, use either of the following methods.
These procedures apply specifically to the VIP-based failover parameters. You also need to configure HA global and interface
parameters. See “Configuring Global HA Parameters” on page 408 and “Configuring HA Interfaces” on page 408.
(For a description of the feature, see “VIP-Based Failover” on page 392.)
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 408.
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:
1. Use the ha-group command at the virtual server configuration level to assign the virtual server to the specified HA
group.
2. Use the ha-dynamic to enable VIP-based failover.
The following command configures HA group 6 on AX-1 and assigns priority 100 to the group:
ACOS-1(config)# ha group 6 priority 100
The following command enables HA pre-emption. HA pre-emption must be enabled in order for failover to occur based on
HA group priority changes.
ACOS-1(config)# ha preemption-enable
The following command configures a floating IP address and assigns it to HA group 6:
ACOS-1(config)# floating-ip 192.168.10.1 ha-group 6
The following commands assign virtual server VIP2 to HA group 6 and enable VIP-based failover for the virtual server. (For
simplicity, this example does not show configuration of the real servers or non-HA virtual server options.)
ACOS-1(config)# slb virtual-server VIP2 192.168.10.22

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

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

To force HA groups to change from Active to Standby status, use the ha force-self-standby command at the global
configuration level of the CLI:
The following command forces HA group 1 to change from Active to Standby status:
ACOS(config)# ha force-self-standby 1
Enabling Session Synchronization

Session synchronization backs up live client sessions on the Backup ACOS device.
To enable session synchronization:
• Globally enable the feature, specifying the IP address of the other ACOS device in the HA pair.
• Enable the feature on individual virtual ports. Session synchronization is supported for Layer 4 sessions.
NOTE: HA session synchronization is required for persistent sessions (source-IP persistence, and
so on), and is therefore automatically enabled for these sessions by the ACOS device.
Persistent sessions are 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.
Manually Synchronizing Configuration Information
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 synchronization is not sup-
ported for this service type.
6. Click OK to redisplay the Port tab.
7. Click OK again.
Using the CLI

To globally enable session synchronization, use the ha conn-mirror command at the global configuration level of the CLI:
To enable session synchronization on a virtual port, use the same command at the configuration level for the port.
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 vserver)# port 80 tcp
ACOS(config-slb vserver-vport)# ha-conn-mirror

NOTE: This section describes how to manually synchronize the configuration. You can use the
ACOS Virtual Chassis System (aVCS) to automate configuration synchronization. See
“Configuration Synchronization without Reload” on page 501.
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.
Manual Session Sync Requirements

Session synchronization (connection mirroring) is required for manual config sync. Config sync uses the session synchroniza-
tion link. To enable session synchronization, see “Enabling Session Synchronization” on page 433.
SSH management access must be enabled on both ends of the link.
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 • SLB

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

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

• Hostname • Interface settings
• MAC addresses • OSPF or IS-IS settings
• Management IP addresses • ARP entries or settings
• Static Trunks or VLANs
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 2 lists the cases in which reload is automatic, optional, or not allowed.
TABLE 2 Reload of Target ACOS Device After Config-Sync

Status of Target ACOS
Admin Role Device* Target Config Reload?
Root or Super User (Read-Write) Standby startup-config Automatic
running-config Automatic
Active startup-config Optional†
Not reloaded by default
running-config Automatic
Partition Write Standby startup-config Not Allowed
running-config Not Allowed
Active startup-config Not Allowed
running-config Not Allowed
*. “Active” means the ACOS device is currently the active device for at least one HA group.
†. If the target ACOS device is not reloaded, the GUI Save button on the Standby ACOS device does not blink to indicate unsaved
changes. It is recommended to save the configuration if required to keep the running-config before the next reboot.
An admin who is logged on with Root or Read-Write (Super Admin) privileges can synchronize for all Role-Based Administra-
tion (RBA) partitions or for a specific partition.
An admin who is logged on with Partition Write privileges can synchronize only for the partition to which the admin is
assigned, and can only synchronize to the startup-config on the other device. The with-reload and to-running-config
options are not available to Partition Write admins.
Caveats
Before synchronizing the Active and Standby ACOS devices, verify that both are running the same software version. HA con-
figuration synchronization between two different software versions is not recommended, since some configuration com-
mands in the newer version might not be supported in the older version.
The HA configuration synchronization process does not check user privileges on the Standby ACOS device and will synchro-
nize 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.
Tip for Ensuring Fast HA Failover
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 > Config Sync.
2. In the User and Password fields, enter the admin username and password credentials for access to the other ACOS
device.
3. Configure the other fields on this page as desired; refer to the GUI online help for more information about each field.
4. Click OK.
Using the CLI

The ha sync commands are available at the global configuration level of the CLI.
• To synchronize data files and the running-config, use the ha sync all command.
• To synchronize the Active ACOS device’s startup-config to the Standby ACOS device’s startup-config or running-con-
fig, without also synchronizing the data files, use the ha sync startup-config command.
• To synchronize the Active ACOS device’s running-config to the Standby ACOS device’s running-config or startup-con-
fig, without also synchronizing the data files, use the ha sync running-config command.
• To synchronize the data files by copying the Active ACOS device’s data files to the Standby ACOS device, use the ha
sync data-files command.
For more detailed information, see “ha sync” in the Command Line Interface Reference.

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 configuration for each router, and use an ICMP health moni-
tor 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 Balancing Guide.)
2. Create an SLB real server configuration for each gateway. If you plan to use a custom ICMP health monitor (previous
step), apply the health monitor to the server.
Perform these steps on both ACOS devices in the HA pair.
NOTE: The ACOS device also has an HA gateway health checking feature. This feature also uses
ICMP health monitors. However, if you use the HA 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
HA Status Indicators
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 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
• 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-con-
fig.
• Most recent config-sync – The system time and date when the most recent configuration change was made.
If the ACOS device is configured with private partitions, separate configuration status information is shown for each partition.
Viewing HA Status in the GUI

The top bar of the GUI always shows one of the following HA or VRRP-A statuses:
• Active
• Standby
• Not Configured
For more information, refer to the GUI online help.
Viewing HA Status in the CLI

HA status in the CLI can be viewed in two locations:
• HA Status in CLI Commands
Viewing Config-Sync Status
• HA Status in the CLI Prompt
HA Status in CLI Commands

The show ha commands (or show vrrp-a for VRRP-A configurations) can be used to view HA status and additional infor-
mation. For more information, see the Command Line Interface Reference.
HA Status in the CLI Prompt

You can configure the CLI prompt to show its HA status using the terminal ha-status command.
For more information about how to customize the CLI prompt to show HA status and other information, see “HA / VRRP-A /
aVCS Status in the CLI Prompt” in the Command Line Interface Reference.
For details on all configurable prompts and how they work in conjunction with one another, refer to “Configurable aVCS
Prompts” on page 519.

• Viewing Config Sync Status in the GUI
• Viewing Config-Sync Status in the CLI
Viewing Config Sync Status in the GUI

To view config sync status, navigate to Monitor Mode > System > HA > Status (or Monitor Mode > System > VRRP-A > Status
for VRRP-A configurations). The config sync status shows the sync status of the running config and startup config to and from
the peer device. In addition, config sync status for private partitions can also be viewed.
For more information, refer to the GUI online help.
Viewing Config-Sync Status in the CLI

For config-sync status, use the show config-sync command.
In the following examples, ACOS1 is the local device and ACOS2 is the peer.
Config-Sync Status for New and Reloaded/Rebooted Devices

In the case of a new device with no config-sync configuration, or when a device is reloaded or rebooted, the sync status of
the running-config will always be reset and the sync status will be “N/A”. For example:
ACOS1(config)# show config-sync detail

Partition Name Sync Status for running-config and startup-config
------------------------------------------------------------------------------------
shared (running-config)N/A
shared (startup-config)N/A
shared (running-config)N/A
This means that if you already have config-sync configured and the device is rebooted, you will have to reconfigure the con-
fig-sync settings in the running-config. The sync status of the startup-config persists through any reload or reboot operation;
and will not be changed by the reload or reboot process.
Config-Sync Status After HA Sync

The following commands sync both the running-config and startup-config from the local device to the peer, then view the
config-sync status:
ACOS1(config)# ha sync running-config to-running-config 192.168.216.202

Running config will be sync’ed, but it has been changed.
Do you want to save before sync’ing? [y/n]:y
Running-config saved.
User name []? admin
Password []?
Sync to 192.168.216.202 succeeded!
ACOS1(config)# ha sync startup-config to-startup-config 192.168.216.202
User name []? admin
Password []?
ACOS1(config)# show config-sync
------------------------------------------------------------------------------------
shared (running-config) sync to ip 192.168.216.202 at 20:32:05 IST Wed May 18 2016
shared (startup-config) sync to ip 192.168.216.202 at 20:32:27 IST Wed May 18 2016
The output from the peer device (ACOS2) shows that both the running-config and startup-config are synced from ACOS1:

------------------------------------------------------------------------------------
shared (running-config) is synced from ip 192.168.216.201 at 20:31:54 IST Wed May
18 2016
shared (startup-config) is synced from ip 192.168.216.201 at 20:32:13 IST Wed May
18 2016
Config-Sync Status After Changes are Made in the Running-Config

If any configuration changes are made in the running-config on ACOS1, the status will change. Suppose we make a configu-
ration change on ACOS1 (for example, specify a VRRP-A failover policy template), then view the config-sync status again:
ACOS1(config)# vrrp-a fail-over-policy-template temp

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

Write configuration to primary default startup-config
[OK]
------------------------------------------------------------------------------------
18 2016
shared (startup-config) not synced because write memory at 20:37:50 IST Wed May
18 2016
The sync status of the startup-config is now “not synced” because of the change.
Config-Sync Status When Synced From the Peer Device

Suppose that later on, we sync the running-config from ACOS2 to ACOS1. Below is the detail output from the local device
(ACOS1) after this happens:

------------------------------------------------------------------------------------
shared (running-config) sync to ip 192.168.216.202 at 08:19:37 IST Fri May 13 2016
shared (running-config) is synced from ip 192.168.216.202 at 18:40:39 IST Mon May
16 2016
Viewing Detailed Config-Sync Status

The detail option shows when the “sync to” status changed to the “is synced from” status, or vice versa.
In this example, the configuration is synced from ACOS2 to ACOS1:
ACOS2(config)# ha sync running-config to-running-config 192.168.216.201

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

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

------------------------------------------------------------------------------------
18 2016
shared (startup-config) not synced because write memory at 20:37:50 IST Wed May
18 2016
18 2016
18 2016
The highlighted lines above show the previous sync status of both the running-config and startup-config on ACOS1 before
the sync from ACOS2 to ACOS1.
For more information, see “show config-sync” in the Command Line Interface Reference.
HA To VRRP-A Migration
This chapter describes how to use the vrrp-a ha-migration CLI command to automatically migrate your existing HA
configuration to VRRP-A configuration. (See “VRRP-A High Availability” on page 293 for more information).
In the HA scenario, one ACOS device serves as an “Active” device, while a second ACOS device serves as a “Standby” device.
Issue the vrrp-a ha-migration command on the Active and the Standby ACOS device to automatically convert the
existing HA configuration into a VRRP-A configuration. Once your conversion is complete, VRRP-A will be operational after
you reload both devices.
NOTE: The vrrp-a ha-migration command must be run independently on both the
Active and the Standby devices.
Follow these steps before you launch the migration script.
• Back up your current configuration. Though the script creates its own backup of the existing configuration, it is rec-
ommended that you create a copy of the existing configuration. Store this file in case you need to revert to your orig-
inal 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 man-
ually 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 445.
For high-level details on HA and VRRP-A, refer to Table 4 on page 447. For details on commands migrated from HA to
VRRP-A, refer to Table 5 on page 450.
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 configuration 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.
Comparison of VRRP-A and HA
• 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 dis-
played on your screen and you will be asked to manually migrate your configuration.

VRRP-A includes numerous improvements over the HA feature available in AX releases earlier than 2.6. The older implemen-
tation 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 config-
uration from HA to VRRP-A. However, if you use RBA partitions or plan to use aVCS, you might want to consider
migrating to VRRP-A.
Table 3 compares the features in VRRP-A and the earlier implementation of HA. .
TABLE 3 Feature Comparison – VRRP-A and HA

Feature VRRP-A Earlier Implementation of HA
Private partition Each private partition in which Layer 3 virtualiza- IP resources are shared with other partitions and
support tion is enabled has its own VRID. can be added to an HA group for backup.
IP resources belonging to the partition are auto-
matically added to the VRID.
Capacity Up to 8 devices can provide redundancy as a set. Maximum of 2 devices can provide redundancy.
The active device for a resource can have up to 7 An active device can have 1 other device as a
other devices available as potential standbys. standby.
Configuration Only minimal configuration is required. On each Configuration of HA is more complex than con-
requirements device in the VRRP-A set: figuration of VRRP-A.
1. Specify the device ID.
2. Enable VRRP-A.
TABLE 3 Feature Comparison – VRRP-A and HA (Continued)

Feature VRRP-A Earlier Implementation of HA
IP resources that • Virtual server IP addresses (VIPs) • Virtual server IP addresses (VIPs)
can be backed • Floating IP address used as default gateway by • Floating IP address used as default gateway by
up downstream devices downstream devices
• IPv4 NAT pools • IPv4 NAT pools
• IPv6 NAT pools • IPv6 NAT pools
• IPv4 static range lists and individual mappings • IPv4 static range lists and individual mappings
for inside source NAT for inside source NAT
• Source address for IPv6 router advertisements
• FWLB virtual firewall address
Configuration If A10 Networks Virtual Chassis System (aVCS) is Must be performed manually
synchronization configured and enabled, it automatically per-
forms configuration synchronization. Otherwise,
configuration synchronization must be per-
formed manually.
See the following:
• “Automated Configuration Synchronization”
on page 465
• “Manually Synchronizing the Configuration”
on page 313
Session synchro- Must be enabled manually on individual virtual Must be enabled manually on individual virtual
nization ports ports
Applies only to Layer 4 (TCP or UDP) sessions Applies only to Layer 4 (TCP or UDP) sessions
Peer automatically selected based on current Requires manual configuration of peer IP address
VRRP-A priority
Failover triggers Failover can be triggered on individual VRID Failover can be triggered on individual HA group
basis, manually or dynamically. basis, manually or dynamically.
(See “Failover” on page 301.)
Pre-emption Supported Supported
Enabled by default Disabled by default
Configurable threshold No threshold
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 4 Implementation Differences between HA and VRRP-A

Configuration High Availability VRRP-A
HA Connection Mirror You must indicate an IP address for an HA Con- The peer IP address is automatically
nection Mirror (ha conn-mirror ip 1.1.1.1). learned.
TABLE 4 Implementation Differences between HA and VRRP-A

Configuration High Availability VRRP-A
Port Tracking Provides server and router interface tracking. Tracking is based on priority.
Command Support HA supports the following commands: VRRP-A does not support these 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
Migrating from HA to VRRP-A

The following section describes how to migrate from HA to VRRP-A. For an example of an actual HA to VRRP-A conversion,
see Table 5 on page 450.
Use the GUI to Migrate from HA to VRRP-A

This feature is not supported in the GUI at this time.
Use the CLI to Migrate from HA to VRRP-A

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:
1. From the configuration mode, execute the vrrp-a ha-migration command on the ACOS device designated as the
Standby device:
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 445 or Table 5 on page 450. You must remove the exceptions (HA configura-
tion statements) before reissuing the vrrp-a ha-migration command.
2. From the privileged exec mode, “ACOS-Active#, reload the standby ACOS device. Issue the reload command. You can-
not issue this command in configuration mode.
NOTE: Make sure that you do not issue the write-memory command. Before the ACOS device
commences the reload, be sure to answer no to the following question:
System configuration has been modified. Save? [yes/no]:
When it reboots successfully, this device will automatically be placed in standby state. For it to become the active
device, from the global configuration mode, issue the no vrrp-a force-self-standby command.
Your HA configuration on the Standby device is now complete. Repeat the same steps on the Active device.
Once both the Active and the Standby ACOS devices are reloaded, verify that you are successfully able to use VRRP-A as
opposed to HA and that everything is working as expected.
3. To check your VRRP-A configuration, issue the show vrrp-a command or the show vrrp-a config command. See
if you can successfully access other VIPs.
CLI Example
The following example shows successful completion of the migration command on an Active ACOS device:
ACOS-Active(config)#vrrp-a ha-migration
ACOS boots from hard disk primary. VRRP-A migration only effects on hard disk primary.
Migrate from HA to VRRP-A therein? (y/n) y
HA Migration Starts...
89 lines of configuration are processed
Replacing old config file with new config file.
Configure file has been replaced!
HA configuration has been replaced by VRRP-A configuration! Please reload the system to
finalize the migration!
Warning: After reloading, all vrids in all partitions will be forced standby!
Please manually remove forced-standby setting with command: no vrrp-a force-self-standby
all-partitions
Before you reload the ACOS device, check your running configuration to see that no VRRP-A
configuration exists:
ACOS-Active(config)#show running | sec vrrp-a
ACOS-Active(config)#
From the privileged EXEC level, reload your ACOS device:
ACOS#reload
System configuration has been modified. Save? [yes/no]:no
Do you wish to proceed with reload? [yes/no]:yes
ACOS is reloading now. Please wait....

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

vrrp-a device-id 2
vrrp-a set-id 1
vrrp-a enable
vrrp-a vrid default
tracking-options
vrrp-a vrid 1
priority 100
tracking-options
vrrp-a interface ethernet 1 router-interface
vrrp-a interface ethernet 2 server-interface no-heartbeat
vrrp-a interface ethernet 3 vlan 100
TABLE 5 Actual HA to VRRP-A Conversion

HA VRRP-A Migration Example (HA first, followed by VRRP-A)
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 vrrp-a vrid num ha group 1 priority 100
num priority num vrrp-a vrid 1
priority 100
floating-ip ip-addr ha- vrrp-a vrid num floating-ip 1.1.1.10 ha-group 1
group num floating-ip num vrrp-a vrid 1
ha interface ethernet vrrp-a interface ethernet ha interface
port-num [router-inter- port-num [router-interface | ha interface ethernet 1 vlan 2
face | server-interface | server-interface | both] ha interface ethernet 1 no-heartbeat
both] [no-heartbeat | [no-heartbeat | vlan vlan- ha interface ethernet 1 server-interface
vlan vlan-id] id] ha interface ethernet 1 router-interface
The VRRP-A tracking options are cre- vrrp-a interface ethernet 1 vlan 2
ated per VRID. The migration script vrrp-a interface ethernet 1 no-heartbeat
will place the configuration under vrrp-a interface ethernet 1 server-
interface
each VRID. If an interface is under a
vrrp-a interface ethernet 1 router-
trunk, only the trunk will be tracked.
interface

ha check vlan vlan-id track options ha check vlan 2 timeout 20
timeout seconds vlan vlan-id timeout seconds vrrp-a vrid 1
priority-cost num tracking-options
ha check gateway ipaddr gateway ipaddr priority-cost ha check gateway 1.1.1.1
num 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- vrrp-a hello-interval 100- ha time-interval 5
units ms-units vrrp-a hello-interval 5
ha timeout-retry-count vrrp-a dead-timer num ha timeout-retry-count 10
num 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- Not supported None
standby
Global Parameters for L2 Inline Mode
ha inline-mode [pre- Not supported None
ferred-port]
ha restart-time 100-msec- Not supported None
units
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- Not supported None
id
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
slb virtual-server v1 1.1.1.3
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 Not supported None
ha-group group-id
Parameters for Real Ports

ha-group group-id Not supported None
Parameters for FWLB
ha-priority-cost weight Not supported None
ha-group group-id
Parameters for IP NAT
Options with ip nat pool, ip nat pool pool-name start- ip nat pool abc 1.1.1.20 1.1.1.30 netmask
ipv6 nat pool, or ip nat ing-ip-nat pool-address end- /24 ha-group-id 1
ing-ip-nat pool-address ip nat pool abc 1.1.1.20 1.1.1.30 netmask
netmask pool-mask vrid vrid- /24 vrid 1
num
Parameters for IP Routes
ha check route des/mask This appears under track options: ha check route 1.1.1.1 /24 gateway
priority-cost weight 2.2.2.2 priority-cost 10
route dest/mask priority-
[gateway ip-addr] cost weight [gateway ipaddr] vrrp-a vrid 1
[protocol {any | static | [protocol {any | static | tracking-options
dynamic}] [distance num] dynamic}] [distance num] route 1.1.1.0 255.255.255.0
gateway 2.2.2.2 priority-cost 10
Reverting to HA from VRRP-A

To restore an existing HA configuration, you can revert from VRRP-A configuration using the vrrp-a ha-migration-
restore command. This command will only work if you have previously migrated your HA configuration to VRRP-A using
the migration script.
Use the GUI to Revert to HA from VRRP-A

This feature is not supported in the GUI at this time.
Use the CLI to Revert to HA from VRRP-A

To replace the VRRP-A configuration with an HA configuration, use the vrrp-a ha-migration-restore command:
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!
Part VIII
ACOS Virtual Chassis Systems (aVCS)

• “Overview of aVCS” on page 455
• “Deploying a Virtual Chassis” on page 473
• “Adding a Device to a Virtual Chassis” on page 495
• “Configuration Synchronization without Reload” on page 501
Overview of aVCS
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 vir-
tual chassis, and are managed by the vMaster.
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 con-
troller 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.
For deployment and upgrade instructions, see the following:
• “Deploying a Virtual Chassis” on page 473
• “Upgrading a Virtual Chassis” on page 494
• “Adding a Device to a Virtual Chassis” on page 495
• “Configuration Synchronization without Reload” on page 501
CAUTION: If you use the system-reset command to restore an ACOS device to its factory default
state, the command affects all ACOS devices in the virtual chassis. The command erases
any saved configuration profiles (including startup-config), as well as system files such
as SSL certificates and keys, aFleX policies, black/white lists, and system logs. The man-
agement IP address and admin-configured admin and enable passwords are also
removed. The only workaround is to reload the system from a saved configuration or
configure the device once again.
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.
An aVCS virtual chassis contains multiple ACOS devices (Figure 1). 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 operations:
• Synchronize configurations
• Synchronize certificates
• Synchronize keys
• Synchronize aFleX policies
• Synchronize black/white lists
• Synchronize code versions
FIGURE 1 Virtual Chassis – Multiple Physical Devices
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 2.
FIGURE 2 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 example, if you create a new SLB server, the vMaster sends the server to the running-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 pro-
files. This includes the startup-config and any custom configuration profiles.
Software Version Management

The vMaster also ensures that each device is running the same software version. For example, in Figure 3, 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 3 vMaster - Software Upgrades on Other Devices
vMaster Election
Likewise, aVCS checks to ensure that the vBlade has the latest configuration. 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.
VRRP-A
The current release supports VRRP-A, providing device redundancy. VRRP-A is the A10 Thunder Series and AX Series imple-
mentation of the High Availability protocol that is completely different from the industry-standard implementation of Virtual
Router Redundancy Protocol (VRRP). For purposes of operational familiarity, it borrows concepts from VRRP, but is signifi-
cantly different from VRRP. VRRP-A will not inter-operate with VRRP.
In this release, VRRP-A, a High Availability implementation, is mutually exclusive of the HA feature and is configured sepa-
rately and not as part of the HA functionality.
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 3 virtualization capabilities.
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 Availability (HA) feature
instead.
For more information on VRRP-A, refer to “VRRP-A High Availability” on page 293.
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 HA feature instead.
High Availability
High Availability (HA) is an ACOS feature that provides ACOS device-level redundancy to ensure continuity of service to cli-
ents. 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 (HA)” on page 375.
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 vir-
tual chassis can contain a maximum of 8 devices.
Configuration Preferences
To use redundancy with Layer 3 virtualization capabilities, use VRRP-A. HA does not support Layer 3 virtualization.
For transparent mode deployments, configure HA, as VRRP-A does not support transparent mode.
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.
vMaster Election
To understand when a vMaster will take over as the Active device, it is necessary to understand different configuration sce-
narios that impact vMaster selection for aVCS, for HA, for VRRP-A, and for aVCS with HA or VRRP-A:
• aVCS First Time Deployment—With aVCS, when a vMaster and multiple 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 vMas-
ter 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 vMaster. 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 independent 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 config-
ures the other device, however, the devices are no longer stand-alone devices. Instead, the HA configuration will
place one device as the Active device and the other as the Standby device. In this case, the device with the higher pri-
ority will be the designated as the vMaster.
• VRRP-A Active/Standby Device Selection—When VRRP-A is configured, the Active device selection is based on
two factors, weight and priority, before electing an Active device that will have several Standby devices ready to take
over that role. An ACOS device will become an Active or Standby device depending on the weight or priority of that
device. The weight of an ACOS device will always take precedence over the priority. If we have a higher weight but a
lower priority, the ACOS device with the higher weight will be the Active. If the weight of the devices are equal, the
ACOS device with the higher priority will become the Active ACOS device. If the weight and the priority of the
devices are equal, the ACOS device will the lowest VRRP-A device ID will be the Active ACOS device.
As a ACOS device user, configure VRRP-A using VRRP-A failover templates and VRRP-A Tracking options to adjust the
weight (using failover templates) or priority (using global tracking options) of an ACOS device and elect an Active
device.
For details on VRRP-A tracking options, refer to “VRRP-A High Availability” on page 293. For details on VRRP-A failover
templates, refer to, “VRRP-A Policy-Based Failover Template” on page 357.
• 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 358. 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:
vMaster Election
• Priority – The device with the highest configured aVCS priority is elected to be the vMaster. If you boot one of the
devices first and allow it to become the vMaster, the device remains the vMaster when the other devices join the vir-
tual chassis, even if the configured priority is higher on another device. This is due to the dynamic priority value
assigned by aVCS. Figure 6 shows an example.
• 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 4 and Figure 5 show examples for each of these parameters. In these examples, all devices in the virtual chassis are
booted at the same time.
FIGURE 4 vMaster Election in First-Time Deployment - Same Priority Value on each Device
vMaster Election
FIGURE 5 vMaster Election in First-Time Deployment - Different Priority Values Configured
Figure 6 shows an example of dynamic priority value assigned by aVCS.
vMaster Election
FIGURE 6 vMaster Election in First-Time Deployment - one device booted first
Dynamic Priority
The configurable aVCS priority is a static value in each device’s configuration. After a virtual chassis becomes active, another
priority value, the dynamic priority, becomes the most important parameter when electing the vMaster The device with the
highest dynamic priority always becomes the vMaster
The dynamic priority adds stability to the virtual chassis, by consistently using the same device as vMaster whenever possi-
ble. Once a device becomes vMaster, its dynamic priority ensures that it will remain the vMaster, even if another device has a
higher configured priority. For example, if the vMaster becomes unavailable and a vBlade transitions to vMaster, the new
vMaster remains in control even if the previous vMaster rejoins the virtual chassis.
The dynamic priority is not configurable. However, you can force a vBlade to become the vMaster. (See “Forced vMaster Take-
over” on page 465.)
Heartbeat Messages
At regular intervals (the heartbeat time interval), the vMaster sends heartbeat messages to each of the vBlades, to inform
them that the vMaster is still up, as shown in Figure 7.
vMaster Election
FIGURE 7 Heartbeat Messages
If a vBlade does not receive a heartbeat message within a specified amount of time (heartbeat dead interval), the vBlade
changes its state from vBlade to vMaster-candidate, and engages in the vMaster election process with the other devices that
are still up.
The default heartbeat time is 3 seconds. The default heartbeat dead interval is 10 seconds. Both parameters are configurable.
vMaster Election
Split Chassis
If one or more vBlades lose contact with the vMaster, the vMaster remains in control for the vBlades that can still receive the
vMaster’s heartbeat messages. However, the other vBlades use the vMaster election process to elect a new vMaster This
results in two separate virtual chassis (a “split chassis”), as shown in Figure 8.
FIGURE 8 vMaster Election - split chassis
After the links among the disconnected devices are restored, the devices again use the vMaster election process to elect a
vMaster Generally, the vMaster that was in effect before the virtual chassis divided continues to be the vMaster after the vir-
tual chassis is rejoined, based on the device’s dynamic priority value. (See “Dynamic Priority” on page 462.)
Forced vMaster Takeover

You can force a vBlade to take over as vMaster, without changing the vMaster-election priority values configured on the
devices. For example, you can force a vBlade to take over the vMaster role, without changing the aVCS profiles of any of the
devices.
Automated Configuration Synchronization
FIGURE 9 Forced vMaster Takeover

aVCS automatically synchronizes configuration information within the virtual chassis. Configuration changes are synchro-
nized in real-time as they occur.
All configuration changes are synchronized, even changes to device-specific parameters such as hostnames and IP
addresses. aVCS configuration synchronization ensures that each device in the virtual chassis has a complete set of configu-
ration information for itself and for each of the other devices. For example, configuration synchronization ensures that each
device has the complete aVCS configuration for the virtual chassis (Figure 10).
FIGURE 10 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 example, in a working
configuration, the vcs enable command normally would appear in the configuration
for each device, under the vrrp-a commands, and the enable command would appear
among the aVCS commands for each device.
Common parameters, such as SLB parameters, are shared by all devices in the virtual chassis and do not have a device ID
(Figure 11).
FIGURE 11 Common Parameters
Manual Configuration Synchronization
Interface parameters are unique to each device and include the aVCS device number (Figure 12).
FIGURE 12 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 configuration to specific devices. For more information on man-
ual synchronization using HA, refer to “Manually Synchronizing Configuration Information” on page 434. For more informa-
tion on manual synchronization using VRRP-A, refer to “Manually Synchronizing the Configuration” on page 313.
Software Image Synchronization

In addition to the configuration repository, each device in the virtual chassis also has a software image repository. When a
new or rebooted device joins the virtual chassis as a vBlade, the device compares its running software image version with
the version running on the vMaster If the version on the vMaster is newer, the vBlade downloads the image from the vMas-
ter, then reboots to place the image into effect.
When a vBlade upgrades in this way, the new image replaces the older image, in the same image area. For example, if the
vBlade boots the older image from the primary image area on the hard drive, the upgrade image downloaded from the
vMaster replaces the image in the primary image area.
Virtual Chassis Management Interface
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 connection goes to the vMaster You can make config-
uration changes only on the vMaster The vMaster automatically sends the changes to the vBlades.
If necessary, you can change the context of the management session to a specific vBlade. To change the management con-
text to the vBlade, use the 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.
The management session will change from the vMaster to the specified vBlade. For additional information, refer to “aVCS CLI
Session Management Enhancements” on page 484.
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 pri-
mary image area of the hard disk or solid state drive (SSD) on each device.
Requirements
Memory Requirements for aVCS with Layer 3 Virtualization

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

Number of Partitions with Layer 3 Virtualization Memory Required*
32 partitions 6 GB memory
*. This assumes that the default system resource-usage settings are in effect. If you change the system resource-usage settings, the
memory requirements also may differ.
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 2 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” on page 473.
The screens show the parameters that are described in Table 2.
NOTE: aVCS reload is required to place any aVCS-related configuration changes into effect.
TABLE 2 aVCS Parameters

Virtual Chassis Parameters
Set ID High availability domain. All devices in the aVCS virtual chassis must For set ID, use 1-7.
also belong to the same VRRP-A set.
If using HA, use 1-2 for the
Note: The set ID does not automatically configure VRRP-A on the device ID.
devices in the virtual chassis. VRRP-A requires additional configuration.
Default: not set
(See “VRRP-A High Availability” on page 293.)
[no] vrrp-a set-id num
or
[no] ha id {1 | 2} [set-id num]
Config Mode > HA > Setting > HA Global - General
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 current vMaster of the Default: not set
virtual chassis.
Up to 6 floating IP addresses are supported.
aVCS automatically binds one of the device’s available 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 send vMaster-election Valid IPv4 multicast
address traffic. address
[no] vcs multicast-ip ipaddr Default: 224.0.0.210
Multicast port Protocol port from which devices in the virtual chassis send vMaster- 1-65535
election traffic. Default: 41217
[no] vcs multicast-port portnum
aVCS Parameters
TABLE 2 aVCS Parameters (Continued)

SSL Secure Sockets Layer (SSL) for encryption of unicast traffic, such as con- Enabled or disabled
figuration synchronization traffic, between devices.
Default: disabled
This option does not apply to multicast traffic.
[no] vcs ssl-enable
Heartbeat time Number of seconds between transmission of keepalive messages from 1-60 seconds
interval the vMaster to vBlades.
Default: 3 seconds
[no] vcs time-interval seconds
Heartbeat dead Maximum number of seconds to wait for a keepalive message from 5-60 seconds
interval the vMaster before triggering vMaster re-election.
Default: 10 seconds
[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. Higher priority val- 1-255
ues are preferred over lower priority values. For example, priority value
Default: 0 (not set)
200 is preferred over priority value 2.
Note: This is only one of the parameters used during vMaster election.
See “vMaster Election” on page 458.
[no] priority num
Unicast port Protocol port used to create TCP connections between the vMaster 1-65535
and vBlades. This connection is used for configuration synchronization.
Default: 41216
[no] unicast-port portnum
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 vMaster election. The
same interface is also used for configuration 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 vMas-
ter 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 Seconds after which the vMaster will be maintained.
maintenance
Deploying a Virtual Chassis
This chapter describes how to deply 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 494.
1. On the ACOS device to be used as the vMaster, configure aVCS. (See “Details for step 1” on page 473.)
NOTE: If you plan to use Layer 3 virtualization, do not configure it yet.
2. After completing aVCS configuration on the vMaster, enable aVCS on the vBlades, and configure aVCS-related parame-
ters 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 synchronization from vMaster to vBlades. After this,
subsequent configuration changes on the vMaster are automatically be synchronized to the vBlades.
5. If you plan to use Layer 3 virtualization, configure it on the vMaster
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 (HA)” on page 375.)
3. Enable aVCS.
4. Configure aVCS device settings:
• vMaster-election interface – Ethernet interface(s) to use for vMaster election. Generally, these are the interfaces con-
nected to the other devices in the virtual chassis. The election interfaces for devices in an aVCS virtual chassis must
be in the shared partition. Use of an L3V private partition’s interface as an aVCS election interface is not supported.
• (Optional) vMaster-election priority – If you want a specific device to serve as the vMaster for the virtual chassis, set
that device’s aVCS priority to 255. You can leave the priority set to its default value on the other devices, which will
become vBlades.
To allow aVCS to select the vMaster based on aVCS device ID, leave the vMaster-election priority on all devices
unchanged.
NOTE: It is recommended not to disable any of the vMaster election interfaces. Doing so can
interrupt communication between vMaster and vBlade, and cause the vBlade to reload.
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 single, 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.

The following window appears:
a. When the local device has been set, enable aVCS by clicking on the aVCS Enabled check box. When you click on
Enabled, an additional 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 config-
uration session, you must clear the session before you can continue with the configura-
tion 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. Indi-
cate 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 Election 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, you can 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 window 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 avail-
able 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 configura-
tion 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 configura-
tion 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 commands:
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 commands:
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:
ACOS#configure
ACOS(config)#vrrp-a set-id 1
ACOS(config)#vrrp-a device-id 1
The following command enables aVCS:
ACOS#vcs enable
The following command configures the management address for the virtual chassis:
Forcing vMaster Takeover
ACOS(config)#vcs floating-ip 192.168.100.169 /24
The following commands configure the aVCS profile for the device:
ACOS(config)#vcs device 1
ACOS(config-vcs-dev)#enable
ACOS(config-vcs-dev)#interfaces management
ACOS(config-vcs-dev)#priority 125
ACOS(config-vcs-dev)#exit
ACOS(config)#vcs reload
ACOS-2#configure
ACOS-2(config)#vrrp-a set-id 1
ACOS-2#vcs enable
ACOS-2(config)#vcs floating-ip 192.168.100.169 /24
ACOS-2(config)#vcs device 2
ACOS-2(config-vcs-dev)#enable
ACOS-2(config-vcs-dev)#interfaces management
ACOS-2(config-vcs-dev)#priority 120
ACOS-2(config-vcs-dev)#exit
ACOS-2(config)#vcs reload
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.
2. Use the following command at the global configuration level of the CLI:
[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 matter which value within the range 1-255 you
specify. (See “Temp-priority Value” on page 483.)
Determining a Device’s aVCS ID
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 com-
mand at the configuration level for the aVCS device.)
• If there is a tie (more than one of the devices has the same highest configured aVCS priority), then the device with the
lowest device ID is selected.
In either case, the new vMaster is selected from among only the vBlades on which you enter the vcs vmaster-take-over
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 column of the Members section.
• If you are logged directly onto a device through its management interface or a data interface, the asterisk indicates
the device.
• If you are logged onto the floating IP address of the virtual chassis, the asterisk indicates the vMaster
(This is true unless you changed the device context of the management session. In this case, you are logged onto the
vBlade to which you changed the device context. See “Virtual Chassis Management Interface” on page 469.)
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
Displaying aVCS Information

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

Image Name Type
aximage_2_7_2-P1_67.tar.gz hd_pri
aximage_2_8_2_119.tar.gz hd_sec
-------- ext
aVCS CLI Session Management Enhancements

• CLI Message for Commands That Affect Only the Local Device
• Option To Configure aVCS Master Affinity to VRRP-A Active
• Option To Display Information for the Active VRRP-A Device
• Option to Disable Syncing of SNMP syscontact OID
• vMaster Maintenance Mode
• Configurable aVCS Message Buffer
CLI Message for Commands That Affect Only the Local Device
This release provides an option that displays a message when you enter a configuration command that applies to only the
local device. When this option is enabled, a message is displayed if you enter a configuration command that affects only the
local device, and the command does not explicitly indicate the device.
This enhancement is enabled by default and can not be disabled.
Local Device
The “local device” is the device your CLI session is on.
• If you log directly onto one of the devices in the virtual chassis, that device is the local device. For example, if you log
on through the management IP address of a vBlade, that vBlade is the local device.
• If you change the device context 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 command does not specify the device ID to which to
apply the configuration change. Therefore, the change is applied to the local device. In this example, the local device is
device 1 in the aVCS virtual chassis.
The message is not necessary if you explicitly specify the device, and therefore is not displayed:
ACOS(config)#mac-age-time 444 device 2
Notes
• For commands that access the configuration level for a specific configuration item, the message is displayed only for
the command that accesses the configuration level. For example:
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 facilitates trou-
bleshooting 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, eight (8) devices can be deployed in an 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 following excerpt of a running configuration displays
your aVCS VRID affinity configuration:
ACOS-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 displays 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 the show arp Command

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 fol-
lowing 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 the show virtual-server Command

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 provides an option to disable this synchronization, on an individual device basis.
NOTE: After configuring this option for an ACOS device, if you disable aVCS on that device, the
running-config is automatically updated to continue using the same syscontact value
you specified for the device. You do not need to reconfigure the syscontact on the
device after disabling aVCS.
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 operate, without attempt-
ing 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 command at the global configuration level of
the CLI:
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 vMaster 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 incremental 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 specify 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.
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 global configuration level of the CLI:
[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
Enabling Active Monitoring for Configuration Synchronization

The output of the show vcs summary command can be updated to show the status of whether or not the running config-
uration of devices in a virtual chassis is synchronized. To enable this feature, use the vcs monitor-cfgsync command in
the CLI.
Below is an example of the show vcs summary output without this feature disabled (this feature is disabled by default):
ACOS-01-vMaster[15/7](config)#show vcs summary
VCS Chassis:
VCS Enabled: Yes
Chassis ID: 10
Multicast IP: 224.0.0.210
Multicast Port: 41217
Version: 2.7.2-P5.b114
VCS Monitor Sync: DISABLE
Members(* means local device):

ID State Priority IP:Port Location Sync-State
------------------------------------------------------------------------------------------
---
2 vBlade 0 1.1.1.2:41216 Remote N/A
3 vMaster(*) 0 1.1.1.3:41216 Local
Total: 2
The “DISABLE” in the VCS Monitor Sync field and the “N/A” in the Sync-State column both indicate that the configuration
between the two devices in this chassis is not actively monitored.
These fields are updated after running the vcs monitor-cfgsync command:
ACOS-01-vMaster[15/7](config)#vcs monitor-cfgsync
ACOS-01-vMaster[15/7](config)#show vcs summary
VCS Chassis:
VCS Enabled: Yes
Chassis ID: 10
Multicast IP: 224.0.0.210
Multicast Port: 41217
Version: 2.7.2-P5.b114
VCS Monitor Sync: ENABLE
Members(* means local device):

ID State Priority IP:Port Location Sync-State
------------------------------------------------------------------------------------------
---
2 vBlade 0 1.1.1.2:41216 Remote SYNC
3 vMaster(*) 0 1.1.1.3:41216 Local
Total: 2
The “ENABLE” in the VCS Monitor Sync field indicates that the configuration between the two devices in this chassis is
actively monitored; the “SYNC” in the Sync-State column indicates that the configurations on both devices are synchronized.
If there is an error in the configuration; for example, someone deletes an object on the vBlade, thus causing the running con-
figurations to be out of sync, the Sync-State column will show a status of “UNSYNC”.
NOTE: Generally the configurations of vMaster and vBlade(s) should be consistent at any time,
as the aVCS synchronization mechanism is in charge of synchronizing configuration
changes from vMaster to vBlade(s) in a real-time manner. When there is an inconsistency
among the configurations of the vMaster and vBlade(s), it may mean that there is an
issue with the aVCS synchronization mechanism. You should contact A10 Support in
such situations.
If the Sync-State column shows a status of “UNSYNC” you can use the show vcs-monitor-cfglog to view the difference
between the vBlade and vMaster. For example:
ACOS#show vcs-monitor-cfglog
2015-05-18-14:24:36 master is inconsistent with blade 3(device id of vblade), the diff is
16a17
> enable-jumbo
38d38
< monitor buffer-usage 91750
...
The “>” marker indicates a configuration that exists in the vMaster, but not in the vBlade. The “<“ marker denotes a configura-
tion that exists in the vBlade, but not the vMaster.
After the discrepancies are listed, the running configuration of the vMaster is also displayed (not shown in this example).
Config Sync in HA or VRRP-A Environments

The show config-sync command shows the status of config-sync in an HA or VRRP-A environment:
ACOS#show config-sync
Running-config:indicate that sync local box's running-config to peer
Startup-config:indicate that sync local box's startup-config to peer
Partition Name Running-config Startup-config
----------------------------------------------------
shared Not-Sync Not-Sync
In this example, neither the running-config nor the startup-config are being synchronized with the device’s HA or VRRP-A
peer.
In the GUI, you can view the HA or VRRP-A config-sync status in the Monitor Mode->system->HA->Status or Monitor
Mode->system->VRRP-A->Status page:
Replacing a Device in a Virtual Chassis
Replacing a Device in a Virtual Chassis

By default, when you add an ACOS device to a virtual chassis that is already running, the device’s configuration information is
migrated to the vMaster.
However, if you are replacing a member of the virtual chassis by removing the ACOS device from the network and inserting
another ACOS device of the same model, you may want the vMaster to migrate the removed device’s configuration informa-
tion to the new device. In this case, when you reload aVCS on the new device, make sure to use the disable-merge option:
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:
ACOS#configure
ACOS#vcs enable
ACOS(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 chassis’ vMaster.
Upgrading a Virtual Chassis

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

Figure 13 shows the process that occurs when you add an ACOS device that is already configured to a virtual chassis.
NOTE: The configuration merge behavior described in this section is the default behavior. If
you want the vMaster to also remove the device-specific configuration information from
the new device, use the disable-merge option when you reload aVCS.
FIGURE 13 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 configuration to its virtual chassis configuration.
The vMaster then synchronizes the device’s configuration to the other vBlades as part of the normal configuration syn-
chronization process.
3. The vMaster sends its running-config to the device.
4. On the device, the vMaster running-config is saved as the device’s startup-config. To complete its aVCS reload, the
device loads its new startup-config. The device is now another vBlade in the virtual chassis.
Figure 14 shows more details about the configuration information present on the vMaster and on a configured ACOS device
added to the virtual chassis, before the configuration merge.
FIGURE 14 Configured Device Added to Virtual Chassis - before configuration merge
Figure 15 shows the results of the configuration merge.
FIGURE 15 Configured Device Added to Virtual Chassis - after configuration merge
Figure 16 shows the completed merge process, after the admin reloads aVCS.
FIGURE 16 Configuration with New Device Synchronized to all vBlades
Procedure for Adding a Device to a Virtual Chassis
Procedure for Adding a Device to a Virtual Chassis

To add an ACOS device that already has a configuration to an aVCS chassis:
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 virtual chassis.
b. View the virtual chassis status using the show vcs summary command
3. Connect the configured ACOS device to the Layer 2 network that contains the other virtual chassis members.
4. Configure aVCS settings on the new device and reload aVCS.
The following commands show how to configure aVCS settings on a configured ACOS device to be added to a virtual
chassis, and reload aVCS to activate the aVCS configuration:
ACOS#configure
ACOS#vcs enable
ACOS(config)#vcs reload
Following the reload of aVCS, the ACOS device joins the virtual chassis as a vBlade, and its configuration information is
migrated to the virtual chassis’ vMaster.
5. Verify that the device is now a member of the virtual chassis using the show vcs summary command.
NOTE: Do not use the disable-merge option when you reload aVCS. This option is used only
when replacing an existing virtual chassis member with a new device. (See “Following
the reload of aVCS, the ACOS device joins the virtual chassis as a vBlade, and its configu-
ration information is migrated to the virtual chassis’ vMaster.” 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 impact-
ing service.
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 deploy-
ments.
Figure 17 shows an example HA deployment that uses aVCS for automated configuration synchronization.
FIGURE 17 aVCS Used for Automated Configuration Synchronization
VRRP-A with aVCS Deployment Example

The following commands deploy the HA configuration shown in Figure 17. This example uses VRRP-A. If you plan to use the
older implementation instead, see “HA with aVCS Deployment Example” on page 503.
To begin, the following command enables aVCS:
ACOS-1#vcs enable
The following commands configure the high availability set ID and device ID:
ACOS-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.
ACOS-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 inter-
face, to help ensure continued communication in case a link goes down.
The following commands save the changes and activate the aVCS configuration.
ACOS-1(config)#write memory
ACOS-2#vcs enable
ACOS-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.
ACOS-1#vcs enable
ACOS-1#configure
ACOS-1(config)#ha id 1 set-id 1
ACOS-2#vcs enable
ACOS-2#configure
ACOS-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 519.
Part IX
Application Delivery Partitions (ADPs)

• “Overview of Application Delivery Partitions” on page 507
• “Role Based Administration Private Partitions” on page 531
• “Layer 3 Virtualization of Private Partitions” on page 539
• “Inter-Partition Routing” on page 569
Overview of Application Delivery Partitions
Each ACOS device includes a default partition called the shared partition; when you access and configure the device, you are
making changes on the shared partition.
It is also possible to create additional partitions on the ACOS device, called Application Delivery Partitions (ADPs). These “pri-
vate” partitions can provide aggregated networking and system services, application resources, and administrative and man-
agement capabilities.
There are two types of partitions that can be created to segment your ACOS device:
• Role Based Administration (RBA) partitions (non-network-enabled partition). For details refer to “Role Based Adminis-
tration Private Partitions” on page 531.
• Layer 3 Virtualization (L3V) partitions (network-enabled partition). For details refer to “Layer 3 Virtualization of Private
Partitions” on page 539.
Additional information can also be found in “Types of Partitions” on page 509.
A partition admin will have the privileges to create and configure private partitions, or even to configure the shared partition
(provided you have the appropriate administrative privileges). Root admins can modify any partition, regardless of the parti-
tion 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 partition name access, then depending on the specified
partition, the admin 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.
Partition Benefits
Partition Benefits
Understanding the benefits of partitioning will help you determine whether or not partitioning is meaningful or necessary in
your environment. Partitioning allows the ACOS device to be logically segmented to support separate configurations for dif-
ferent 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
Figure 1 shows an example of an ACOS device with multiple partitions.
Types of Partitions
FIGURE 1 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. Like-
wise, 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 par-
tition. Likewise, B.com's admins can add, modify, delete and save only the resources in B.com's partition. For a better under-
standing of administrative roles, refer to “Administrative Roles” on page 513.
Types of Partitions
The ACOS device has a single shared partition and can have multiple private partitions. By default, the ACOS device does not
have any private partitions.
Types of Partitions
FIGURE 2 Understanding APDs
The different types of partitions are summarized below.
• Shared partition – The shared partition contains system and networking 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. Creating 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 Partitions” on page 531.
• Private L3V partitions – Partitions that provide Layer 2-7 support are referred to as L3V partitions. An L3V private par-
tition contains application (SLB) resources, networking resources, and the system resources. In essence, each L3V par-
tition 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 sys-
tem 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 539.
Hardware-Supported Number of Partitions
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 1.
Supported RBA and L3V Partitions Per ACOS Device

The current release provides support for up to 1 K partitions for the following models: Thunder 6430, Thunder 5430, and AX
5630.
Table 1 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 1.
• 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 1.
TABLE 1 RBA and L3V Supported Partitions

MAX Number of RBA Partitions MAX Number of L3V Partitions
Device Supported Supported
Thunder 6630/6630S 1023 1023
Thunder 6430/6430S
Thunder 5630/5630S
Thunder 5430-11/5430S-11
Thunder 5430S
AX 5630
AX 3530 1023 127
Thunder 4430/4430S 128 128
AX 5200 128 127
AX 5200-11
AX 5100
AX 3400 128 64
AX 3200-12
Thunder 3030S
AX 3030
AX 3000-11-GCF
AX 3000
AX 2600
Partition Logos
TABLE 1 RBA and L3V Supported Partitions (Continued)

MAX Number of RBA Partitions MAX Number of L3V Partitions
Device Supported Supported
AX 2500 128 32
Thunder 1030S
AX 1030
Thunder 930
vThunder 32 32
The total number of partitions in which Layer 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. However, those partitions must share network resources. They cannot run L3V.
NOTE: Configuration synchronization only supports up to 127 RBA partitions even though a
total of 1023 RBA partitions are now supported.
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 recom-
mended logo size is 180x60 pixels.
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 3 virtualization, the output of the log command in aFleX scripts is written into
the log of the shared partition, even if the aFleX script is active in a private partition.
Admins with the proper privilege level can configure local and remote logging 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 vir-
tual 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.
Partition-Based Banners
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 configure the banner message displayed when the Priv-
ileged 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 “Configuring Basic System Parameters” on page 47.
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 avail-
able resources. For details, refer to “Resource Templates for L3V Partitions” on page 558.
Administering Private Partitions

To administer a private partition, you must have the appropriate administrative “role” and “privilege level” assigned to your
role. Only a “root administrator” 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 516. For details on admin accounts, refer to “Configuring Par-
tition Admin Accounts” on page 517. For additional security-related questions, refer to “Management Security Features” in
the Application Access Management and DDoS Mitigation Guide.
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:
ACOS>enable
Password:
ACOS#
ACOS#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 configure 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
• 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 2 describes the GUI access roles and CLI privilege levels.
TABLE 2 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, with per-
level. Use Partition-write. mission 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 permission
to view service port statistics, and to dis-
able 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.
In addition to the pre-configured GUI access roles described here, admins with global read-write access can configure addi-
tional GUI access roles or customize the preconfigured ones. (For more information, see the Application Access Management
and DDoS Mitigation Guide.)
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 and will be able to administer both the shared and private RBA or L3V partitions:
• 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 3 describes the GUI access roles and CLI privilege levels for shared partition administrators.
TABLE 3 Shared and Private Partition Root Admin Privilege Level

GUI Access Role CLI Privilege Level Access to Shared Partition Access to Private 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 privilege Read-write for System Read-write for System
level. Use Write. resources only resources only (for all pri-
vate partitions)
NetworkAdmin No equivalent CLI privilege Read-write for Network Read-write for Network
vate partitions)
SlbServiceAdmin No equivalent CLI privilege Read-write for SLB Service Read-write for SLB Service
vate partitions)
SlbServiceOperator No equivalent CLI privilege Read-only for SLB Service Read-only for SLB Service
level. Use Write. resources, with permission resources, with permission
to enable or disable serv- to enable or disable serv-
ers/services ers/services (for all private
partitions)
PartitionReadWrite Partition-write Read-only Read-write for all resources.
TABLE 3 Shared and Private Partition Root Admin Privilege Level

GUI Access Role CLI Privilege Level Access to Shared Partition Access to Private Partition
PartitionNetworkOperator No equivalent CLI privilege None Read-only for network
level. Use Partition-write. resources, with permission
to enable or disable inter-
faces.
PartitionSlbServiceAdmin No equivalent CLI privilege None Read-write for SLB
level. Use Partition-write. resources.
PartitionSlbServiceOperator Partition-enable-disable None Read-only for real servers,
with permission to view
service port statistics, 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 Partition 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.
• 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 individual 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” in the Application Access
Management and DDoS Mitigation Guide.
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.
3. Enter the name in the Administrator Name field.
4. Enter the password for the new admin account in the Password and Confirm 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” in the Application Access Management and DDoS Mitigation Guide.)
7. To restrict access to specific management interfaces, click the checkboxes 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” in the Application Access Management and DDoS Mitigation
Guide.
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
The admin command creates the admin account and changes the CLI to the configuration level for the account. The com-
mand syntax shown here includes the password option. You can specify the password with the admin command, or with
the separate password command at the configuration 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 speci-
fying 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 commands:
ACOS(config)#admin xyz
ACOS(config-admin:xyz)#exit
By default, admin “xyz” will now have a default password of “a10,” because none was specified.
To specify password:
ACOS(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 Addi-
tional Admin Accounts” in the Application Access Management and DDoS Mitigation
Guide.
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 parti-
tion.
By default, a private partition admin is allowed to change the active partition 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.
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 config-
uration level of the CLI:
[no] partition no-sharing
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 Partitions” on page 531 and “Layer 3 Virtualization of Private Parti-
tions” on page 539.
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:
Viewing and Saving the Configuration
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 private 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 private partitions, use either of the following meth-
ods.
Using the GUI

See “Switching To Another Partition” on page 521.
Using the CLI

To view the configuration, use the following commands:
show running-config
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 partition-name, an “Insufficient privilege” warn-
ing message appears. The resources of the other partition are not displayed.
Switching To Another Partition
Saving the Configuration

To save the configuration on an ACOS device configured with private partitions, 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 partition view. For example, if the partition view is set to the “companyB” private partition, only the
resources in that partition are saved.
Using the CLI

To save the configuration, use the following command:
write memory [all-partitions | partition partition-name]
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 applicable 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 partition(s) to which the write memory com-
mand is applied. Unless the resources in the shared partition are being saved, the con-
figuration profile name used with the write memory command must already exist. The
command does not create new configuration profiles for private partitions.
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 methods.
Synchronizing the Configuration
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.

In High Availability (HA) deployments, either VRRP-A or the older implementation of HA, partition resources can be synchro-
nized 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 465.) Otherwise, the configuration must be synchronized 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 synchro-
nized.
An admin with Read Write privileges can specify any partitions(s) to synchronize.
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 cor-
rectly in the Standby ACOS device’s configuration.
• Synchronize all partitions

• Synchronize the shared partition to the startup-config first, then synchronize the pri-
vate 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 mem-
ory 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 parti-
tion, 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 command, see the note at the beginning of this section
first.
For admins logged on with Partition Write privileges, the following syntax is available:
Operator Management of Real Servers
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.

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 3 Real Server Management in Operator Mode
NOTE: Although the GUI displays the Delete and New buttons, these buttons are not sup-
ported 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 4 Disabling Service Ports – Selecting the Servers
FIGURE 5 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-dis-
able account and use the following 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 enable and config commands to access the configuration level of the CLI:
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 operation level for the real server:
slb server server-name [ipaddr]
Use the disable or enable commands to change the state of the servers.
To verify the state change, use the show slb server command.
Private Partition Session Limits
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 the disable or enable commands to change the state of the service port.
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

With a resource-usage template, you can adjust the Layer 4 session limits for individual partitions. The template allows you to
define a guaranteed minimum number of sessions for a partition, as well as a maximum number of sessions allowed. This
keeps parity among the partitions. One partition user will no longer be able to consume all supported sessions by increasing
the session timeout value.
To apply a minimum guarantee and maximum allowable sessions, configure the limits on an SLB resource-usage template.
Bind the template to the partition to which the limits should be applied. The limits will take effect the next time the ACOS
device is reloaded or rebooted.
A resource-usage template specifying a minimum guaranteed number of sessions can only be bound to partitions when the
minimum resource guarantee can be met. If the total minimum guaranteed values across partitions will exceed 100%, then
the template cannot be applied.
If a session limit is configured on a partition, and you want to change the limit, then the new limit must be higher than the
current session utilization. The maximum allowed value can still be lower, as long as the number of currently active sessions
is lower than the new maximum value. If the number of currently active sessions is higher, then the change will be rejected.
To completely disable the feature, the Layer 4 session limit configurations should be deleted from all templates that are
bound to any private partition. The limits will be removed the next time the ACOS device is reloaded or rebooted.
Configuration Notes
Configuration notes for this feature:
• This feature only provides a minimum guaranteed or a maximum allowed number of sessions per partition. It does
not limit other resources, such as the number of connections allowed per second.
• All partitions are pre-allocated a small amount of session memory that will not be freed, even if all the sessions in a
partition are closed. Because of this, the show command “show resource-usage” will never be 0% for the “l4-session-
count” value, even when there is no traffic.
Configuring Partition Session Limits

To set a guaranteed minimum number of connections and/or a maximum allowed number of connections per partition, do
the following:
1. Configure a system resource-usage template.
2. Apply the template to a partition.
Using the GUI

This feature is not supported in the GUI currently.
Using the CLI

To configure partition session limits in the CLI, create or modify a system resource-usage template by using the following
command at the global configuration level:
system resource-usage template template-name
Within the resource-usage template, enter the system-resources level by entering the following command:
system-resources
To configure the limits, enter the following command at the system-resources level of the resource-usage template:
l4-session-limit max [min-guarantee min]
Within the Layer 4 session limit command, the “max” specifies the maximum number of sessions allowed, as a percentage of
the total number of sessions supported on the ACOS device. The “min” specifies the minimum number of sessions that are
guaranteed, as a percentage of the total number of sessions supported on the ACOS device. Both values allow up to 2 digits
precision.
NOTE: The minimum guaranteed value cannot be more than the maximum allowed.
Role Based Administration Private Partitions
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 configu-
ration 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 templates 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 can-
not remove them.
Figure 6 show how an ACOS device can be carved into separate RBA partitions.
FIGURE 6 RBA Partitions
Resources Contained in RBA Private Partitions

The following types of resources can be contained in RBA private partitions:
• Layer 4-7 (Application/SLB) resources:
• Real servers
• Virtual servers
• Service groups
• Templates
Overview
• 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 parti-
tions. For example, partitions “A.com” and “B.com” can each have a real server named “rs1”. The ACOS device is able to distin-
guish between them.
All RBA partitions depend on the shared partition for the following networking 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 networking 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 partition. This ID will be chronological in order. For exam-
ple, 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
An ADP that is partitioned with RBA partitions provides the capabilities shown in Figure 7:
FIGURE 7 RBA Partition Capabilities
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

Simple RBA Partition Configuration
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 performed by an admin with Partition-write privileges
who is assigned to the partition. For details on administrative roles and privileges, refer to “Application Delivery Parti-
tions (ADPs)” on page 505.
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 interfaces, 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

1. Select Config Mode > System > Admin.
2. On the menu bar, select Partition.
3. Click Add. The Partition section appears.
FIGURE 8 Config Mode > System > Admin > Partition
4. Enter a name for the partition. This is similar to using the partition name command in the CLI.
5. Specify a partition ID.
6. Disable the Network Partition option (default)
7. To upload a logo for the partition, click Browse and navigate to the logo file.
8. If a partition logo is not uploaded, the A10 Networks logo is used by default.
9. Click OK. The new partition appears in the partition list.
FIGURE 9 Config Mode > System > Admin > Partition - List
Using the CLI

To configure a private partition, use the following command at the global configuration level of the CLI:
[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.
Example 1: RBA Partition Configuration

The following subsections show additional RBA configuration examples.
1. Create the RBA partition:

ACOS(config)#partition rba1
2. Create the admin and assign privileges:

ACOS(config)#admin admin-rba1 password test
ACOS(config-admin:admin-rba1)#privilege partition-write rba1
Modify Admin User successful!
ACOS(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.
ACOS(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]
ACOS[rba1]>enable
Password:
ACOS[rba1]#
ACOS[rba1]#config
ACOS[rba1](config)#
4. Configure the RBA partition. In a RBA partition you can configure servers, service groups, and VIPs.
a. Configure a server:
ACOS[rba1](config)#slb server s1 20.20.20.25
ACOS[rba1](config-real server)#port 80 tcp
ACOS[rba1](config-real server-node port)#exit
ACOS[rba1](config-real server)#exit
b. Create service-groups:
ACOS[rba1](config)#slb service-group s1-80 tcp
ACOS[rba1](config-slb svc group)#member s1:80
ACOS[rba1](config-slb svc group)#exit
c. Create VIPs:
ACOS[rba1](config)#slb virtual-server vip1 10.10.10.15
ACOS[rba1](config-slb vserver)#port 80 http

ACOS[rba1](config-slb vserver-vport)#service-group s1-80
5. Display your RBA partition configuration using the show running command. 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.
ACOS[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 cre-
ated.
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 permission only to view service port statistics for real
servers in the partition, and to disable or re-enable the real servers.
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 partitions for these types of resources, L3V partitions support direct access to networking
resources per partition. Layer 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 net-
working, system, and application resources. In addition, they also provide a mechanism to administer any given partition. For
details on partitioning, refer to “Overview of Application Delivery Partitions” on page 507. L3V partitions provide a mecha-
nism to segment a single ACOS device into multiple instances that behave independent of each other.
Figure 10 show how an ACOS device can be carved into separate L3V partitions (network-enabled partition).
FIGURE 10 L3V Partitions
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 organization’s configuration or space. Each organization then can authenticate their own partition and configure their
own devices as if they were a completely, separate organization.
ACOS devices provide support for multiple L3V partitions, and the number of partitions they support are platform depen-
dent. For information on a maximum number of supported partitions that can run L3V, refer to “Supported RBA and L3V Par-
titions Per ACOS Device” on page 511.
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.
Overview
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 Configu-
ration” on page 546.
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 “Resource Templates for L3V Partitions” on page 558
L3V Advantages
Content Isolation—A partition administrator will be able to create servers, service-groups, VIPs, templates, and aFleX scripts
per partition. However, everything will be in a network that is totally independent from that of a shared or any other L3V par-
tition.
Multi-tenancy—L3V within ADPs provides a space saving multi-tenant solution. ADP role-based management allows con-
figuration and monitoring capabilities within individual partitions.
Resource Usage Templates—Via resource usage templates, L3V partitions can ensure that no partition is starved of any net-
work, system, or application resources. These templates can contain preconfigured new limits for these values from their
prior default values. For details, refer to “Resource Templates for L3V Partitions” on page 558
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 Figure 11:
FIGURE 11 L3V Partition Capabilities
VIPs, Servers, Templates,aFleX
Administrative Access Capabilities L3V VLANs, VEs, IP Addresses
Without these capabilities, each partition will not have direct access to networking resources. For details on L3V, refer to
“Layer 3 Virtualization” on page 541.
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.
Overview
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 “Resource Templates for L3V Partitions” on page 558
The following types of resources can be contained in an L3V private partition:
• Layer 2 (System) resources:
• VLANs
• Virtual Ethernet (VE) interfaces
• Static MAC entries
• Layer 3 (Network) resources:
• IP addresses
• ARP entries
• Routing tables
• ACLs
• 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 par-
titions. For example, partitions “A.com” and “B.com” can each have a real server named “rs1”. The ACOS device is able to distin-
guish between them.
After creating and assigning users to a partition, the administrator may then configure all resources to the partition.
Layer 3 Virtualization
Layer 3 virtualization allows a private partition to have its own network resources. You can enable Layer 3 virtualization on an
individual partition basis.
Admins with the proper privilege level for a private partition on which Layer 3 virtualization is enabled can configure net-
work resources for exclusive use by the individual partition:
Overview
Each partition has its own ARP table, and its own IPv4 and IPv6 route tables. They are completely separate from the 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 avail-
able to all partitions. The VLAN tag ensures that a given partition’s traffic remains within
that partition’s Layer 2 broadcast domain.
Requirements
Layer 3 resources must be unique within a given partition. However, some types of Layer 3 resources can be the same in mul-
tiple 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 partition, 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 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 4 lists the operational differences between partitions in which Layer 3 virtualization is enabled or disabled.
Overview
TABLE 4 Operational Comparison Between Layer 3 Virtualization Enabled and Disabled

Layer 3 Virtualization Enabled Layer 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 port disabling allowed disabling allowed
allowed from shared
partition
Untagged VLAN Visible only in the par- Visible in the shared Visible in all the pri- Visible in the shared
ports tition they belong to partition vate partitions partitions
Cannot be configured Cannot be configured Can be configured, Can be configured,
from a if it belongs to some disabled, enabled disabled, enabled
partition which they partition other than from all the from the shared parti-
do not belong to shared partitions tion
Tagged VLAN ports Visible in all the parti- Visible in all the parti- Visible in all the parti- Visible in all the parti-
tions tions tions tions
Disabling or enabling Disabling or enabling Disabling or enabling Disabling or enabling
a tagged port within a tagged port within a tagged port within a tagged port in the
a partition does not the shared partition a partition also dis- shared partition also
disable the port in also disables the port ables or enables the disables or enables
other partitions in all other partitions port in other parti- the port in all private
tions partitions
Trunks Allowed Allowed Allowed Allowed
Note: The trunk can
be configured only in
the shared partition.
VLANs Same VLAN ID cannot Same VLAN ID cannot Same VLAN ID cannot Same VLAN ID cannot
be configured in dif- be configured in be configured in dif- be configured in
ferent partitions shared partition ferent partitions shared partition
VEs Same VE numbers are Same VE numbers are Same VE numbers Same VE numbers
not allowed in differ- not allowed in the not allowed in differ- not allowed in differ-
ent partitions. The VE shared partition. The ent partitions ent partitions
must match the VLAN VE must match the
ID, so cannot be re- VLAN ID, so cannot be
used. re-used.
Overview
TABLE 4 Operational Comparison Between Layer 3 Virtualization Enabled and Disabled (Continued)
Layer 3 Virtualization Enabled Layer 3 Virtualization Disabled
Resource Private Partition Shared Partition Private Partition Shared Partition
IP addresses Same subnet allowed Same subnet with Same subnets not Same subnets not
in different partitions regard to different allowed in different allowed in shared
partitions allowed in private partition partition
A tagged port can
shared partition
have same subnet A tagged port is not A tagged port is not
across different parti- A tagged port can allowed to have same allowed to have same
tions under different have same subnet as subnets even with subnets even with
VLANs other partitions but different VLAN IDs different VLAN IDs in
with different VLAN shared partition
Note: Duplicate IP
addresses are sup- ID
ported in L3V parti-
tions. In this case,
both partitions can
have same IP address
but must be on sepa-
rate VE interfaces.
ACLs Supported Supported Not supported Supported
NAT pools Same NAT pools Same NAT pools Same NAT pools not Same NAT pools not
allowed across allowed in shared allowed allowed
different partitions partition
Static routing Supported Supported Not supported Supported
Dynamic routing Supported Supported Not supported Supported
VIPs VIPs with same name VIPs with same name VIPs with same name VIPs with same name
or same subnet not or same subnet not or same subnet not or same subnet not
allowed in different allowed in different allowed in different allowed in different
partitions partitions partitions partitions
VIPs from other parti- VIPs from shared par-
tions allowed tition 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 subnet name or same subnet
address allowed in address allowed in not allowed in differ- not allowed in differ-
different partitions different partitions ent partitions ent partitions
Servers from other Servers from shared
partitions allowed partition can be used
by any other partition
Per-partition Feature Support for Layer 3 Virtualization

The following features can be configured in private partitions on which Layer 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.
Overview
NOTE: This enhancement applies only to partitions in which Layer 3 virtualization is enabled. If
Layer 3 virtualization is disabled, these features can not be configured within the parti-
tion.
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 3 Virtualization” on page 545.)
Features that can be configured at the interface configuration level within a private partition:
• IPv6 router advertisement and discovery
• ICMP rate limiting
Per-partition Default SLB Templates for Layer 3 Virtualization

Layer 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 par-
tition:
L3V Partition Configuration
• 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 private partitions.
NOTE: This behavior applies only to partitions on which Layer 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 “Configuration Examples” on
page 552.)
Limitations
Firewall Load Balancing (FWLB) is not supported in individual private partitions. This feature can be configured only in the
shared partition.
Next Hop Load Distributor (NHLD) is supported in private partitions only if the feature is configured using a wildcard VIP.

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 Partitions” on page 531 and “Layer 3 Virtualization of Private Partitions”
on page 539:
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 performed by an admin with Partition-write privileges
who is assigned to the partition. For details on administrative roles and privileges, refer to “Application Delivery Parti-
tions (ADPs)” on page 505.
4. Configure network and system connectivity resources such as interfaces, 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

1. Select Config Mode > System > Admin > Partition.
2. Click Add. The Partition section appears.
3. Enter a name and ID for the network partition.
4. Select the Enable button in the Network Partition field.
5. Select the maximum allowed number of aFleX files that can be created in this partition.
FIGURE 12 Config Mode > System > Admin > Partition > New
6. Click OK. The new partition appears in the partition list.
Using the CLI

To configure a private partition, use the following command at the global configuration level of the CLI:
[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 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 automat-
ically 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
Shared Management VLAN in L3V Private Partitions
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 network resources, such as VLANs, VEs, and IP Addresses.
Shared Management VLAN in L3V Private Partitions

This release allows you to configure a shared management VLAN that is accessible from all partitions.
For incoming and outgoing management traffic received on this interface, independent ACLs can be enabled in each parti-
tion (for this shared VLAN). Configure a shared VLAN across different partitions to support management applications. The
shared VLAN can only be created in the shared partition.
The new commands for this feature are accessible once you have configured your partition(s) in the network partition level
and configured your VLAN for shared management access.
1. Specify the interface to be bound to the partitions for management access.
2. Specify the source IP address allowed to establish management access to ACOS.
3. Configure your VLAN as a shared management VLAN accessible from all partitions.
NOTE: A VE configured for shared VLAN management, is limited to the following options: The
option to enable or disable the interface, the ACL option and the name option. Only one
IP address is allowed to be configured to match the allowable range provided.
Using the GUI

Using the CLI

1. Once you have reached the network partition configuration level, specify the interface to be bound to the partition for
management access (should already be configured) using the following command:
map-interface interface
2. Specify the IP address allowed for the partition using the following command: allowable-ip-range ip
address
3. Repeat the first two steps for as many partitions as you wish to configure.
4. Exit back to the global configuration level.
5. From the global configuration level, configure a VLAN.
6. Set the VLAN as a shared VLAN accessible from all partitions using the following command: shared-vlan man-
agement
The following gives an example of a management VLAN configuration. It shows the configuration of multiple network parti-
tions and a VLAN configured for shared management access for those partitions.
Independent SNMP Configuration Expansion for Partitions
ACOS(config-partition)#map-interface ve 100
ACOS(config-ip-range)#allowable-ip-range 1.3.4.1 vrid default
ACOS(config-partition)#map-interface ve 100
ACOS(config-ip-range)#allowable-ip-range 1.3.4.5 vrid 10
ACOS(config)#vlan 100
ACOS(config-vlan:100)#untagged ethernet1
ACOS(config-vlan:100)#shared-vlan management
ACOS(config-vlan:100)#name “example”
ACOS(config-vlan:100)#interface ve 100 ip address 1.3.4.111/24
The following is a continuation of the example above. It shows the output given by show commands, as it applies to this fea-
ture.
ACOS(config-vlan:100)#show vlans
VLAN 100, Name [example]:
Untagged Ethernet Ports: 1
Tagged Ethernet Ports: None
Shared VLAN: Enabled
ACOS[p1](config-vlan:100)#show ip allowable-ip-range
Partition p1
Allowable Range : 1.3.4.1
Mapped Interface : ve100
Management : 1.3.4.1
Independent SNMP Configuration Expansion for

Partitions
With this feature, users are able to configure the SNMP on L3V private partitions. The configuration will be aware of each par-
tition and only apply to the partition being configured.
Using the GUI

Using the CLI

The following new CLI commands has been added to L3V partitions. The enable/disable trap commands will only be acces-
sible on the group level, not individual trap level. You can only enable/disable a group of traps.
[no] snmp-server enable
Disabling SNMP Traps for Private Partition
[no] snmp-server enable trap snmp/gslb/slb/slb-change

[no] snmp-server disable trap snmp/gslb/slb/slb-change
[no] snmp-server host ip-addr destination-ip-address
To configure SNMP L3V traps:
1. Configure snmp-server enable in the shared partition.
2. Configure snmp-server enable in the L3V partition.
3. Configure snmp-server host ip address in the L3V partition with the trap destination IP address.
4. Configure snmp-server enable traps in the L3V partition.
5. Configure slb server create name ip address. This should trigger the slb create/delete traps command with the L3V
community string.
CLI Example
ACOS(config)#snmp-server enable
ACOS(config)#snmp-server community read nbohFbcYrRstQd
ACOS(config)#snmp-server enable traps
ACOS(config)#snmp-server host 10.30.31.101
NOTE: When running the no snmp-server enable command, ACOS may delete all SNMP con-
figuration. When running the snmp-server enable command, ACOS enables SNMP and
generates a new random password in the community string. Currently, the only way to
generate a new password is to disable and re-enable the SNMP-server, which will
require you to re-enter any previously existing SNMP configuration, including any trap
configuration.
Disabling SNMP Traps for Private Partition

ACOS allows you to enable SNMP traps on shared partitions. The ACOS device can disable traps on private L3V partitions
while the SNMP traps are still enabled on shared partitions. The default behavior is for both shared and L3V partition traps to
be sent out when SNMP traps are enabled on shared partitions.
NOTE: GSLB group traps are not partition aware so they cannot be controlled using the follow-
ing command:
snmp-server disable traps gslb
Configuration
To disable SNMP traps on private partitions, make sure that you are in the configuration level for an L3V partition first. You can
choose to disable all traps, or else specify which traps should not be sent out.
Using the GUI

This feature is not supported in the GUI currently.
Using the CLI

To disable all SNMP traps on private partitions using the CLI, enter the following command at the partition configuration
level:
snmp-server disable traps
To specify which SNMP traps to disable on a private partition, enter the following command at the partition configuration
level:
snmp-server disable traps

{routing |
snmp |
ha |
network |
slb |
ssl |
gslb |
system |
lldp |
slb-change}
The example below disables network and LLDP traps on an L3V private partition named “pl3v.”
ACOS(config)#active-partition pl3v
ACOS[pl3v](config)#snmp-server disable traps network
ACOS[pl3v](config)#snmp-server disable traps LLDP
ACOS[pl3v](config)#active-partition shared
Example 1: Simple L3V Partition Configuration
The following example shows how to create an L3V partition:
1. Create an L3V partition:

ACOS(config)#partition l3v1 network-partition
2. Create the admin and assign privileges:

ACOS(config)#admin admin-l3v1 password test
ACOS(config-admin:admin-rba1)#privilege partition-write l3v1
Modify Admin User successful!
ACOS(config-admin:admin-l3v1)#access axapi web cli
ACOS(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]
ACOS-Active[l3v1]>enable
Password:
ACOS-Active[l3v1]#config
ACOS-Active[l3v1](config)#
4. Configure the desired network and system resources:

For details, refer to “Resource Templates for L3V Partitions” on page 558.
a. Configure a VLAN:
ACOS-Active[l3v1](config)#vlan 50
ACOS-Active[l3v1](config-vlan:50)#tagged ethernet 1
ACOS-Active[l3v1](config-vlan:60)#router-interface ve 50
ACOS-Active[l3v1](config)#vlan 60
ACOS-Active[l3v1](config-vlan:60)#tagged ethernet 1
ACOS-Active[l3v1](config-vlan:60)#router-interface ve 60
b. Configure VEs:
ACOS-Active[l3v1](config)#interface ve 50
ACOS-Active[l3v1](config-if:ve50)#ip address 50.50.50.1 /24
ACOS-Active[l3v1](config)#interface ve 60
ACOS-Active[l3v1](config-if:ve60)#ip address 60.60.60.1 /24
ACOS-Active[l3v1](config-if:ve60)#exit
c. Configure a server:
ACOS-Active[l3v1](config)#slb server s1-l3v 60.60.60.20
ACOS-Active[l3v1](config-real server)#port 80 tcp
ACOS-Active[l3v1](config-real server-node port)#exit
d. Configure a service-group:
ACOS-Active[l3v1](config)#slb service-group s1-80 tcp
ACOS-Active[l3v1](config-slb svc group)#member s1-l3v:80
e. Configure a VIP:
ACOS-Active[l3v1](config)#slb virtual-server vip1 50.50.50.15
ACOS-Active[l3v1](config-slb vserver)#port 80 tcp
ACOS-Active[l3v1](config-slb vserver-vport)#service-group s1-80
ACOS-Active[l3v1](config-slb vserver-vport)#exit
ACOS-Active[l3v1](config-slb vserver)#exit
5. View your running configuration. Since you have created an L3V partition, you can see and configure Layer 3 network
resources, such as VLANs, VEs, and IP Addresses:
ACOS-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 Layer 3 Virtualization

The following commands log onto the CLI with Read Write admin access, and enable Layer 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 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 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
[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 interfaces 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 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. Ether-
net 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
Resource Templates for L3V Partitions
The following commands log onto the CLI with Read Write admin access, and display the list of Ethernet interfaces in the
shared partition. All physical 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

Resource templates help you to define limits for application, network, and system resources in partitions enabled for Layer 3
virtualization. Once defined, you can bind or unbind a resource template to a particular partition. You can also apply a sam-
ple template to multiple partitions. By default, Layer 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 serv-
ers 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 3 partitions. For example, you can specify the number of real serv-
ers a partition can access.
By configuring resource limits for individual Layer 3 partitions, you can ensure that no partition starves another partition of
resources by monopolizing the available system resource quotas.
Resource Template Parameters

You can configure the following types of resource templates for Layer 3 partitions:
• Application Resources – Contains configuration parameters for application resources such as the number of health
monitors, real servers, service 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 throughput, and SSL CPS.
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 configura-
tion level of the CLI:
show system resource-usage
*.
GSLB parameters are configurable on a per-partition basis hard-coded (and thus non-configurable) at the system level.
Application Resource Parameters

At the template configuration level, set the application resource parameters discussed in Table 5.
TABLE 5 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 6.
TABLE 6 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.
System Resource Parameters

At the template configuration level, set the system resource parameters discussed in Table 7.
TABLE 7 System Resource Usage Template Parameters

Bandwidth bw-limit Enter a bandwidth limit between 10 and 10000 Mbps. Right after
you indicate a bandwidth limit in Mbps, optionally, disable a
watermark using a watermark-disable keyword. A water-
mark 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 water-
mark-disable keyword will turn off the watermark option and
result in accepting new connections until 100% of the band-
width in that second is utilized.
Concurrent Session concurrent-session- Enter the concurrent session limit. Configure a concurrent ses-
limit sion limit when you have no active sessions running on the
ACOS device. If you indicate the concurrent session limit when
there are active sessions (on the L3V partition where you are
configuring 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 ses-
sions 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 a SSL throughput limit between 10 and 10000 Mbps. Right
after you indicate a bandwidth limit in Mbps, optionally, disable a
watermark using a watermark-disable keyword. A water-
mark 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 water-
mark-disable keyword will turn off the watermark option and
result in accepting new connections until 100% of the band-
width in that second is utilized.
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 template.
4. Configure the application, network, and system resource options. (See Table 5 on page 560, Table 6 on page 560, and
Table 7 on page 561.)
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 565.
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 system resources from their default values.
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 partition.
NOTE: Though partitions need to bound to a template one at a time, several partitions may be
bound to the same custom template.
4. Unbind a template to revert to the default values for resources per partition. This step assumes that you
have created a default template.
Creating a System Resource Template

Use the system resource-usage template command to create a custom resource template.
To view your customized template containing the values for application, network, and system resources, use the show sys-
tem resource-usage template command.
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 partitions unless a partition is already
bound to another custom template.
The following example creates a resource template named “ru-tmplt”:
ACOS(config)#system resource-usage template ru-tmplt
Assigning Resource Limits

From the template configuration mode, you can modify any application, network, or system resource limits.
Application Resources
Use the app-resources command to enter the application resource limit configuration mode. Configuring application
resource parameters allows you to assign values for parameters listed in Table 5 on page 560:
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:
ACOS(config-resource template)#app-resources
ACOS(config-resource template-node app)#gslb-zone-count 10
ACOS(config-resource template-node app)#health-monitor-count 50
ACOS(config-resource template-node app)#real-server-count 100
ACOS(config-resource template-node app)#service-group-count 150
ACOS(config-resource template-node app)#virtual-server-count 250
Network Resources
Use the network-resources command to enter the network resource limit configuration mode. Configuring network
The following example shows you how to enter the network resources configuration mode. From this location, you can set
values for the available network resources:
ACOS(config-resource template)#network-resources
ACOS(config-resource template-node network)#static-arp-count 100
ACOS(config-resource template-node network)#static-ipv4-route-count 1000
ACOS(config-resource template-node network)#static-ipv6-route-count 2000
ACOS(config-resource template-node network)#static-mac-count 200
ACOS(config-resource template-node network)#static-neighbor-count 128
System Resources
Use the system-resources command to enter the system resource limit configuration mode. Configuring system
The following example shows you how to enter the system resources configuration mode. From this location, you can set
values for the available 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:
ACOS(config-resource template)#system-resources
ACOS(config-resource template-node system)#bw-limit 500 watermark-disable
ACOS(config-resource template-node system)#concurrent-session-limit 3200
ACOS(config-resource template-node system)#l4cps-limit 2000
ACOS(config-resource template-node system)#l7cps-limit 4000
ACOS(config-resource template-node system)#natcps-limit 100000
ACOS(config-resource template-node system)#ssl-throughput-limit 1000
ACOS(config-resource template-node system)#sslcps-limit 10000
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 parti-
tion that is not bound to a custom system template. Though partitions need to bound
to a template one at a time, several partitions may be bound to the same custom tem-
plate.
Using the GUI

To apply a system resource template to a partition:
1. Navigate to Config Mode > System > Admin > Partition.
2. Click the name of an existing 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 562.
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 tem-
plate 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”:

ACOS(config-partition)#template ru-tmplt
To verify that your template is applied to the partition called “p55”, use the show running command:
ACOS(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:
ACOS(config-partition)#partition p55 network-partition

ACOS(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.
4. Click OK.
Contradictory Resource Usage Scenario

Configuration of resource usages may fail in the event of contradictory resource limit conditions. Some scenarios are out-
lined 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 contradictory 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. How-
ever, 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 software again checks for contradictory resource limits prior to unbinding the template.
Monitoring L3V Resource Templates

This section describes how to monitor resource templates using SNMP traps and Syslog messages.
SNMP and Logging Thresholds for Shared and Private Partition Resource Utilization
You can configure SNMP traps to be sent out when the configured threshold is reached for a particular system resource. This
will show both the global system usage and the system usage per-partition.
NOTE: Both a Log message and a trap are generated when the configured threshold is crossed
in either direction. The message will indicate if the current utilization if above or below
the threshold.
Using the GUI

Using the CLI

To set a threshold percentage for the network and application resource categories, use the following commands at your
selected resource-usage level:
[no] app-resource-threshold percent

[no] network-resource-threshold percent
The following example shows you how to configure the SNMP trap threshold for your application resources.
ACOS(config)#system resource template test

ACOS(config-resource template)#app-resources
ACOS(config-resource template-node app)#app-resource-threshold 10
NOTE: For information on enabling SNMP traps, please see “Enable SNMP Traps” on page 130.
System Logging Rate in Resource Template

This feature adds two new Syslog parameters to the resources template; remote-log-rate and local-log-rate. This
gives the administrator control over the log rate for any bound partition. The log rate limiting is only for data plane logging.
Using the GUI

To configure system logging parameters using the GUI:
1. Navigate to Config Mode > System > Settings > General > Resource Usage > Template.
2. Click Add to create a new template.
3. Configure the resources are desired. Refer to the GUI online help for information about the fields on this page.
Using the CLI

To set the maximum log rate for local and remote logging, use the local-log and remote-log commands at the system
resource-usage level.
The following example shows you how to configure the local and remote log rates at the system resource usage level.
ACOS(config)#system resource template test

ACOS(config-resource template)#system-resources
ACOS(config-resource template-node system)#remote-log rate 30,000
ACOS(config-resource template-node system)#local-log rate 50
Simultaneous Logging Capabilities for Log Servers in Shared and Private Partitions
When configured using the CLI, if the shared partition and the private (L3V) partition both have their own syslog servers, this
feature will allow for simultaneous log updates to both partitions. Currently, this release provides support for IPv4.
Using the GUI

Using the CLI

For configuring in the shared partition, use the following command:
logging host ip-address port num
For configuring in the private partition to allow simultaneous system logs sent to the shared and private partition, use the
following command:
logging host ip-address partition shared
The following example shows you how to configure simultaneous log updates to both partitions.
ACOS(config)#logging host 192.168.216.45

ACOS(config)#end
Currently active partition: p1
ACOS[p1](config)#logging host 2.2.2.2 partition shared
In the configuration above, system logs generated from partition “p1” will be sent to logging server “2.2.2.2”, as well as to the
shared logging server’s “192.168.216.45”.
Inter-Partition Routing
This chapter contains the following topics:
• Overview of Inter-Partition Routing
• Configuring Inter-Partition Routing
Overview of Inter-Partition Routing

Static routes can be configured directly between a private partition and the shared partition. One example of how this capa-
bility is meaningful is the case where different partitions are leased to separate customers; traffic can be routed from the
shared partition to the VIP configured in a private partition and vice versa.
Without this capability, in order to route traffic from one partition to another, traffic must be sent out of the device to an
external router, which then forwards the traffic to the destination partition of the devices. In addition, partition-awareness
was accomplished by using VLAN tags only.
NOTE: Inter-partition routing is only supported using IPv4 addresses.
Below are some common 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 servers 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 specified.
• 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 Forwarding 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 partitions. 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 partition only.
• Static routes can forward traffic from the shared partition to VIP in a private partition.
Configuring Inter-Partition Routing

An example configuration of inter-partition routing is shown below:

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[p69](config)# ip route 0.0.0.0 /24 partition shared
The ip slb-partition-redirect command enables the support on the ingress Ethernet data port that will receive the
traffic addressed to the VIP in the private partition. Then, use the ip route command to add the static route whose destina-
tion is the network address configured in the private partition. Then, change the CLI session to the private partition (in this
example, p69, and configure a static default route back to the shared partition.
Configuration in the Shared Partition

To enable inter-partition routing capabilities, do the following 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 partition.
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:
ACOS(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:
ACOS(config)# show ip route

* - 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.
ACOS(config)# show ip fib

------------------------------------------------------------------------
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 traf-
fic on the specified incoming interface. This traffic will be successfully redirected to the specified private partition that will
process the packets. This command is meaningful for downstream routing of traffic:
The configuration is applied to the specified physical interface, virtual interface, 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.
ACOS(config-if:ve21)# ip address 10.11.0.1 /24
ACOS(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:
ACOS# 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 config-
ured 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.
Configuring the Default Route—Private Partition to 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 pri-
vate partition, and configure a static default route back to the shared partition:
Ensure that you have SLB running and VIPs configured in your private partition before you configure a static route to the VIP.
Configure the default route to the shared partition from the private partition:
ACOS[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:
ACOS[a](config)# show ip route

* - 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:
ACOS[a](config)# show ip fib

------------------------------------------------------------------------
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:
ACOS[a](config)# show running interface ve 22

interface ve 22
ip address 10.15.0.1 255.255.255.0
Configuring SLB Within a Private Partition

To configure SLB in your private partition, use the following commands, configure the server, the associated port and proto-
col, 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 virtual server.
ACOS[a](config)# slb server abc 10.15.0.15

ACOS[a](config-real server)# port 80 tcp
ACOS[a](config-real server-node port)# slb service-group abc tcp
ACOS[a](config-slb svc group)# member abc:80
ACOS[a](config-slb svc group)# slb virtual-server v1 10.15.0.101
ACOS[a](config-slb vserver)# port 80 http
ACOS[a](config-slb vserver-vport)# service-group abc
ACOS[a](config-slb vserver-vport)# slb virtual-server v2 10.15.0.102
ACOS[a](config-slb vserver)# port 80 tcp
ACOS[a](config-slb vserver-vport)# service-group abc
Verify your private partition SLB configuration using the show running command and display the SLB configuration sec-
tion:
ACOS[a](config)#show run | sec slb

slb server abc 10.15.0.15
port 80 tcp
slb service-group abc tcp
member abc:80
port 80 http
service-group abc
port 80 tcp
service-group abc
Having configured the static route in the private partition and the shared partition, and having configured SLB redirect capa-
bilities on the shared partition, the inter-partition routing feature is now functional.
5
ACOS 2.7.2-P9 System Configuration and Administration Guide | 16 September 2016

System Configuration and Administration Guide

Uploaded by

Copyright:

Available Formats

System Configuration and Administration Guide

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

System Configuration and Administration Guide

Uploaded by

Copyright:

Available Formats

System Configuration and Administration Guide

A10 Networks Inc. Software License and End User Agreement

2. sublicense, rent or lease the Software.

System Overview .........................................................................................................................21

FIPS Support ..................................................................................................................................29

Common Setup Tasks....................................................................................... 39

Configuring Basic System Parameters .................................................................................47

Deployment Examples ..............................................................................................................63

System Requirements: ..................................................................................................................................................... 73

Thunder HVA .................................................................................................................................77

Configuration Management ............................................................................ 79

Backing Up System Information ............................................................................................81

Source Interface for Management Traffic ...........................................................................89

Boot Options .................................................................................................................................95

Power On Auto Provisioning ................................................................................................ 103

Overview .......................................................................................................................................................... 103

System Center Operations Manager Support ................................................................ 105

Fail-Safe Automatic Recovery .............................................................................................. 109

Monitoring Tools ............................................................................................ 115

System Log Messages ............................................................................................................. 117

Emailing Log Messages .......................................................................................................... 123

Simple Network Management Protocol (SNMP) ........................................................... 129

Configure SNMP............................................................................................................................................. 133

Link Monitoring ......................................................................................................................... 137

Gateway Health Monitoring ................................................................................................. 143

Multiple Port-Monitoring Mirror Ports .............................................................................. 147

NetFlow v9 and v10(IPFIX) .................................................................................................... 151

sFlow ............................................................................................................................................. 159

Network Configuration .................................................................................. 167

Virtual LAN Support ................................................................................................................. 169

Jumbo Frames ........................................................................................................................... 175

Link Trunking ............................................................................................................................. 181

Link Layer Discovery Protocol .............................................................................................. 203

Open Shortest Path First (OSPF) .......................................................................................... 207

Interface Configuration ................................................................................................................................................ 208

Border Gateway Protocol (BGP) ........................................................................................... 219

Bidirectional Forwarding Detection .................................................................................. 231

Configure BFD with BGP .............................................................................................................................................. 239

Dynamic Host Configuration Protocol (DHCP) .............................................................. 243

Internet Group Multicast Protocol (IGMP) Queries ...................................................... 249

Configuring a Software Defined Network ....................................................................... 253

Configuring a Sample Topology .............................................................................................................. 256

Network Address Translation (NAT) ............................................................. 263

Configuring Dynamic NAT .................................................................................................... 265

Configuring Static NAT ........................................................................................................... 277

NAT ALG Support for PPTP .................................................................................................... 281

Additional NAT Configuration Features ........................................................................... 285

IP NAT in HA Configurations...................................................................................................................... 290

VRRP-A High Availability ............................................................................... 293

Overview of VRRP-A ................................................................................................................. 295

Deploying VRRP-A .................................................................................................................... 311

Displaying VRRP-A Information................................................................................................................ 312

VRRP-A GUI Configuration and Monitoring .................................................................... 329

GUI Configuration Examples ..................................................................................................................................... 340

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

High Availability (HA)..................................................................................... 375

Overview of High Availability .............................................................................................. 377

Restrictions .................................................................................................................................................................. 384

HA Configuration Parameters .............................................................................................. 399