Manual.pdf

  • Uploaded by: Min Min
  • 0
  • 0
  • June 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Manual.pdf as PDF for free.

More details

  • Words: 111,323
  • Pages: 486
System Configuration and Administration Guide

AX Series Advanced Traffic Manager Document No.: D-030-01-00-0024 Ver. 2.6.1-GR1 4/18/2012

©

A10 Networks, Inc. 4/18/2012 - All Rights Reserved

Information in this document is subject to change without notice. Trademarks A10 Networks, the A10 logo, ACLOUD, ACOS, AFLEX, AFLOW, AGALAXY, AVCS, AXAPI, IDACCESS, IDSENTRIE, IP TO ID, SMARTFLOW, SOFTAX, VIRTUALADC, VIRTUAL CHASSIS, and VIRTUALN are trademarks or registered trademarks of A10 Networks, Inc. All other trademarks are property of their respective owners.

Patents Protection A10 Networks products including all AX Series products are protected by one or more of the following US patents and patents pending: 8151322, 8079077, 7979585, 7716378, 7675854, 7647635, 7552126, 20120084419, 20110239289, 20110093522, 20100235880, 20100217819, 20090049537, 20080229418, 20080148357, 20080109887, 20080040789, 20070283429, 20070282855, 20070271598, 20070195792, 20070180101

Confidentiality This document contains confidential materials proprietary to A10 Networks, Inc. This document and information and ideas herein may not be disclosed, copied, reproduced or distributed to anyone outside A10 Networks, Inc. without prior written consent of A10 Networks, Inc. This information may contain forward looking statements and therefore is subject to change.

A10 Networks Inc. Software License and End User Agreement Software for all AX Series 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 this Agreement. 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 The information presented in this document describes the specific products noted and does not imply nor grant a guarantee of any technical performance nor does it provide cause for any eventual claims resulting from the use or misuse of the products described herein or errors and/or omissions. A10 Networks, Inc. reserves the right to make technical and other changes to their products and documents at any time and without prior notification. No warranty is expressed or implied; including and not limited to warranties of non-infringement, regarding programs, circuitry, descriptions and illustrations herein.

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 location, which can be found by visiting www.a10networks.com.

AX Series - System Configuration and Administration Guide End User License Agreement

End User License Agreement IMPORTANT: PLEASE READ THIS END USER LICENSE AGREEMENT CAREFULLY. DOWNLOADING, INSTALLING OR USING A10 NETWORKS OR A10 NETWORKS PRODUCTS, OR SUPPLIED SOFTWARE CONSTITUTES ACCEPTANCE OF THIS AGREEMENT. A10 NETWORKS IS WILLING TO LICENSE THE PRODUCT (AX Series) TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE AGREEMENT. BY DOWNLOADING OR INSTALLING THE SOFTWARE, OR USING THE EQUIPMENT THAT CONTAINS THIS SOFTWARE, YOU ARE BINDING YOURSELF AND THE BUSINESS ENTITY THAT YOU REPRESENT (COLLECTIVELY, "CUSTOMER") TO THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, THEN A10 NETWORKS IS UNWILLING TO LICENSE THE SOFTWARE TO YOU AND DO NOT DOWNLOAD, INSTALL OR USE THE PRODUCT. The following terms of this End User License Agreement ("Agreement") govern Customer's access and use of the Software, except to the extent there is a separate signed agreement between Customer and A10 Networks governing Customer's use of the Software License. Conditioned upon compliance with the terms and conditions of this Agreement, A10 Networks Inc. or its subsidiary licensing the Software instead of A10 Networks Inc. ("A10 Networks"), grants to Customer a nonexclusive and nontransferable license to use for Customer's business purposes the Software and the Documentation for which Customer has paid all required fees. "Documentation" means written information (whether contained in user or technical manuals, training materials, specifications or otherwise) specifically pertaining to the product or products and made available by A10 Networks in any manner (including on CD-Rom, or on-line). Unless otherwise expressly provided in the Documentation, Customer shall use the Software solely as embedded in or for execution on A10 Networks equipment owned or leased by Customer and used for Customer's business purposes. General Limitations. This is a license, not a transfer of title, to the Software and Documentation, and A10 Networks retains ownership of all copies of the Software and Documentation. Customer acknowledges that the Software and Documentation contain trade secrets of A10 Networks, its suppliers or licensors, including but not limited to the specific internal design and structure of individual programs and associated interface information. Accordingly, except as otherwise expressly provided under this Agreement, Customer shall have no right, and Customer specifically agrees not to:

a. transfer, assign or sublicense its license rights to any other person or entity, or use the Software on unauthorized or secondhand A10 Networks equipment b. make error corrections to or otherwise modify or adapt the Software or create derivative works based upon the Software, or permit third parties to do the same

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

3 of 486

AX Series - System Configuration and Administration Guide End User License Agreement c. reverse engineer or decompile, decrypt, disassemble or otherwise reduce the Software to human readable form, except to the extent otherwise expressly permitted under applicable law notwithstanding this restriction d. disclose, provide, or otherwise make available trade secrets contained within the Software and Documentation in any form to any third party without the prior written consent of A10 Networks. Customer shall implement reasonable security measures to protect such trade secrets. Software, Upgrades and Additional Products or Copies. For purposes of this Agreement, "Software" and “Products” shall include (and the terms and conditions of this Agreement shall apply to) computer programs, including firmware and hardware, as provided to Customer by A10 Networks or an authorized A10 Networks reseller, and any upgrades, updates, bug fixes or modified versions thereto (collectively, "Upgrades") or backup copies of the Software licensed or provided to Customer by A10 Networks or an authorized A10 Networks reseller. OTHER PROVISIONS OF THIS AGREEMENT:

a. CUSTOMER HAS NO LICENSE OR RIGHT TO USE ANY ADDITIONAL COPIES OR UPGRADES UNLESS CUSTOMER, AT THE TIME OF ACQUIRING SUCH COPY OR UPGRADE, ALREADY HOLDS A VALID LICENSE TO THE ORIGINAL SOFTWARE AND HAS PAID THE APPLICABLE FEE FOR THE UPGRADE OR ADDITIONAL COPIES b. USE OF UPGRADES IS LIMITED TO A10 NETWORKS EQUIPMENT FOR WHICH CUSTOMER IS THE ORIGINAL END USER PURCHASER OR LEASEE OR WHO OTHERWISE HOLDS A VALID LICENSE TO USE THE SOFTWARE WHICH IS BEING UPGRADED c. THE MAKING AND USE OF ADDITIONAL COPIES IS LIMITED TO NECESSARY BACKUP PURPOSES ONLY. Term and Termination. This Agreement and the license granted herein shall remain effective until terminated. All confidentiality obligations of Customer and all limitations of liability and disclaimers and restrictions of warranty shall survive termination of this Agreement Export. Software and Documentation, including technical data, may be subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations, and may be subject to export or import regulations in other countries. Customer agrees to comply strictly with all such regulations and acknowledges that it has the responsibility to obtain licenses to export, re-export, or import Software and Documentation. Trademarks. A10 Networks, the A10 logo, ACOS, aFleX, aFlow, aGalaxy, aVCS, aXAPI, IDaccess, IDsentrie, IP-to-ID, SoftAX, Virtual Chassis, and VirtualN are trademarks or registered trademarks of A10 Networks, Inc. All other trademarks are property of their respective owners.

4 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide End User License Agreement Patents Protection. A10 Networks products including all AX Series are protected by one or more of the following US patents and patents pending: 7716378, 7675854, 7647635, 7552126, 20090049537, 20080229418, 20080040789, 20070283429, 20070271598, 20070180101.

Limited Warranty Disclaimer of Liabilities. REGARDLESS OF ANY REMEDY SET FORTH FAILS OF ITS ESSENTIAL PURPOSE OR OTHERWISE, IN NO EVENT WILL A10 NETWORKS OR ITS SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, PROFIT, OR LOST OR DAMAGED DATA, BUSINESS INTERRUPTION, LOSS OF CAPITAL, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY OR WHETHER ARISING OUT OF THE USE OF OR INABILITY TO USE PRODUCT OR OTHERWISE AND EVEN IF A10 NETWORKS OR ITS SUPPLIERS OR LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event shall A10 Networks’ or its suppliers' or licensors' liability to Customer, whether in contract, (including negligence), breach of warranty, or otherwise, exceed the price paid by Customer for the Software that gave rise to the claim or if the Software is part of another Product, the price paid for such other Product. Customer agrees that the limitations of liability and disclaimers set forth herein will apply regardless of whetherCustomer has accepted the Software or any other product or service delivered by A10 Networks. Customer acknowledges and agrees that A10 Networks has set its prices and entered into this Agreement in reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of risk between the parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same form an essential basis of the bargain between the parties. The Warranty and the End User License shall be governed by and construed in accordance with the laws of the State of California, without reference to or application of choice of law rules or principles. If any portion hereof is found to be void or unenforceable, the remaining provisions of the Agreement shall remain in full force and effect. This Agreement constitutes the entire and sole agreement between the parties with respect to the license of the use of A10 Networks Products unless otherwise supersedes by a written signed agreement.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

5 of 486

AX Series - System Configuration and Administration Guide End User License Agreement

6 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Obtaining Technical Assistance

Obtaining Technical Assistance For all customers, partners, resellers, and distributors who hold valid A10 Networks Regular and Technical Support service contracts, the A10 Networks Technical Assistance Center provides support services online and over the phone.

Corporate Headquarters A10 Networks, Inc. 2309 Bering Dr. San Jose, CA 95131-1125 USA Tel: +1-408-325-8668 (main) Tel: +1-888-822-7210 (support – toll-free in USA) Tel: +1-408-325-8676 (support – direct dial) Fax: +1-408-325-8666 www.a10networks.com

Collecting System Information The AX device provides a simple method to collect configuration and status information for Technical Support to use when diagnosing system issues. To collect system information, use either of the following methods.

USING THE GUI (RECOMMENDED) 1. 2. 3. 4. 5. 6. 7.

Log into the GUI. Select Monitor > System > Logging. On the menu bar, click Show Tech. Click Export. The File Download dialog appears. Click Save. The Save As dialog appears. Navigate to the location where you want to save the file, and click Save. Email the file as an attachment to [email protected].

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

7 of 486

AX Series - System Configuration and Administration Guide Obtaining Technical Assistance

USING THE CLI 1. Log into the CLI. 2. Enable logging in your terminal emulation application, to capture output generated by the CLI. 3. Enter the enable command to access the Privileged EXEC mode of the CLI. Enter your enable password at the Password prompt. 4. Enter the show techsupport command. 5. After the command output finishes, save the output in a file. 6. Email the file as an attachment to [email protected]. Note:

As an alternative to saving the output in a log file captured by your terminal emulation application, you can export the output from the CLI using the following command: show techsupport export [use-mgmt-port] url (For syntax information, see the AX Series CLI Reference.)

8 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide About This Document

About This Document This document describes the features of the A10 Networks AX Series™ Advanced Traffic Manager. Configuration examples of the major features are provided. Additional information is available for AX Series systems in the following documents. These documents are included on the documentation CD shipped with your AX Series system, and also are available on the A10 Networks support site: • AX Series Installation Guides • AX Series Application Delivery and Server Load Balancing Guide • AX Series Global Server Load Balancing Guide • AX Series GUI Reference • AX Series CLI Reference • AX Series aFleX Reference • AX Series MIB Reference • AX Series aXAPI Reference

This document assumes that you have already performed the basic deployment tasks described in the AX Series Installation Guide for your AX model. Note:

IPv6 migration features—Large-scale NAT, Dual-stack Lite, and so on— are not supported in 2.6.1.

Note:

This guide includes GUI configuration examples. Some GUI pages may have new options that are not shown in the example screen images. In these cases, the new options are not applicable to the examples. For information about any option in the GUI, see the AX Series GUI Reference.

A10 Virtual Application Delivery Community You can use your A10 support login to access the A10 Virtual Application Delivery Community (VirtualADC). The VirtualADC is an interactive forum where you can find detailed information from product specialists. You also can ask questions and leave comments. To access the VirtualADC, navigate here: http://www.a10networks.com/adc/ Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

9 of 486

AX Series - System Configuration and Administration Guide About This Document

System Description – The AX Series FIGURE 1

The AX Series™ Advanced Traffic Manager

The AX Series is the industry’s best performing application acceleration switch that helps organizations scale and maximize application availability through the world’s most advanced application delivery platform. The AX Series Advanced Core Operating System (ACOS) accelerates and secures critical business applications, provides the highest performance and reliability, and establishes a new industry-leading price/performance For more detailed information, see “System Overview” on page 23.

Audience This document is intended for use by network architects for determining applicability and planning implementation, and for system administrators for provision and maintenance of the A10 Networks AX Series.

10 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Contents

End User License Agreement

3

Obtaining Technical Assistance

7

Collecting System Information.............................................................................................................. 7

About This Document

9

A10 Virtual Application Delivery Community....................................................................................... 9 System Description – The AX Series .................................................................................................. 10 Audience................................................................................................................................................ 10

System Overview

23

AX Series Features............................................................................................................................... 23 ACOS Architecture ............................................................................................................................... 25 AX Software Processes .................................................................................................................. 26 SoftAX ............................................................................................................................................. 27 Local File Storage on AX Hardware Models ................................................................................... 28 Hardware Interfaces ............................................................................................................................. 30 Software Interfaces............................................................................................................................... 30 Server Load Balancing Features......................................................................................................... 31 Intelligent Server Selection ............................................................................................................. 32 SLB Configuration Templates ......................................................................................................... 32 Global Server Load Balancing ........................................................................................................ 34 Outbound Link Load Balancing ....................................................................................................... 34 Transparent Cache Switching ......................................................................................................... 35 Firewall Load Balancing .................................................................................................................. 35 Where Do I Start?.................................................................................................................................. 35

Basic Setup

37

Logging On............................................................................................................................................ 37 Logging Onto the CLI ...................................................................................................................... 39 Logging Onto the GUI ..................................................................................................................... 40 Configuring Basic System Parameters .............................................................................................. 43 Setting the Hostname and Other DNS Parameters ........................................................................ 43 Setting the CLI Banners .................................................................................................................. 44 Setting Time/Date Parameters ....................................................................................................... 46 Configuring Syslog Settings ............................................................................................................ 48

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

11 of 486

AX Series - System Configuration and Administration Guide Contents

Enabling SNMP .............................................................................................................................. 52 SNMP Traps ................................................................................................................................ 54 SNMP Communities and Views .................................................................................................. 56 SNMP Configuration Steps ......................................................................................................... 56 Configuration Examples .......................................................................................................................60 Replacing the Web Certificate..............................................................................................................66 Emailing Log Messages........................................................................................................................68

Network Setup

73

Overview ................................................................................................................................................73 Trunk Support ................................................................................................................................. 73 Virtual LAN Support ........................................................................................................................ 74 IP Subnet Support .......................................................................................................................... 75 Routing Support ............................................................................................................................. 76 Gateway Health Monitoring ............................................................................................................ 76 Layer 2/3 Virtualization ................................................................................................................... 76 High Availability .............................................................................................................................. 77 Management Interface Configuration..................................................................................................77 Configuration Example ................................................................................................................... 78 Transparent Mode Deployment............................................................................................................80 Configuration Example ................................................................................................................... 80 Route Mode Deployment ......................................................................................................................82 Configuration Example ................................................................................................................... 83

Link Trunking

87

Overview ................................................................................................................................................87 Static Trunk Configuration ...................................................................................................................87 Trunk Parameters and Trunk Interface Parameters ....................................................................... 88 Configuring Trunk Parameters ....................................................................................................... 89 Adding Ports to a Trunk .............................................................................................................. 89 Configuring Port-threshold Parameters ....................................................................................... 89 Configuring Interface-level Parameters on a Trunk ........................................................................ 90 Static Trunk Configuration Example ............................................................................................... 91 Dynamic Trunk Configuration ..............................................................................................................91 LACP Parameters .......................................................................................................................... 92 UDLD .......................................................................................................................................... 93 Configuration .................................................................................................................................. 94 Displaying LACP Information ......................................................................................................... 95 12 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Contents

Clearing LACP Statistics ................................................................................................................. 96 Configuration Example ................................................................................................................... 96

Gateway Health Monitoring

101

Overview.............................................................................................................................................. 101 Configuration ...................................................................................................................................... 103

Open Shortest Path First (OSPF)

105

Support for Multiple OSPFv2 and OSPFv3 Processes.................................................................... 105 Support for OSPFv2 and OSPFv3 on the Same Interface or Link.................................................. 105 OSPF MIB Support.............................................................................................................................. 105 OSPF Configuration Example............................................................................................................ 106 Interface Configuration ................................................................................................................. 106 Global OSPF Parameters ............................................................................................................. 107 OSPF Logging .............................................................................................................................. 108 Configuring Router Logging for OSPF ...................................................................................... 108

DHCP Relay

113

Overview.............................................................................................................................................. 113 Configuration ...................................................................................................................................... 114

AX Virtual Chassis System

121

Overview.............................................................................................................................................. 122 High Availability ............................................................................................................................ 125 vMaster Election ........................................................................................................................... 125 Heartbeat Messages ................................................................................................................. 129 Forced vMaster Takeover ......................................................................................................... 130 Automated Configuration Synchronization ................................................................................... 131 Manual Configuration Synchronization ...................................................................................... 134 Software Image Synchronization .................................................................................................. 134 Virtual Chassis Management Interface ......................................................................................... 135 Requirements ............................................................................................................................... 135 aVCS Parameters................................................................................................................................ 137 Deploying a Virtual Chassis (first-time deployment only) .............................................................. 140 Details for step 1 ........................................................................................................................... 140 First-Time Deployment Example .................................................................................................. 143 Forcing vMaster Takeover ............................................................................................................ 144 Determining a Device’s aVCS ID .................................................................................................. 145 Displaying aVCS Information ........................................................................................................ 145 Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

13 of 486

AX Series - System Configuration and Administration Guide Contents

Upgrading a Virtual Chassis ..............................................................................................................146 Adding a Configured AX Device to a Virtual Chassis......................................................................146 Overview ...................................................................................................................................... 147 Procedure ..................................................................................................................................... 152 Replacing a Device in a Virtual Chassis ...........................................................................................152

Role-Based Administration with Layer 2/3 Virtualization

155

Overview ..............................................................................................................................................156 Resource Partitions ...................................................................................................................... 157 Administrator Roles ...................................................................................................................... 159 Partition-Based Logging ............................................................................................................... 160 Partition-Based CLI Banner .......................................................................................................... 161 Layer 2/3 Virtualization ................................................................................................................. 161 Requirements ............................................................................................................................ 162 Per-partition Feature Support for Layer 2/3 Virtualization ......................................................... 165 Per-partition Default SLB Templates for Layer 2/3 Virtualization .............................................. 166 Limitations ................................................................................................................................. 166 Configuring Role-Based Administration...........................................................................................167 Configuring Private Partitions ....................................................................................................... 167 Migrating Resources Between Partitions .................................................................................. 169 Deleting a Partition .................................................................................................................... 169 Configuring a Custom GUI Access Role ...................................................................................... 170 Configuring Partition Admin Accounts .......................................................................................... 170 Disabling Private Partition Admin Access to the Shared Partition ................................................ 172 CLI Examples ............................................................................................................................... 173 RBA Configuration Without Layer 2/3 Virtualization .................................................................. 173 RBA Configuration With Layer 2/3 Virtualization ....................................................................... 174 Viewing and Saving the Configuration..............................................................................................178 Viewing the Configuration ............................................................................................................ 178 Saving the Configuration .............................................................................................................. 179 Switching To Another Partition..........................................................................................................180 Synchronizing the Configuration.......................................................................................................181 Manual Synchronization ............................................................................................................... 181 Operator Management of Real Servers .............................................................................................183

14 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Contents

VRRP-A High Availability

187

Overview.............................................................................................................................................. 187 Virtual Router ID ........................................................................................................................... 187 Partition Support ........................................................................................................................ 188 Default VRID ............................................................................................................................. 189 VRID Virtual MAC Addresses .................................................................................................... 189 Floating IP Addresses ................................................................................................................... 190 Configuration Synchronization ...................................................................................................... 191 Session Synchronization .............................................................................................................. 191 Active / Standby Device Selection ................................................................................................ 192 Failover ......................................................................................................................................... 194 VRRP-A Hello Messages .......................................................................................................... 195 Dynamic Priority Reduction ....................................................................................................... 195 Pre-emption ............................................................................................................................... 198 Force-self-standby ..................................................................................................................... 198 VRRP-A Interfaces ....................................................................................................................... 199 Explicitly Configured VRRP-A Interfaces (optional) .................................................................. 199 Comparison of VRRP-A and HA ................................................................................................... 200 VRRP-A Parameters ..................................................................................................................... 202 Deploying VRRP-A.............................................................................................................................. 205 Specify the VRRP-A Device ID ..................................................................................................... 205 Configuring Floating IP Addresses for VRRP-A VRIDs ................................................................ 205 Enable VRRP-A ............................................................................................................................ 206 Displaying VRRP-A Information .................................................................................................... 206 Manually Synchronizing the Configuration...................................................................................... 206 VRRP-A Information Included ....................................................................................................... 206 Peer IP Address Option ................................................................................................................ 207 Configuration Examples .................................................................................................................... 210 Simple Deployment ....................................................................................................................... 210 Deployment with Custom Priority Settings .................................................................................... 211 Configuration of Tracking Options ................................................................................................ 212

High Availability

215

Overview.............................................................................................................................................. 215 Layer 3 Active-Standby HA ........................................................................................................... 216 Layer 3 Active-Active HA .............................................................................................................. 218 Layer 2 Active-Standby HA (Inline Deployment) .......................................................................... 220 Preferred HA Port ...................................................................................................................... 223 Port Restart ............................................................................................................................... 224 Layer 3 Active-Standby HA (Inline Deployment) .......................................................................... 225 Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

15 of 486

AX Series - System Configuration and Administration Guide Contents

HA Messages ............................................................................................................................... 226 HA Heartbeat Messages ........................................................................................................... 227 Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6) ...................................... 227 HA Interfaces ................................................................................................................................ 228 Session Synchronization .............................................................................................................. 229 Optional Failover Triggers ............................................................................................................ 230 VLAN-based Failover ................................................................................................................ 230 Gateway-based Failover ........................................................................................................... 231 Route-based Failover ................................................................................................................ 231 Real Server or Port Health-based Failover ............................................................................... 232 VIP-based Failover .................................................................................................................... 232 How the Active AX Device Is Selected ......................................................................................... 234 HA Pre-Emption ........................................................................................................................... 236 HA Sets ........................................................................................................................................ 237 HA Configuration Parameters ...................................................................................................... 238 HA Status Indicators ...........................................................................................................................245 In the GUI .................................................................................................................................. 245 In the CLI .................................................................................................................................. 246 Configuring Layer 3 HA ......................................................................................................................246 Configuring Layer 2 HA (Inline Mode) ...............................................................................................256 Layer 2 Inline HA Configuration Example .................................................................................... 257 Configuring Layer 3 HA (Inline Mode) ...............................................................................................264 Layer 3 Inline HA Configuration Example .................................................................................... 265 Configuring Optional Failover Triggers ............................................................................................269 VLAN-Based Failover Example .................................................................................................... 270 Gateway-Based Failover Example ............................................................................................... 271 Route-Based Failover Example .................................................................................................... 273 VIP-Based Failover Example ....................................................................................................... 274 Forcing Active Groups to Change to Standby Status .....................................................................276 Enabling Session Synchronization ...................................................................................................277 Configuring OSPF-Related HA Parameters ......................................................................................279 OSPF Awareness of HA ............................................................................................................... 279 OSPF Support on Standby AX in Layer 3 Inline Mode ................................................................. 280 Manually Synchronizing Configuration Information........................................................................280 Configuration Items That Are Backed Up ..................................................................................... 281 Configuration Items That Are Not Backed Up ........................................................................... 282 Performing HA Synchronization ................................................................................................... 284 Tip for Ensuring Fast HA Failover .....................................................................................................286 16 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Contents

Configuration Synchronization without Reload

289

VRRP-A with aVCS Deployment Example ................................................................................ 290 HA with aVCS Deployment Example ........................................................................................ 291 Note Regarding HA Group ID .................................................................................................... 292

Network Address Translation

293

Overview.............................................................................................................................................. 293 Configuring Dynamic IP Source NAT................................................................................................ 295 Configuring Static IP Source NAT..................................................................................................... 301 NAT ALG Support for PPTP ............................................................................................................... 304 Configuring NAT ALG for PPTP ................................................................................................... 305 Mapping Allocation Method............................................................................................................... 308 Fast Aging for IP NATted ICMP and DNS Sessions......................................................................... 309 Client and Server TCP Resets for NATted TCP Sessions............................................................... 310 Requirements for Translation of DNS Traffic ................................................................................... 311 Pool-specific TCP Maximum Segment Life...................................................................................... 311 IP NAT Use in Transparent Mode in Multi-Netted Environment ..................................................... 312 NAT Range List Requires AX Interface or Route Within the Global Subnet ................................. 313 IP NAT in HA Configurations ............................................................................................................. 314 Configuring Dynamic IP NAT with Many Pools................................................................................ 315 Configure NAT Pools .................................................................................................................... 315 Configure LIDs .............................................................................................................................. 315 Configure a Class List ................................................................................................................... 316 Class List Syntax ....................................................................................................................... 316 Importing a Class List ................................................................................................................ 316 Configuring a Class List Using the CLI ...................................................................................... 317 Enable Inside Source NAT ........................................................................................................... 317 Configuration Example ................................................................................................................. 318

Management Security Features

321

Configuring Additional Admin Accounts ......................................................................................... 322 Configuring an Admin Account ..................................................................................................... 322 GUI Access Roles ..................................................................................................................... 324 Deleting an Admin Account .......................................................................................................... 329 Configuring Admin Lockout .............................................................................................................. 330 Admin Access Control Based on Management Interface ............................................................... 332

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

17 of 486

AX Series - System Configuration and Administration Guide Contents

Securing Admin Access by Ethernet ................................................................................................333 Displaying the Current Management Access Settings ................................................................. 336 Regaining Access if You Accidentally Block All Access ............................................................... 337 SSH Public Key Authentication for SSH Management Access.......................................................337 Changing Web Access Settings ........................................................................................................340 Command Auditing .............................................................................................................................342 Configuring AAA for Admin Access..................................................................................................344 Authentication ............................................................................................................................... 344 Authentication Process ............................................................................................................. 344 Token-based Authentication Support for RADIUS .................................................................... 346 Authorization ................................................................................................................................ 348 Authorization Based on Management Interface ........................................................................ 348 Authorization for GUI Access .................................................................................................... 349 Authorization for CLI Access ..................................................................................................... 351 Authorization Based on Private Partition ................................................................................... 354 RADIUS Authorization Based on Service-Type ........................................................................ 355 Accounting .................................................................................................................................... 355 Command Accounting (TACACS+ only) ................................................................................... 356 TACACS+ Accounting Debug Options ...................................................................................... 356 Configuring AAA for Admin Access .............................................................................................. 356 Configuring Authentication ........................................................................................................ 357 Configuring Authorization .......................................................................................................... 360 Configuring Accounting ............................................................................................................. 360 Configuring Windows IAS for AX RADIUS Authentication ........................................................... 365 Procedure Overview .................................................................................................................. 365 Configure Access Groups ......................................................................................................... 366 Configure RADIUS Client for AX Device ................................................................................... 367 Configure Remote Access Policies ........................................................................................... 369 Add AD Users to AX Access Groups ........................................................................................ 378 Register the IAS Server in Active Directory .............................................................................. 379 Configure RADIUS in the AX Device ........................................................................................ 380 Test the Configuration ............................................................................................................... 380

Traffic Security Features

381

DDoS Protection..................................................................................................................................381 Enabling DDoS Protection ............................................................................................................ 383 Configuring IP Anomaly Filters for System-Wide PBSLB ............................................................. 383 Displaying and Clearing IP Anomaly Statistics ............................................................................. 384

18 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Contents

SYN Cookies ....................................................................................................................................... 385 The Service Provided By SYN Cookies ........................................................................................ 385 Enabling Hardware-Based SYN Cookies ..................................................................................... 387 Configuration when Target VIP and Client-side Router Are in Different Subnets ..................... 388 Enabling Software-Based SYN Cookies ....................................................................................... 389 SACK and MSS with Software-based SYN-cookies ................................................................. 389 Configuring Layer 2/3 SYN Cookie Support ................................................................................. 390 ICMP Rate Limiting ............................................................................................................................. 391 Access Control Lists (ACLs) ............................................................................................................. 394 How ACLs Are Used ..................................................................................................................... 394 Configuring Standard IPv4 ACLs .................................................................................................. 395 Configuring Extended IPv4 ACLs ................................................................................................. 397 Configuring Extended IPv6 ACLs ................................................................................................. 401 Adding a Remark to an ACL ......................................................................................................... 405 Transparent Session Logging ....................................................................................................... 405 Sample Log Messages for Transparent Sessions ..................................................................... 406 Configuration ............................................................................................................................. 407 Applying an ACL to an Interface ................................................................................................... 407 Applying an ACL to a Virtual Server Port ...................................................................................... 408 Using an ACL to Control Management Access ............................................................................ 409 Using an ACL for NAT .................................................................................................................. 409 Resequencing ACL Rules ............................................................................................................. 410 Source-IP Based Connection Rate Limiting..................................................................................... 412 Parameters ................................................................................................................................... 412 Log Messages .............................................................................................................................. 413 Deployment Considerations .......................................................................................................... 414 Configuration ............................................................................................................................. 415 Configuration Examples ................................................................................................................ 416

Policy-Based SLB (PBSLB)

419

Configuring a Black/White List.......................................................................................................... 419 Example Black/White List ............................................................................................................. 420 Dynamic Black/White-list Client Entries ........................................................................................ 421 Connection Limit for Dynamic Entries ....................................................................................... 421 Aging of Dynamic Entries .......................................................................................................... 421 Wildcard Address Support in PBSLB Policies Bound to Virtual Ports ....................................... 422 Configuring System-Wide PBSLB..................................................................................................... 422 Displaying and Clearing System-Wide PBSLB Information .......................................................... 424

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

19 of 486

AX Series - System Configuration and Administration Guide Contents

Configuring PBSLB for Individual Virtual Ports...............................................................................424 Displaying PBSLB Information ..................................................................................................... 432 CLI Configuration Examples ......................................................................................................... 433 Configuration Example—Sockstress Attack Protection .................................................................434 System-wide PBSLB Policy Configuration ................................................................................... 435 Statistics Display ....................................................................................................................... 435

Specifying the Source Interface for Management Traffic

437

Using the Management Interface as the Source for Management Traffic......................................437 Route Tables ................................................................................................................................ 437 Management Routing Options ...................................................................................................... 438 Enabling Use of the Management Interface as the Source for Automated Management Traffic ........................................................................................................................................ 439 Using the Management Interface as the Source Interface for Manually Generated Management Traffic .................................................................................................................. 440 Commands at the User EXEC Level ......................................................................................... 440 Commands at the Privileged EXEC Level ................................................................................. 440 Commands at the Global Configuration Level .......................................................................... 440 Show Commands ...................................................................................................................... 441 Using a Loopback Interface as the Source for Management Traffic ............................................ 441

Boot Options

445

Storage Areas ......................................................................................................................................445 Displaying Storage Information .................................................................................................... 446 Displaying the Storage Location for Future Reboots .................................................................... 448 Booting from a Different Storage Area..............................................................................................449 Temporarily Changing the Storage Location for the Next Reboot ................................................ 449 Permanently Changing the Storage Location for Future Reboots ................................................ 450

Configuration Management

455

Backing Up System Information ........................................................................................................455 Saving Multiple Configuration Files Locally.....................................................................................457 Configuration Profiles ................................................................................................................... 457

VLAN-to-VLAN Bridging

465

Overview ..............................................................................................................................................465 Configuration.......................................................................................................................................466

20 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Contents

FIPS Support

469

FIPS-Compliant and FIPS-Certified AX Models ............................................................................... 469 FIPS Compliance for Hardware ......................................................................................................... 470 SSL Modules ................................................................................................................................ 470 Tamper-Proof Seals ...................................................................................................................... 470 Changes to AX Chassis ................................................................................................................ 472 FIPS Compliance for SSL................................................................................................................... 472 FIPS Compliance for Software .......................................................................................................... 473 Software Upgrade Image .............................................................................................................. 473 Ports ............................................................................................................................................. 473 RMAs ............................................................................................................................................ 473 Lost Passwords ............................................................................................................................ 474 Web Support for FIPS Compliance ................................................................................................... 474 CLI Support for FIPS Compliance ..................................................................................................... 474 FIPS-compliant Web Server............................................................................................................... 475

Fail-safe Automatic Recovery

477

Error Types Monitored by Automatic Recovery .............................................................................. 477 Hardware Errors ........................................................................................................................... 477 Software Errors ............................................................................................................................. 478 Recovery Timeout............................................................................................................................... 478 Configuration ...................................................................................................................................... 479

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

21 of 486

AX Series - System Configuration and Administration Guide Contents

22 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide AX Series Features

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

AX Series Features Key features of the AX Series include the following. Note:

Support for some features depends on AX model or software version. The specific models and software versions required are listed in the detailed sections for the features. • Application Delivery Features • Comprehensive IPv4/IPv6 Support • Transparent (Layer 2) and gateway (Layer 3) mode support for • • • • • • •

easy deployment into existing infrastructures Static trunking; dynamic trunking with Link Aggregation Control Protocol (LACP) Standard Network Address Translation (NAT) – IPv4-IPv4, IPv6-IPv6, ALG support for PPTP OSPFv2 for IPv4, OSPFv3 for IPv6 IS-IS for IPv4 and IPv6 Internal BGP for IPv4 and IPv6 IPv4/IPv6 static routes DHCP relay

• Advanced Layer 4/7 Server Load Balancing • Fast TCP, fast UDP, fast HTTP, and full HTTP Proxy • Comprehensive protocol support: HTTP, HTTPS, FTP, TFTP,

TCP, UDP, SSL, SIP, SMTP, and others • Comprehensive load-balancing methods – weight-based, connection-based, request-based, and response-based methods, as well as simple round robin • Protocol translation – support for mixed IPv4/IPv6 environments • Advanced health monitoring • Customizable configuration templates • RAM caching of web content

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

23 of 486

AX Series - System Configuration and Administration Guide AX Series Features • Firewall Load Balancing (FWLB) • Global Server Load Balancing (GSLB) • Transparent Cache Switching (TCS) • High Availability (HA) • Active-Active, Active-Standby, and Layer 2/3 inline mode configu-

rations with sub-second failover • Layer 4 session synchronization • Configuration synchronization • VRRP-like syntax • Acceleration and Security • Federal Information Processing Standards (FIPS) compliance • SSL acceleration and offload • Traffic security • Management access security – Local admin database and support

for optional remote RADIUS or TACACS+ AAA • Spam filter support (Policy-Based SLB) – High-speed application

of very large black/white lists that filter based on source or destination IP host or subnet address • DoS attack detection and prevention • Access Control Lists (ACLs) • DNS Application Firewall – Solution consisting of the following: • Traffic validation – Drop or redirect malformed DNS queries • High performance surge protection: • DNS caching on per-VIP or per-record basis • Rate-based DNS caching • Throttling based on domain name • Dynamic traffic flow regulation: • Source-IP based connection rate limiting • Policy-Based SLB (black/white lists) • aFleX Tcl-like Scripting Language • XML Application Programming Interface (aXAPI)

24 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide ACOS Architecture • System Management • Dedicated management interface • Multiple access methods – SSH, Telnet, HTTPS • Web-based Graphical User Interface (GUI) with language localiza-

tion • Industry-standard Command Line Interface (CLI) support • On-demand backup of configuration files, logs, and system files • SNMP, syslog, alerting • AX Series Virtual Chassis System (aVCS), for managing multiple

AX devices as a single device • Virtualized Management, provided by Role-Based Administration

(RBA) • Troubleshooting tools • Port mirroring • AXdebug subsystem for packet capture

ACOS Architecture 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 AX device into your network in transparent mode or gateway (route) mode. • Transparent mode – The AX device has a single IP interface. For multi-

netted environments, you can configure multiple Virtual LANs (VLANs). • Route mode – Each AX interface is in a separate IP subnet.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

25 of 486

AX Series - System Configuration and Administration Guide ACOS Architecture

AX Software Processes The AX software performs its many tasks using the following processes: • a10mon – Parent process of the AX device. This process is executed

when the system comes up. The a10mon process does the following: • Brings AX user-space processes up and down. • Monitors all its child processes and restarts a process and all depen-

dent processes if any of them die. • syslogd – System logger daemon that logs kernel and system events. • a10logd – Fetches all the logs from the AX Log database. • a10timer – Schedules and executes scheduled tasks. • a10stat – Monitors the status of all the main processes of the AX device,

such as a10switch (on models AX 2200 and higher) and a10lb. The a10stat process probes every thread within these processes to ensure that they are responsive. If a thread is deemed unhealthy, a10stat kills the process, after which a10mon restarts the process and other processes associated with it. • a10switch – Contains libraries and APIs to program the Switching ASIC

to perform Layer 2 and Layer 3 switching at wire speed. • a10hm – Performs health-checking for real servers and services. This

process sends pre-configured requests to external servers at pre-defined intervals. If a server or individual service does not respond, it is marked down. Once the server or service starts responding again, it is marked up. • a10rt – Routing daemon, which maintains the routing table with routes

injected from OSPF, as well as static routes. • a10rip – Implements RIPv1 and v2 routing protocols. • a10ospf – Implements the OSPFv2 routing protocol. • a10snmpd – SNMPv2c and v3 agent, which services MIB requests. • a10wa – Embedded Web Server residing on the AX 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 AX device. This process contains all the intelli-

gence to perform Server Load Balancing.

26 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide ACOS Architecture • rimacli – This process is automatically invoked when an admin logs into

the AX device through an interface address. The admin is presented a Command Line Interface (CLI) that can issue and save commands to configure the system.

SoftAX SoftAX is a fully operational software-only version of A10 Networks’ line of AX Series Advanced Traffic Managers / Server Load Balancers. SoftAX is available as a virtual machine image in Open Virtualization Format (OVF). You can install SoftAX on a hardware platform running VMware ESX 4.0 or higher, or ESXi 4.0 or higher. FIGURE 1

SoftAX

With a few exceptions, the feature support on the AX Series is the same as the feature support on hardware-based AX models.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

27 of 486

AX Series - System Configuration and Administration Guide ACOS Architecture Feature Support With the following exceptions, the same features supported on AX hardware models are supported on the SoftAX. The following features are not supported on SoftAX: • Transparent (Layer 2) deployment • Hardware-specific features (for example, hardware-based HTTP/

HTTPS compression and hardware-based SSL acceleration) • Role-Based Administration (RBA). Only the shared partition is sup-

ported. Private partitions are not supported. • IPv6 migration features (Large-scale NAT, DS-Lite, NAT64/DNS64) • Port mirroring • Trunking

More Information For installation information, see the SoftAX Installation Guide. For feature information, see the rest of this guide (AX Series System Configuration and Administration Guide) and the guides listed in “About This Document” on page 9.

Local File Storage on AX Hardware Models Every AX model includes one of the following types of local file storage devices: • Solid State Drive (SSD) – Used in 64-bit ACOS models and “-11” mod-

els: • AX 2500 • AX 2600 • AX 3000 • AX 5100 • AX 5200 • AX 5200-11 • AX 1030 • AX 3030

28 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide ACOS Architecture • AX 1000-11 • AX 2200-11 • AX 3000-11-GCF • AX 3200-11 • Hard disk – Used in 32-bit ACOS models (except “-11” models): • AX 1000 • AX 2000 • AX 2100 • AX 2200 • AX 3100 • AX 3200

AX devices use local storage for application files and for data objects used for monitoring. The amount of storage used for these types of data depends on the AX model and on how the devices are used. On average, the following amounts of storage are used for these types of data on 64-bit ACOS models: • AX 2500, AX 2600 – 15 Gigabytes (G) or less • AX 3000 – 20 G or less • AX 5100, AX 5200 – 35 G or less

Application files include system images, configuration files, aFleX scripts, certificate and key files, black/white list files, class-list files, log messages, CLI audit log messages, core dump files, show techsupport files (up to 30days’ worth), and other miscellaneous files. The size of all application files varies depending on the configuration of the system and other factors. The show techsupport files use no more than 3-4 G. aFleX scripts range from 0-500 KB. Monitoring data includes objects for CPU, disk, memory, global statistics, port statistics, and 30-day SLB statistics. The 30-day SLB statistics include objects for real servers, virtual servers, real ports, virtual ports, server groups, service groups, and service-group members. The 30-day SLB statistics use the most storage among the monitoring objects. For the maximum configuration, the 30-day SLB statistics can use the following amounts of storage on 64-bit ACOS models:

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

29 of 486

AX Series - System Configuration and Administration Guide Hardware Interfaces • AX 2500, AX 2600 – 3 G or less • AX 3000 – 9 G or less • AX 5100, AX 5200 – 26 G or less

If there is a storage shortage, the software dynamically adjusts the maximum number of SLB monitoring objects to prevent consumption of the remaining storage.

Hardware Interfaces The AX device supports the following physical interfaces: • 1000BaseT (GOC) + SFP Mini GBIC Fiber Ports • On models AX 3100, AX 3200, AX 5100, AX 5200, and AX 5200-11,

10G XFP-SR (short range) single-mode fiber port or XFP-LR (long range) multi-mode fiber port, depending on order • Management Ethernet Port • RJ-45 Console Port

Generally, the fiber ports do not require any configuration other than IP interface(s). When you plug in a port, the port speed and mode (full-duplex or half-duplex) are automatically negotiated with the other end of the link. The management Ethernet port allows an out-of-band IP connection to the switch for management. The management interface traffic is isolated from the traffic on the other Ethernet ports. The serial console port is for direct connection of a laptop PC to the AX device.

Software Interfaces The AX device supports the following management interfaces: • Graphical User Interface (GUI) • Command Line Interface (CLI) accessible using console, Telnet, or

Secure Shell (v1 and v2) • Simple Network Management Protocol (SNMP) v1, v2c, and v3 • XML Application Programming Interface (aXAPI)

30 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Server Load Balancing Features The configuration examples in this manual show how to configure the AX Series using the CLI and GUI. For more information about the AX management interfaces, see the following documents: • AX Series GUI Reference • AX Series CLI Reference • AX Series MIB Reference • AX Series aXAPI Reference

Server Load Balancing Features Server Load Balancing (SLB) is a suite of resource management features that make server farms more reliable and efficient. You can easily grow server farms in response to changing traffic flow, while protecting the servers behind a common virtual IP address. From the perspective of a client who accesses services, requests go to and arrive from a single IP address. The client is unaware that the server is in fact multiple servers managed by an AX 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 AX configuration for the virtual server, and the new real server becomes accessible immediately.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

31 of 486

AX Series - System Configuration and Administration Guide Server Load Balancing Features FIGURE 2

SLB Example

Intelligent Server Selection The services managed by the AX device are controlled by service groups. A service group is a set of real servers. The AX 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 AX device provides a robust set of configurable health monitors for checking the health (availability) of servers and individual services.

SLB Configuration Templates SLB configuration is simplified by the use of templates. Templates simplify configuration by enabling you to configure common settings once and use

32 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Server Load Balancing Features them in multiple service configurations. The AX device provides templates to control server and port configuration parameters, connectivity parameters, and application parameters. Server and Port Configuration Templates The AX 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 AX 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 AX device sends TCP Resets to clients or servers after a session times out • UDP – Controls UDP connection settings such as the idle timeout for

unused sessions, and specifies how quickly sessions are terminated after a server response is received Application Templates The following types of application templates are provided: • 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 • Policy – Uses Policy-based SLB (PBSLB) to permit or deny clients, or

direct them to service groups, based on client black/white lists • Cache – Caches web content on the AX device to enhance website per-

formance for clients • Client SSL – Offloads SSL validation tasks from real servers • Server SSL – Validates real servers on behalf of clients

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

33 of 486

AX Series - System Configuration and Administration Guide Server Load Balancing Features • Connection reuse – Reduces overhead from TCP connection setup by

establishing and reusing TCP connections with real servers for multiple client requests • Cookie persistence – Inserts a cookie into server replies to clients, to

direct clients to the same service group, real server, or real service port for subsequent requests for the service • Source-IP persistence – Directs a given client, identified by its IP

address, to the same service port, server, or service group • Destination-IP persistence – Configures persistence to real servers based

on destination IP address • SSL session-ID persistence – Directs all client requests for a given vir-

tual port, and that have a given SSL session ID, to the same real server and real port • SIP – Customizes settings for load balancing of Session Initiation Proto-

col (SIP) traffic • SMTP – Configures STARTTLS support for Simple Mail Transfer Pro-

tocol (SMTP) clients • Streaming-media – Directs client requests based on the requested con-

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

Global Server Load Balancing Global Server Load Balancing (GSLB) allows you to manage multiple SLB sites and direct clients to the best site. Site selection is based on metrics including the site’s health and the site’s geographic proximity to the client.

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

34 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Where Do I Start?

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. Note:

Beginning in AX Release 2.6.0, the fwlb and show fwlb CLI commands and their equivalent GUI options are no longer supported. To configure FWLB, use a wildcard VIP instead. For information, contact A10 Networks.

Where Do I Start? • To configure basic system settings, see “Basic Setup” on page 37. • To configure network settings, see “Network Setup” on page 73. • To configure security features, see the following chapters: • “Management Security Features” on page 321 • “Traffic Security Features” on page 381 • “Policy-Based SLB (PBSLB)” on page 419 • “Geo-location-based Access Control for VIPs” chapter in the AX

Series Application Delivery and Server Load Balancing Guide • “IP Limiting” chapter in the AX Series Application Delivery and

Server Load Balancing Guide • To configure application delivery or Server Load Balancing features, see

the AX Series Application Delivery and Server Load Balancing Guide.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

35 of 486

AX Series - System Configuration and Administration Guide Where Do I Start?

36 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Logging On

Basic Setup This chapter describes how to log onto the AX device and how to configure the following basic system parameters: • Hostname and other Domain Name Server (DNS) settings • CLI banner messages • Date/time settings • System log (Syslog) settings • Simple Network Management Protocol (SNMP) settings

After you are through with this chapter, go to “Network Setup” on page 73. Note:

The only basic parameters that you are required to configure are date/time settings. Configuring the other parameters is optional.

Note:

This chapter does not describe how to access the serial console interface. For that information, see the installation guide for your AX model.

Caution:

When you make configuration changes, be sure to remember to save the changes. Unsaved configuration changes will be lost following a reboot. To save changes, click Save on the top row of the GUI window or enter the write memory command in the CLI.

Logging On AX Series devices provide the following management 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 following protocols:

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

37 of 486

AX Series - System Configuration and Administration Guide Logging On • Secure protocol – Hypertext Transfer Protocol over Secure Socket

Layer (HTTPS) • Unsecure protocol – Hypertext Transfer Protocol (HTTP) • aXAPI – XML Application Programming Interface based on the Repre-

sentational State Transfer (REST) architecture. The aXAPI enables you to use custom third-party applications to configure and monitor Server Load Balancing (SLB) parameters on the AX device, and to monitor Ethernet interfaces. (For more information, see the AX Series aXAPI Reference.) Note:

By default, Telnet access is disabled on all interfaces, including the management interface. SSH, HTTP, HTTPS, and SNMP access are enabled by default on the management interface only, and disabled by default on all data interfaces.

Note:

The AX device supports a maximum of 128 simultaneous management sessions. This includes any combination of CLI, GUI, and aXAPI sessions. Federal Information Processing Standards (FIPS) Compliance To comply with FIPS security standards, beginning in AX Release 2.4.2, management access to the AX device has the following requirements: • Web access to GUI – The browser used to access the AX GUI must sup-

port encryption keys of 128 bits or longer. Shorter encryption keys (for example, 40 bits) are not supported. The browser also must support TLS 1.0. Beginning in AX Release 2.6.1-P1, browsers that support only SSL are not supported. • SSH access to CLI – The SSH client used to access the CLI must sup-

port SSHv2. SSHv1 is not supported. The SSHv2 client must support one of the following encryption ciphers: • 3des-cbc • aes128-cbc • aes192-cbc • aes256-cbc Other ciphers are not supported.

38 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Logging On

Logging Onto the CLI Note:

The AX Series provides advanced features for securing management access to the device. This section assumes that only the basic security settings are in place. (For more information about securing management access, see “Management Security Features” on page 321.) To log onto the CLI using SSH: 1. On a PC connected to a network that can access the AX device’s management interface, open an SSH connection to the IP address of the management interface. 2. Generally, if this the first time the SSH client has accessed the AX 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: AX> The User EXEC level allows you to enter a few basic commands, including some show commands as well as ping and traceroute.

Note:

The “AX” in the CLI prompt is the hostname configured on the device, which is “AX” by default. If the hostname has already been changed, the new hostname appears in the prompt instead of “AX”. 5. To access the Privileged EXEC level of the CLI and allow access to all configuration levels, enter the enable command. At the Password: prompt, enter the enable password. (This is not the same as the admin password, although it is possible to configure the same value for both passwords.) If the enable password is correct, the command prompt for the Privileged EXEC level of the CLI appears: AX# 6. To access the global configuration level, enter the config command. The following command prompt appears: AX(config)#

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

39 of 486

AX Series - System Configuration and Administration Guide Logging On

Logging Onto the GUI Web access to the AX device is supported on the Web browsers listed in Table 1. TABLE 1

GUI Browser Support Platform

Browser IE 6.0-9.0 Firefox 3.5-7.0 Safari 3.0 Safari 2.0 Chrome 5.0

Windows Supported Supported Not Supported Not Supported Supported

Linux N/A Supported N/A N/A Supported

MAC N/A N/A Supported Not Supported Supported

A screen resolution of at least 1024x768 is recommended. 1. Open one of the Web browsers listed in Table 1. 2. In the URL field, enter the IP address of the AX device’s management interface. 3. If the browser displays a certificate warning, select the option to continue to the server (the AX device). Note:

To prevent the certificate warning from appearing in the future, you can install a certificate signed by a Certificate Authority. See “Replacing the Web Certificate” on page 66. A login dialog is displayed. The name and appearance of the dialog depends on the browser you are using.

40 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Logging On FIGURE 3

GUI Login Dialog (Internet Explorer)

4. Enter your admin username and password and click OK. Note:

The default admin username and password are “admin”, “a10”. The Summary page appears, showing at-a-glance information for your AX device. You can access this page again at any time while using the GUI, by selecting Monitor > Overview > Summary.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

41 of 486

AX Series - System Configuration and Administration Guide Logging On FIGURE 4

42 of 486

Monitor > Overview > Summary

Note:

GUI management sessions are not automatically terminated when you close the browser window. The session remains in effect until it times out. To immediately terminate a GUI session, click Logout.

Note:

For more information about the GUI, see the AX Series GUI Reference or the GUI online help.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters

Configuring Basic System Parameters This section describes the basic system parameters and provides CLI and GUI steps for configuring them. Note:

If you plan to use the GUI, the Basic System page under Config Mode also provides configuration access to most of the system parameters described in this chapter. For information, navigate to Config Mode > Basic System, then click Help.

Setting the Hostname and Other DNS Parameters The default hostname is “AX”. To change the hostname, use either of the following methods. Note:

Do not use a period ( . ) in the AX hostname. If you do use a period, the AX device will use the text after the period as the DNS suffix instead of the DNS suffix you configure.

USING THE GUI 1. Select Config > Network > DNS. The DNS page appears. 2. In the Hostname field, edit the name to one that will uniquely identify this particular AX device (for example, “AX-SLB1”). 3. In the DNS Suffix field, enter the domain name to which the host (AX Series) belongs. 4. In the Primary DNS field, enter the IP address of the external DNS server the AX Series should use for resolving DNS queries. 5. In the Secondary DNS field, enter the IP address of an external backup DNS server the AX Series should use if the primary DNS server is unavailable. 6. Click OK.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

43 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters

USING THE CLI 1. Access the global configuration level of the CLI: AX>enable Password:enable-password AX#config AX(config)# 2. Use the following command to change the hostname: hostname string After you enter this command, the command prompt should change to the same value as the new hostname. Note:

The “ > ” or “ # ” character and characters in parentheses before “ # ” indicate the CLI level you are on and are not part of the hostname. 3. To set the default domain name (DNS suffix) for hostnames on the AX device, use the following command: ip dns suffix string 4. To specify the DNS servers the AX should use for resolving DNS requests, use the following command: ip dns {primary | secondary} ipaddr The primary option specifies the DNS server the AX device should always try to use first. The secondary option specifies the DNS server that the AX device should use if the primary DNS server is unavailable.

Setting the CLI Banners The CLI displays banner messages when you log onto the CLI. By default, the messages shown in bold type in the following example are displayed: login as: admin Welcome to AX Using keyboard-interactive authentication. Password: Last login: Thu Feb 192.168.1.144

7 13:44:32 2008 from

[type ? for help]

You can format banner text as a single line or multiple lines.

44 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

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

USING THE GUI 1. Select Config > System > Settings. 2. On the menu bar, select Terminal > Banner. 3. 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 configuration. 4. If you are configuring both messages, repeat step 3 for the other message. 5. Click OK.

USING THE CLI To change one or both banners, use the following command: [no] banner {exec | login} [multi-line end-marker] line The login option changes the first banner, which is displayed after you enter the admin username. The exec option changes the second banner, which is displayed after you enter the admin password. To use blank spaces within the banner, enclose the entire banner string with double quotation marks.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

45 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters

Setting Time/Date Parameters To configure time/date parameters: • Set the timezone. • Set the system time and date manually or configure the AX device to use

a Network Time Protocol (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 AX device automatically adjusts the time for Daylight Savings Time based on the timezone you select.

Note:

When you change the AX timezone or system time, the statistical database is cleared. This database contains general system statistics (performance, and CPU, memory, and disk utilization) and SLB statistics. For example, in the GUI, the graphs displayed on the Monitor > Overview page are cleared.

USING THE GUI 1. Select Config > System > Time. The Date/Time page appears. • To set the time and date by synchronizing them with the time and date on the PC from which you are running the GUI, click Sync Local Time. • To configure the time and date manually: a. Enter the date in the Date field or select the date using the 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. In the Update System Clock Every field, enter the number of minutes you want the AX device to wait between synchronizations with the NTP server. 2. To select the timezone: a. Click Time Zone. b. From the Time Zone Name pull-down list, select the time zone.

46 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters c. Click OK. d. Click Date/Time to re-display the section, if not already displayed. 3. Click OK.

USING THE CLI To set the timezone Enter the following command at the global configuration level of the CLI: clock timezone timezone [nodst] The nodst option disables Daylight Savings Time (DST) for the zone. DST is enabled by default, if applicable to the timezone. To view the available timezones, enter the following command: clock timezone ? To configure the AX device to use NTP 1. To specify the NTP server to use, enter the following command at the global configuration level of the CLI: ntp server {hostname | ipaddr} You can configure a maximum of 4 NTP servers. 2. To enable NTP and synchronize the AX clock with the NTP server, enter the following command: ntp enable To set the time and date manually 1. Return to the Privileged EXEC level of the CLI by entering the exit command. 2. Enter the following command at the Privileged EXEC level of the CLI: clock set time day month year Enter the time and date in the following format: time – hh:mm:ss day – 1-31 month – January, February, March, ... year – 2008, 2009 ...

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

47 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters Note:

The clock is based on 24 hours. For example, for 1 p.m., enter the hour as “13”. 3. To display clock settings, use the following command: show clock [detail]

Configuring Syslog Settings The AX device logs system events with Syslog messages. The AX device can send Syslog messages to the following places: • Local buffer • Console CLI session • Console SSH and Telnet sessions • External Syslog server • Email address(es) • SNMP servers (for events that are logged by SNMP traps)

Logging to the local buffer and to CLI sessions is enabled by default. Logging to other places requires additional configuration. The standard Syslog message severity levels are supported: • Emergency – 0 • Alert – 1 • Critical – 2 • Error – 3 • Warning – 4 • Notification – 5 • Information – 6 • Debugging – 7

Table 2 lists the configurable Syslog parameters.

48 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters TABLE 2

Configurable System Log Settings

Parameter Disposition (message target)

Description Output options for each message level. For each message level, you can select which of the following output options to enable:

Supported Values The following message levels can be individually selected for each output option:

• Console – Messages are displayed in Console sessions.

• Emergency (0)

• Buffered – Messages are stored in the system log buffer.

• Critical (2)

• Email – Messages are sent to the email addresses in the Email To list. (See below.)

• Warning (4)

• SNMP – SNMP traps are generated and sent to the SNMP receivers.

Logging Email Filter Logging Email Buffer Number Logging Email Buffer Time Facility

• Error (3) • Notification (5) • Information (6)

• Syslog – Messages are sent to the external log servers specified in the Log Server fields. (See below.)

• Debug (7)

• Monitor – Messages are displayed in Telnet and SSH sessions.

Only Emergency, Alert, Critical, and Notification can be selected for Email.

Note: For information about emailing log messages, see “Emailing Log Messages” on page 68. Settings for sending log messages by email.

Standard Syslog facility to use.

Log Buffer Entries

Maximum number of log entries the log buffer can store.

Log Server

IP addresses or fully-qualified domain names of external log servers. Only the message levels for which Syslog is selected in the Disposition list are sent to log servers.

Log Server Port

• Alert (1)

Note: By default, the AX device can reach remote log servers only if they are reachable through the AX device’s data ports, not the management port. To enable the AX device to reach remote log servers through the management port, see “Specifying the Source Interface for Management Traffic” on page 437. Protocol port to which log messages sent to external log servers are addressed.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

Only Emergency, Alert, and Critical can be selected for SNMP.

See “Emailing Log Messages” on page 68.

Standard Syslog facilities listed in RFC 3164. 10000 to 50000 entries Default: 30000 Any valid IP address or fully-qualified domain name. Default: None configured

Any valid protocol port number Default: 514

49 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters TABLE 2

Configurable System Log Settings (Continued)

Parameter Email To

Description Email addresses to which to send log messages. Only the message levels for which Email is selected in the Disposition list are sent to log servers.

SMTP Server

IP address or fully-qualified domain name of an email server using Simple Message Transfer Protocol.

Supported Values Valid email address. Click the down arrow next to the input field to add another address (up to 10). Each email address can be a maximum of 31 characters long. Any valid IP address or fully-qualified domain name. Default: None configured

SMTP Server Port

Note: By default, the AX device can reach SMTP servers only if they are reachable through the AX device’s data ports, not the management port. To enable the AX device to reach SMTP servers through the management port, see “Specifying the Source Interface for Management Traffic” on page 437. Protocol port to which email messages sent to the SMTP server are addressed.

Mail From

Specifies the email From address.

Default: 25 Valid email address

Need Authentication

Specifies whether access to the SMTP server requires authentication.

Default: Not set Selected (enabled) or unselected (disabled)

Username

Username required for access to the SMTP server.

Default: disabled Valid username

Password

Password required for access to the SMTP server.

Default: Not set Valid password

Any valid protocol port number

Default: Not set

Log Rate Limiting The AX device uses a log rate limiting mechanism to ensure against overflow of external log servers and the internal logging buffer. The rate limit for external logging is 15,000 messages per second from the AX device. The rate limit for internal logging is 32 messages per second from the AX device. • If the number of new messages within a one-second interval exceeds 32,

then during the next one-second interval, the AX 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 AX will again send messages to the local logging buffer as well as the

50 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters external log server. In any case, all messages (up to 15,000 per second) get sent to the external log servers.

USING THE GUI 1. Select Config > System > Settings. 2. Select Log on the menu bar. 3. Change settings as needed. (For descriptions of the settings, see Table 2.) 4. Click OK.

USING THE CLI 1. To change the severity level of messages that are logged in the local buffer, use the following command: logging buffered severity-level 2. To change the severity level of messages that are logged in other places, use the following command: logging target severity-level The target can be one of the following: • console – Serial console • email – Email • monitor – Telnet and SSH sessions • syslog – external Syslog host • trap – external SNMP trap host Note:

Only severity levels emergency, alert, critical, and notification can be sent by email. Sending log messages by email requires additional configuration. See “Emailing Log Messages” on page 68. 3. To configure the AX device to send log messages to an external Syslog server, use the following command to specify the server: logging host ipaddr [ipaddr...] [port protocol-port] You can enter more than one server IP address on the same command line. The default protocol port is 514. You can specify only one protocol port with the command. All servers must use the same protocol port to listen for syslog messages. If you use the command to add some log servers, then need to add a new log server later, you must enter all server IP addresses in the new com-

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

51 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters mand. Each time you enter the logging host command, it replaces any set of servers and syslog port configured by the previous logging host command. 4. To configure the AX device to send log messages by email, use the following commands to specify the email server and the email addresses: smtp {hostname | ipaddr} [port protocol-port] The port option specifies the protocol port to which to send email. The default is 25. logging email-address address [...] To enter more than one address, use a space between each address. 5. To send event messages to an external SNMP server, see “Enabling SNMP” on page 52.

Enabling SNMP AX devices support the following SNMP versions: v1, v2c, v3. SNMP is disabled by default. You can configure the AX 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 AX device by external SNMP managers. Note:

SNMP access to the AX device is read-only. SET operations (write access) are not supported. The AX device supports the following SNMP-related RFCs: • RFC 1157, A Simple Network Management Protocol (SNMP) • RFC 1213, Management Information Base for Network Management of

TCP/IP-based internets: MIB-II The sysService object returns a value that indicates the set of services the AX device offers. For the AX device, the sysService object always returns the following value: 76 This value indicates that the AX device offers the following services: • datalink/subnetwork – 0x2 • internet – 0x4 • end-to-end – 0x8 • applications – 0x40 For information about how the value is calculated, see the RFC. • RFC 1850, OSPF Version 2 Management Information Base

52 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters • draft-ietf-ospf-ospfv3-mib-08, OSPF Version 3 Management Informa-

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

the Internet-standard Network Management Framework • 2790, Host Resources MIB

The following subtrees are supported: • hrSystem: .1.3.6.1.2.1.25.1 • hrStorage: .1.3.6.1.2.1.25.2 • hrDeviceTable: .1.3.6.1.2.1.25.3.2 • hrProcessorTable: .1.3.6.1.2.1.25.3.3 • RFC 3410, Introduction and Applicability Statements for Internet Stan-

dard Management Framework • RFC 3411, An Architecture for Describing Simple Network Manage-

ment Protocol (SNMP) Management Frameworks • RFC 3412, Message Processing and Dispatching for the Simple Net-

work Management Protocol (SNMP) • RFC 3413, Simple Network Management Protocol (SNMP) Applica-

tions • RFC 3414, User-based Security Model (USM) for version 3 of the Sim-

ple Network Management Protocol (SNMPv3) • RFC 3415, View-based Access Control Model (VACM) for the Simple

Network Management Protocol (SNMP) • RFC 3635, Definitions of Managed Objects for the Ethernet-like Inter-

face Types

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

53 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters

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

AX SNMP Traps

Trap Category SNMP System

Trap Link Up Link Down Start Shutdown Restart Control CPU utilization

Description Indicates that an Ethernet interface has come up. Indicates that an Ethernet interface has gone down. Indicates that the AX device has started. Indicates that the AX device has shut down. Indicates that the AX device is going to reboot or reload. Indicates that the control CPU utilization is higher than 90%.*

Data CPU utilization

Indicates that data CPU utilization is higher than 90%.* Indicates that the temperature inside the AX chassis is higher than 68 C.*

High Temperature

Fan Failure Power Supply Failure Primary Hard Disk

Secondary Hard Disk

High Disk Usage High Memory Usage Packet Buffer drop

54 of 486

If you see this trap, check for fan failure traps. Also check the installation location to ensure that the chassis room temperature is not too high (40 C or higher) and that the chassis is receiving adequate air flow. Indicates that a system fan has failed. Contact A10 Networks. Indicates that a power supply has failed. Contact A10 Networks. Indicates that the primary Hard Disk has failed or the RAID system has failed. Contact A10 Networks. In dual-disk models, the primary Hard Disk is the one on the left, as you are facing the front of the AX chassis. Indicates that the secondary Hard Disk has failed or the RAID system has failed. Contact A10 Networks. The secondary Hard Disk is the one on the right, as you are facing the front of the AX chassis. Note: This trap does not apply to the following models: AX 1030, AX 3030, AX 2500, AX 2600, AX 3000, AX 3000-11, AX 3200-12, AX 3400, AX 5100, AX 5200, or AX 5200-11. Indicates that hard disk usage on the AX device is higher than 85%.* Indicates that the memory usage on the AX device is higher than 95%.* Indicates that the AX device is dropping too many packets.*

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters TABLE 3

AX SNMP Traps (Continued)

Trap Category Network

Trap Trunk Ports Threshold

High Availability (HA)

Active Standby Active-Active VRRP

Server Load Balancing (SLB)

Server Up Server Down Service Up Service Down Server Connection Limit Server Connection Resume Service Connection Limit Service Connection Resume Virtual Server Connection Limit Virtual Port Connection Limit Virtual Server Connection-Rate Limit Virtual Port Connection-Rate Limit Virtual Port Up

Virtual Port Down Application Buffer Threshold

Description Indicates that the trunk ports threshold feature has disabled trunk members because the number of up ports in the trunk has fallen below the configured threshold. Indicates that the AX device is going from HA Standby mode to Active mode. Indicates that the AX device is going from HA Active mode to Standby mode. Indicates that an Active-Active HA configuration has been enabled. Indicates that a VRID has changed state between active and standby. Indicates that an SLB server has come up. Indicates that an SLB server has gone down. Indicates that an SLB service has come up. Indicates that an SLB service has gone down. Indicates that an SLB server has reached its configured connection limit. Indicates that an SLB server has reached its configured connection-resume value. Indicates that an SLB service has reached its configured connection limit. Indicates that an SLB service has reached its configured connection-resume value. Indicates that the connection limit configured on a virtual server has been exceeded. Indicates that the connection limit configured on a virtual port has been exceeded. Indicates that the connection rate limit configured on a virtual server has been exceeded. Indicates that the connection rate limit configured on a virtual port has been exceeded. Indicates that an SLB virtual service port has come up. An SLB virtual server’s service port is up when at least one member (real server and real port) in the service group bound to the virtual port is up. Indicates that an SLB virtual service port has gone down. Indicates that the configured SLB application buffer threshold has been exceeded.*

* This threshold is configurable. To use the GUI, navigate to Config > System > Settings > General > Threshold. In the CLI, use the monitor command at the global configuration level.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

55 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters

SNMP Communities and Views You can allow external SNMP managers to access the values of MIB objects from the AX device. To allow remote read-only access to AX 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 AX device when requesting MIB values. Community strings are similar to passwords. You can minimize security risk by applying the same principles to selecting a community name as you would to selecting a password. Use a hard-to-guess string and avoid use of commonly used community names such as “public” or “private”. You also can restrict access to specific Object IDs (OIDs) within the MIB, on an individual community basis. OIDs indicate the position of a set of MIB objects in the global MIB tree. The OID for A10 Networks AX Series objects is 1.3.6.1.4.1.22610. SNMP Views An SNMP view is like a filter that permits or denies access to a specific OID or portions of an OID. You can configure SNMP user groups and individual SNMP users, and allow or disallow them to read specific portions of the AX MIBs using different views. When you configure an SNMP user group or user, you specify the SNMP version. SNMP v1 and v2c do not support authentication or encryption of SNMP packets. SNMPv3 does. You can enable authentication, encryption, or both, on an individual SNMP user-group basis when you configure the groups. You can specify the authentication method and the password for individual SNMP users when you configure the users.

SNMP Configuration Steps To configure SNMP: 1. Optionally, configure location and contact information. 2. Optionally, configure external SNMP trap receivers. 3. Optionally, configure one or more read-only communities. 4. Optionally, configure views, groups, and users.

56 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters 5. Enable the SNMP agent and SNMP traps. 6. Save the configuration changes. You are not required to perform these configuration tasks in precisely this order. The workflow in the GUI is slightly different from the workflow shown here. Note:

By default, the AX device can reach remote logging and trap servers only if they are reachable through the AX device’s data ports, not the management port. To enable the AX device to reach remote logging and trap servers through the management port, see “Specifying the Source Interface for Management Traffic” on page 437.

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.

USING THE GUI

1. Select Config > 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 AX device’s location. c. In the System Contact field, enter the name or email address of the AX 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 AX device. d. In the Object Identifier field, enter the OID at which SNMP management applications can reach the AX device. e. Click Add. f. Repeat step b through step e for each combination of community string, management host, and OID.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

57 of 486

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters 4. In the Trap section, specify external trap receivers: a. Click Trap. b. In the Community field, enter the name of the community sending the traps. c. In the IP Address (host) field, enter the IP address or fully-qualified hostname of the SNMP trap receiver. d. If the trap receiver does not use the standard protocol port to listen for traps, change the port number in the Port field. e. Select SNMP the version from the Version drop-down list: • V1 • V2c f. Click Add to add the receiver. g. Repeat step b through step f for each trap receiver. 5. In the Trap List section, enable traps: a. Click Trap List. b. To enable all traps, select All Traps. Otherwise, select the individual traps you want to enable. 6. Click OK. 7. To save the configuration changes, click the Save button. Note:

When there are unsaved configuration changes on the AX 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]

58 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Basic System Parameters 3. To configure one or more read-only communities, use the following command: snmp-server community read ro-community-string [oid oid-value] [remote {hostname | ipaddr mask-length | ipv6-addr/prefix-length}] 4. To configure views, groups, and users, use the following commands: snmp-server view view-name oid [oid-mask] {included | excluded} snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} read view-name snmp-server user username group groupname {v1 | v2 | v3 [auth {md5 | sha} password [encrypted]]} 5. To enable the SNMP agent and SNMP traps, use the following 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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

59 of 486

AX Series - System Configuration and Administration Guide Configuration Examples

Configuration Examples The following examples show how to configure the system settings described in this chapter.

GUI EXAMPLE The following examples show the GUI screens used for configuration of the basic system settings described in this chapter. Note:

The GUI does not support configuration of SNMPv3 settings. FIGURE 5

60 of 486

Config > Network > DNS > DNS

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration Examples FIGURE 6

Config > System > Time

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

61 of 486

AX Series - System Configuration and Administration Guide Configuration Examples FIGURE 7

62 of 486

Config > System > Settings > Log

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration Examples FIGURE 8

Config > System > SNMP

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

63 of 486

AX Series - System Configuration and Administration Guide Configuration Examples

64 of 486

FIGURE 9

Config > System > SNMP > Trap List

FIGURE 10

Save Button

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration Examples

CLI EXAMPLE The following commands log onto the CLI, access the global configuration level, and set the hostname and configure the other DNS settings: login as: admin Welcome to AX Using keyboard-interactive authentication. Password:******** Last login: Tue Jan 13 19:51:56 2009 from 192.168.1.144 [type ? for help] AX>enable Password:******** AX#config AX(config)#hostname AX-SLB2 AX-SLB2(config)#ip dns suffix ourcorp AX-SLB2(config)#ip dns primary 10.10.20.25 AX-SLB2(config)#ip dns secondary 192.168.1.25

The following examples set the login banner to “welcome to login mode” and set the EXEC banner to “welcome to exec mode”: AX-SLB2(config)#banner login “welcome to login mode” AX-SLB2(config)#banner exec “welcome to exec mode”

The following commands set the timezone and NTP parameters: AX-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

... AX-SLB2(config)#clock timezone America/Los_Angeles

AX-SLB2(config)#ntp server 10.1.4.20 AX-SLB2(config)#ntp server enable The following commands configure the AX device to send system log messages to an external syslog server and to email Emergency messages to the system admins. In this example, the message levels sent to the external server are left at the default, Error (3) and above. By default, the same mesPerformance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

65 of 486

AX Series - System Configuration and Administration Guide Replacing the Web Certificate sage levels are sent to the management terminal in CLI sessions. The message level emailed to admins is set to Emergency (0) messages only. AX-SLB2(config)#logging host 192.168.10.10

AX-SLB2(config)#smtp ourmailsrvr AX-SLB2(config)#logging email-address [email protected] [email protected] AX-SLB2(config)#logging email 0 The following commands enable SNMP and all traps, configure the AX device to send traps to an external trap receiver, and configure a community string for use by external SNMP managers to read MIB data from the AX device. AX-SLB2(config)#snmp-server location ourcorp-HQ AX-SLB2(config)#snmp-server contact Me_admin1 AX-SLB2(config)#snmp-server enable trap AX-SLB2(config)#snmp-server community read ourcorpsnmp AX-SLB2(config)#snmp-server host 192.168.10.11 ourcorpsnmp

The following command saves the configuration changes to the startup-config. This is the file from which the AX device loads the configuration following a reboot. AX-SLB2(config)#write memory

Replacing the Web Certificate You can replace the web certificate shipped with the AX device. Replacing the certificate with a CA-signed certificate prevents the certificate warning from being displayed by your browser when you log onto the GUI.

USING THE GUI 1. Select Config > 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.

66 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Replacing the Web Certificate 4. Click Open. The path and filename appear in the Source field. Go to step 10. 5. To use the management interface as the source interface for the connection to the remote device, select Use Management Port. Otherwise, the AX device will attempt to reach the remote server through a data interface. 6. Select the file transfer protocol: FTP, TFTP, RCP, or SCP. 7. In the Host field, enter the directory path and filename. 8. 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. 9. In the User and Password fields, enter the username and password required for access to the remote server. 10. Click OK.

USING THE CLI The current release does not support this option using the CLI.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

67 of 486

AX Series - System Configuration and Administration Guide Emailing Log Messages

Emailing Log Messages You can configure the AX device to email log messages, using email log filters. By default, emailing of log messages is disabled. Log email filters consist of the following parameters: • Filter ID – Filter number, 1-8. • Conditions – One or more of the following: • Severity – Severity levels of messages to send in email. If you do

not specify a message level, messages of any severity level match the filter and can be emailed. • Software Module – Software modules for which to email messages. Messages are emailed only if they come from one of the specified software modules. If you do not specify a software module, 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 supported. Only messages that meet the criteria of the regular expression can be emailed. The regular expression can be a simple text string or a more complex expression using standard regular expression logic. If you do not specify a regular expression, messages with any text match the filter and can be emailed. The operators (AND, OR, NOT) specify how the conditions should be compared. (See ““Boolean Operators” on page 68”.) • 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

68 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Emailing Log Messages (For more information about Reverse Polish Notation, see the following link: http://en.wikipedia.org/wiki/Reverse_Polish_notation.)

USING THE GUI 1. Select Config > System > Settings. 2. On the menu bar, select Log. 3. In the Logging Email Filter section, click Add. A configuration page for the filter appears. 4. In the ID field, enter the filter ID, 1-8. 5. 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. 6. Construct the rest of the filter by selecting the conditions. Note:

The conditions must be selected in the order described here. Otherwise, the filter will be invalid. If you accidentally configure an invalid filter, you can click Clear to remove the filter conditions and start again. a. Select the message severity level from the Level drop-down list, and click Add. To add more severity levels, repeat this step for each severity level. b. Optionally, select a software module from the Module drop-down list, and click Add. To add more modules, repeat this step for each module. c. Optionally, enter a regular expression in the Pattern field to specify message text to match on, and click Add. d. Select the operator from the Operator drop-down list, and click Add. 7. Click OK. The new filter appears in the Logging Email Filter section on the Log page. 8. 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. 9. Optionally, to change the number of minutes the AX 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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

69 of 486

AX Series - System Configuration and Administration Guide Emailing Log Messages the maximum number of messages allowed. You can specify 10-1440 minutes. The default is 10. 10. When finished configuring log settings, click OK.

70 of 486

FIGURE 11 section)

Config > System > Settings > Log - Add (Logging Email Filter

FIGURE 12

Config > System > Settings > Log (Logging Email Filter added)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Emailing Log 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 operators [trigger]

filter

filter-num

conditions

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. 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

71 of 486

AX Series - System Configuration and Administration Guide Emailing Log Messages 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 AX 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. AX(config)#logging email buffer number 32 time 30

The following command resets the buffer settings to their default values. AX(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. AX(config)#logging email filter 1 level information pattern "abc" and

The following command reconfigures the filter to immediately email matching messages. AX(config)#logging email filter 1 level information pattern "abc" and trigger

72 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Network Setup This chapter describes how to add the AX device to your network.

Overview AX Series devices can be inserted into your network with minimal or no changes to your existing network. You can insert the AX device into your network as a Layer 2 switch (transparent mode) or a Layer 3 router (route mode). In either deployment mode, the AX device has a dedicated Ethernet management interface, separate from the Ethernet data interfaces. You can assign an IPv4 address and an IPv6 address to the management interface. This chapter provides the following configuration examples: • “Management Interface Configuration” on page 77 • “Transparent Mode Deployment” on page 80 • “Route Mode Deployment” on page 82

Trunk Support The AX 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. You can configure the following types of trunks: • Static trunks – You can configure up to 8 static trunks. Each trunk can

contain 2-8 Ethernet data ports. • Dynamic trunks – You can enable Link Aggregation Control Protocol

(LACP) on Ethernet data interfaces, to make those interfaces candidate members of dynamically configured trunks. Although this chapter does not show trunking examples, the following chapter does: “Link Trunking” on page 87

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

73 of 486

AX Series - System Configuration and Administration Guide Overview

Virtual LAN Support A VLAN is a Layer 2 broadcast domain. MAC-layer broadcast traffic can be flooded within the VLAN but does not cross to other VLANs. For traffic to go from one VLAN to another, it must be routed. You can segment the AX 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 AX Ethernet data ports are untagged members of VLAN 1. Note:

A port actually can be an untagged member of a single VLAN, and also a tagged member of one or more other VLANs. For example, to add a port to a new VLAN, it is not required either to remove the port from VLAN 1, or to change its status in VLAN 1 from untagged to tagged. Default VLAN (VLAN 1) By default, all the AX device’s Ethernet data ports are members of a single virtual LAN (VLAN), VLAN 1. On a new or unconfigured AX 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 AX 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:

74 of 486

Configuring an IP interface on an individual Ethernet interface indicates you are deploying in route mode (also called “gateway mode”). If you deploy in transparent mode instead, in which the AX device has a single IP address for all data interfaces, Layer 2 forwarding is left enabled by default on VLAN 1.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview Virtual Ethernet Interfaces On AX devices deployed in route mode (Layer 3 mode), you can configure IP interfaces on VLANs. To configure an IP interface on a VLAN, add a Virtual Ethernet (VE) interface to the VLAN, then assign the IP interface to the VE. Each VLAN can have one VE. The VE ID must be the same as the VLAN ID. For example, VLAN 2 can have VE 2, VLAN 3 can have VE 3, and so on. Maximum Number of Supported Virtual Ethernet Interfaces • For all FPGA models: 128 VEs on a single port* • For non-FPGA models: 128 VEs on a single port • For private partitions enabled for Layer 2/3 virtualization (both FPGA

and non-FPGA models): 32 VEs on a single port

IP Subnet Support The AX 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 AX 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 AX device deployed in route mode (Layer 3) can have separate IP addresses on each data interface. No two interfaces can have IP addresses that are in the same subnet. This applies to the management interface and all data interfaces.

*.

An exception is model AX 5200, which supports 384.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

75 of 486

AX Series - System Configuration and Administration Guide Overview

Routing Support The AX device supports the following dynamic routing protocols: • Open Shortest Path First (OSPF) version 2 for IPv4 and OSPFv3 for

IPv6 • Intermediate System to Intermediate System (IS-IS) for IPv4 and IPv6 • Border Gateway Protocol version 4 with multiprotocol extensions

(BGP4+), for IPv6 and IPv4 For OSPF information, see the following: • “Open Shortest Path First (OSPF)” on page 105 • AX Series CLI Reference

For IS-IS and BGP information, see the AX Series CLI Reference.

Gateway Health Monitoring You can configure the AX device to monitor the health (Layer 3 reachability) of its nexthop gateways. Gateway health monitoring provides more efficient routing by sending traffic only to available gateways. For more information, see “Gateway Health Monitoring” on page 101.

Layer 2/3 Virtualization Layer 2/3 virtualization ia a feature that enables you to partition the AX device into multiple virtual devices, each with its own completely separate Layer 2/3 networking resources. Layer 2/3 virtualization is an optional part of Role-Based Administration (RBA). RBA allows the AX device to be partitioned into multiple virtual devices, each with their own administrators. From a partition administrator’s point of view, they have management control of a complete, antonymous device, separate from the other virtual devices (partitions). For more information, see “Role-Based Administration with Layer 2/3 Virtualization” on page 155.

76 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Management Interface Configuration

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

Management Interface Configuration 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 13 shows an example of the management interface on an AX Series device. FIGURE 13

Note:

AX Deployment Example – Management Interface

By default, the AX device attempts to use a route from the main route table for management connections originated on the AX device. You can enable the AX device to use the management route table to initiate management connections instead. (For information, see “Specifying the Source Interface for Management Traffic” on page 437.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

77 of 486

AX Series - System Configuration and Administration Guide Management Interface Configuration

Configuration Example This section shows the GUI screens and CLI commands needed to configure the management interface as shown in Figure 13.

USING THE GUI 1. Log into the GUI. Note:

Unless you have already configured an IP interface, navigate to the default IP address: http://172.31.31.31. 2. Select Config > Network > Interface > Management. (See Figure 14.) Figure 14 shows the GUI screen used to configure the management IP addresses shown in Figure 13. 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 14

78 of 486

Config > Network > Interface > Management

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Management Interface Configuration

USING THE CLI The following commands access the global configuration level of the CLI: login as: admin Welcome to AX Using keyboard-interactive authentication. Password:*** [type ? for help] AX>enable Password:(just press Enter on a new system) AX# AX#config AX(config)#

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

The following commands configure IPv4 access on the management interface: AX(config)#interface management AX(config-if:mgmt)#ip address 192.168.2.228 /24 AX(config-if:mgmt)#ip default-gateway 192.168.2.1

The following commands verify the configuration: AX(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, 0 input errors, 0 runts

0 CRC

Received 66 multicasts,

Received 662 unicasts

0 frame

0 giants

924 packets output 3549 bytes Transmitted 157 broadcasts 0 output errors

7 multicasts

770 unicasts

0 collisions

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

79 of 486

AX Series - System Configuration and Administration Guide Transparent Mode Deployment

Transparent Mode Deployment Figure 15 shows an example of an AX Series device deployed in transparent mode. FIGURE 15

Note:

AX Deployment Example – Transparent Mode

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 AX device as shown in Figure 15.

USING THE GUI 1. Select Config > Network > Interface > Transparent. (See Figure 16.) 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 17.) 5. Select the checkbox next to each Ethernet data interface to enable. 6. Click Enable.

80 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Transparent Mode Deployment FIGURE 16

Config > Network > Interface > Transparent

FIGURE 17

Config > Network > Interface > LAN

USING THE CLI The following commands configure the global IP address and default gateway: AX(config)#ip address 10.10.10.2 /24 AX(config)#ip default-gateway 10.10.10.1

The following commands enable the Ethernet interfaces used in the example: AX(config)#interface ethernet 1 AX(config-if:ethernet1)#enable AX(config-if:ethernet1)#interface ethernet 2

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

81 of 486

AX Series - System Configuration and Administration Guide Route Mode Deployment AX(config-if:ethernet2)#enable AX(config-if:ethernet2)#interface ethernet 3 AX(config-if:ethernet3)#enable AX(config-if:ethernet3)#exit

Route Mode Deployment Figure 18 shows an example of an AX device deployed in route mode. Note:

Route mode is also called “gateway” mode. FIGURE 18

AX Deployment Example – Route Mode

In this example, the AX device has separate IP interfaces in different subnets on each of the interfaces connected to the network. The AX device can be configured with static IP routes and can be enabled to run OSPF and IS-IS. In this example, a static route is configured to use as the default route through 10.10.10.1. Although this example shows single physical links, you could use trunks as physical links. You also could use multiple VLANs. In this case, the IP addresses would be configured on Virtual Ethernet (VE) interfaces, one per VLAN, instead of being configured on individual Ethernet ports. Since the AX device is a router in this deployment, downstream devices can use the AX 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 AX devices in a High Availability (HA) configuration is used, the downstream devices would use a floating IP address shared by the two

82 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Route Mode Deployment AX devices as their default gateway. (For more on HA, see “High Availability” on page 215.)

Configuration Example This section shows the GUI screens and CLI commands needed to implement the configuration shown in Figure 18.

USING THE GUI 1. Select Config > Network > Interface > LAN. 2. Click on the interface name (for example, “e1”). The configuration page for the port appears. (See Figure 19.) 3. To assign an IPv4 address, click “IPv4” to display the configuration fields for that section, and enter the address information. 4. To assign an IPv6 address, click “IPv6” to display the configuration fields for that section, and enter the address information. 5. Click OK. Configuring the Default Route 1. Select Config > Network > Route > IPv4 Static (or IPv6 Static) > 2. Enter the route information. (For an IPv4 example, see Figure 20.) 3. Click OK.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

83 of 486

.

AX Series - System Configuration and Administration Guide Route Mode Deployment

84 of 486

FIGURE 19 selected

Config > Network > Interface > LAN - Ethernet data port 1

FIGURE 20

Config > Network > Route > IPv4 Static

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Route Mode Deployment

USING THE CLI The following commands enable the Ethernet interfaces used in the example and configure IP addresses on them: AX(config)#interface ethernet 1 AX(config-if:ethernet1)#enable AX(config-if:ethernet1)#ip address 10.10.10.2 /24 AX(config-if:ethernet1)#interface ethernet 2 AX(config-if:ethernet2)#enable AX(config-if:ethernet2)#ip address 192.168.3.100 /24 AX(config-if:ethernet2)#interface ethernet 3 AX(config-if:ethernet3)#enable AX(config-if:ethernet3)#ip address 192.168.1.111 /24 AX(config-if:ethernet3)#exit AX(config-if:ethernet3)#interface ethernet 4 AX(config-if:ethernet4)#enable AX(config-if:ethernet4)#ip address 192.168.2.100 /24 AX(config-if:ethernet4)#exit

The following command configures the default route through 10.10.10.1: AX(config)#ip route 0.0.0.0 /0 10.10.10.1

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

85 of 486

AX Series - System Configuration and Administration Guide Route Mode Deployment

86 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Link Trunking This chapter describes how to configure trunk links on the AX device.

Overview The AX 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 provided 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 8 static trunks. Each trunk can

contain 2-8 Ethernet data ports. • Dynamic trunks – You can enable Link Aggregation Control Protocol

(LACP) on Ethernet data interfaces, to make those interfaces candidate members of dynamically configured trunks. 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 8 static trunks. Each trunk can contain 2-8 Ethernet data ports. To configure a static trunk: 1. Add the trunk and configure trunk parameters: • Port membership. You can add 2-8 Ethernet data ports to the trunk. • Optionally, configure port-threshold parameters. The port threshold

specifies the minimum number of member ports in the trunk that must be up, for the trunk itself to remain up.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

87 of 486

AX Series - System Configuration and Administration Guide Static Trunk Configuration 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. • IPv4 and IPv6 parameters – You can assign one or more IPv4 and

IPv6 addresses, and configure other IP-related parameters such as IP helper or IPv6 neighbor discovery. • Dynamic routing – You can configure interface-level OSPF and

IS-IS parameters. • Access list (ACL) – You can filter incoming traffic based on source

and destination IPv4 or IPv6 address and protocol port, as well as additional parameters such as ICMP type and code or VLAN ID. • ICMP rate limiting – You can enable protection against denial-of-

service (DoS) attacks such as Smurf attacks, which consist of floods of spoofed broadcast ping messages. • Layer 3 forwarding – Layer 3 forwarding is enabled by default. You

can disable it. If you want to allow Layer 3 forwarding except between VLANs, a separate option allows you to disable Layer 3 forwarding between VLANs.

Trunk Parameters and Trunk Interface Parameters You can configure trunk-related parameters at the following configuration levels: • Trunk • Interface

At the trunk configuration level, you can enable or disable the trunk, add or remove trunk members, and set port-threshold parameters. Using the 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 interfacerelated 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.

88 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Static Trunk Configuration

Configuring Trunk Parameters To configure trunk parameters, use the following commands. [no] trunk [DeviceID-]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 DeviceID is applicable only if you are using the AX Series Virtual Chassis System (aVCS) to manage multiple AX devices as a single virtual chassis.

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 AX automatically disables the trunk’s member ports. The ports are disabled in the running-config. The AX device also generates a log message and an SNMP trap, if these services are enabled. Note:

After the feature has disabled the members of the trunk group, the ports are not automatically re-enabled. The ports must be re-enabled manually after the issue that caused the ports to go down has been resolved. In some situations, a timer is used to delay the ports-threshold action. The configured port threshold is not enforced until the timer expires. The portsthreshold 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: Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

89 of 486

AX Series - System Configuration and Administration Guide Static Trunk Configuration [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 AX automatically disables the trunk’s member ports. The ports are disabled in the running-config. The AX 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 exceeded. You can set the ports-threshold timer to 1-300 seconds. The default is 10 seconds.

Configuring Interface-level Parameters on a Trunk To configure interface-level parameters for the trunk, use the following command to access the interface configuration level for the trunk: interface trunk [DeviceID-]num Enter this command at the global configuration level of the CLI. This command changes the CLI to the interface configuration level for the specified trunk, where the following commands are available: [no] name string [no] ip options [no] ipv6 options [no] ospf options [no] isis options [no] access-list acl-num in [no] icmp-rate-limit options disable enable [no] l3-vlan-fwd-disable Note:

90 of 486

The disable and enable commands at the interface configuration level for the trunk control Layer 3 forwarding on the trunk but do not completely disable the trunk. To control all forwarding on the trunk, use the disable or enable command at the trunk configuration level instead.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration For more information about these commands, see the “Config Commands: Interface” chapter of the AX Series CLI Reference.

Static Trunk Configuration Example The following commands configure trunk 7 with ports 5-8, and verify the configuration: AX(config)#trunk 7 AX(config-trunk:7)#ethernet 5 to 8 AX(config-trunk:7)#show trunk Trunk ID

: 7

Trunk Status

: Up

Member Count: 4

Members

: 5

Cfg Status

: Enb Enb Enb Enb

Oper Status

: Up

Ports-Threshold

: None

Working Lead

: 5

6 Up

7 Up

8 Up

AX(config-trunk:7)#exit

The following commands access the interface configuration level for the trunk and assign an IPv6 address to the trunk interface: AX(config)#interface trunk 7 AX(config-if:trunk7)#ipv6 address 2001:db8::7/32

Dynamic Trunk Configuration Link Aggregation Control Protocol (LACP) dynamically creates trunk links. The AX implementation of LACP is based on the 802.3ad IEEE specification. You can configure a maximum of 16 LACP trunks on an AX device. An interface can belong to a single LACP trunk. Limitations in This Release In the current release, an IP address can not be configured directly on an LACP trunk because there is no trunk interface. However, you can associate an IP address with an LACP trunk by placing the trunk in a VLAN and assigning an IP address to the VLAN’s Virtual Ethernet (VE) interface. You then can configure routing protocols on the VE interface. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

91 of 486

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration

LACP Parameters The following LACP parameters are configurable. System-wide LACP Parameter • LACP system priority – Specifies the LACP priority of the AX device.

In cases where LACP settings on the local device (the AX 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 AX automatically disables the trunk’s member ports. The ports are disabled in the running-config. You can specify 2-8. By default, no port threshold is set. A trunk remains up if even 1 of its ports is up. • Ports threshold timer – Number of seconds to wait after a port goes

down before marking the trunk down, if the configured threshold is exceeded. 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 10000-65535. • LACP port priority – Priority of the interface for selection as an active

member of a link. If the LACP trunk has more candidate members than are allowed by the device at the other end of the link, LACP selects the

92 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration 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. • 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 is disabled by default on AX LACP trunk links. You can enable UDLD on individual LACP trunk interfaces. (For more information, see “UDLD” on page 93.)

UDLD When UDLD is enabled, the AX Series UDLD uses LACP protocol packets as heartbeat messages. If an LACP link on the AX device does not receive an LACP protocol packet within a specified timeout, LACP blocks traffic on the port. This corrects the problem by forcing the devices connected by the non-operational link to use other, fully operational links. A link that is blocked by LACP can still receive LACP protocol packets but blocks all other traffic. UDLD is disabled by default on AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

93 of 486

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration 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 To configure 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 global configuration level of the CLI: [no] ports-threshold num [do-manual-recovery] You can specify 2-8 ports. The do-manual-recovery option disables automatic recovery of the trunk when the required number of ports come back up. If you use this option, the trunk remains disabled until you re-enable it. b. Specify how many seconds to wait after a port goes down before marking the trunk down, if the configured threshold is exceeded. [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. 3. For each interface: a. Change the CLI to the configuration level for the interface. b. 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. c. (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.

94 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration d. (Optional) Specify the aging timeout for LACP data units from the other end of the LACP link, using the following command: [no] lacp timeout {short | long} You can specify short (3 seconds) or long (90 seconds). The default is long. e. (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.

Displaying LACP Information To display LACP information, use the following commands: show lacp sys-id This command displays the AX device’s LACP system ID. The LACP system ID consists of the LACP system priority and the system MAC address. On AX devices, the system MAC address is the lowest numbered MAC address on the device. show lacp counter [lacp-trunk-id] This command displays statistics. show lacp trunk [ admin-key-list-details | detail | port {ethernet portnum | loopback num | management | trunk lacp-trunk-id | udld num | ve ve-num} | summary | lacp-trunk-id ] This command shows configuration and status information for LACP.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

95 of 486

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration

Clearing LACP Statistics To clear LACP statistics counters, use the following command at the Privileged EXEC level of the CLI: clear lacp counters [lacp-trunk-id]

Configuration Example This example enables LACP on physical Ethernet data ports 1-3 and 6. The following commands configure LACP parameters on the ports: AX-1(config)#interface ethernet 1 AX-1(config-if:ethernet1)#lacp trunk 5 admin-key 10001 mode active AX-1(config-if:ethernet1)#lacp timeout long AX-1(config-if:ethernet1)#interface ethernet 2 AX-1(config-if:ethernet2)#lacp trunk 5 admin-key 10001 mode active AX-1(config-if:ethernet2)#lacp timeout long AX-1(config-if:ethernet2)#interface ethernet 3 AX-1(config-if:ethernet3)#lacp trunk 10 mode active AX-1(config-if:ethernet3)#lacp timeout short AX-1(config-if:ethernet3)#interface ethernet 4 AX-1(config-if:ethernet4)#lacp timeout long AX-1(config-if:ethernet4)#interface ethernet 6 AX-1(config-if:ethernet6)#lacp trunk 10 mode active AX-1(config-if:ethernet6)#lacp timeout short AX-1(config-if:ethernet6)#end

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

96 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration The following command shows LACP statistics: AX-1#show lacp counters Traffic statistics Port

LACPDUs Sent

Marker

Recv

Sent

Pckt err Recv

Sent

Recv

Aggregator po5 1000000 ethernet 1

81

81

0

0

0

0

ethernet 2

81

81

0

0

0

0

0

0

0

0

Aggregator po10 1000001 ethernet 6

233767

233765

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: AX-1#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 additional parameter: 0 ref count: 451 % Admin Key: 3 bandwidth: 1 mtu: 16436 duplex mode: 0 hardware type: 1 type: 0 additional parameter: 0 ref count: 14

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

97 of 486

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration % Admin Key: 4 bandwidth: 1 mtu: 1500 duplex mode: 0 hardware type: 2 type: 0 additional parameter: 0 ref count: 6

The following command shows summary trunk information: AX-1#show lacp trunk summary Aggregator po5 1000000 Admin Key: 0005 - Oper Key 0005 Link: ethernet 1 (3) sync: 1 Link: ethernet 2 (4) sync: 1 Aggregator po10 1000001 Admin Key: 0010 - Oper Key 0010 Link: ethernet 6 (8) sync: 1

The following command shows information for trunk 5: AX-1#show lacp trunk 5 Aggregator po5 1000000 Admin Key: 0005 - Oper Key 0005 Partner LAG: 0x0064,001f-a0-01-dc-60 Partner Oper Key 0005 Link: ethernet 1 (3) sync: 1 Link: ethernet 2 (4) sync: 1

The following command shows detailed information for all LACP trunks: AX-1#show lacp trunk detail Aggregator po5 1000000 Mac address: 00:1f:a0:02:1e:48 Admin Key: 0005 - Oper Key 0005 Receive link count: 1 - Transmit link count: 0 Individual: 0 - Ready: 1 Partner LAG- 0x0064,00-1f-a0-01-dc-60 Link: ethernet 1 (3) sync: 1 Link: ethernet 2 (4) sync: 1 Aggregator po10 1000001 Mac address: 00:1f:a0:02:1e:4d Admin Key: 0010 - Oper Key 0010 Receive link count: 1 - Transmit link count: 0 Individual: 0 - Ready: 1

98 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration Partner LAG- 0x8000,00-1f-a0-10-19-66 Link: ethernet 6 (8) sync: 1

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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

99 of 486

AX Series - System Configuration and Administration Guide Dynamic Trunk Configuration

100 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Gateway Health Monitoring This chapter describes gateway health monitoring and how to configure it. For information about health monitoring of servers in Server Load Balancing (SLB) configurations, see the “Health Monitoring” chapter in the AX Series Application Delivery and Server Load Balancing Guide. Notes • Gateway health monitoring is useful in cases where there is more than

one route to a destination. In this case, the AX device can discard the routes that use unresponsive gateways. If there is only one gateway, this feature is not useful. • Gateway health monitoring and SLB server health monitoring are inde-

pendent features. If a gateway fails its health check, a server reached through the gateway is not immediately marked down. The status of the server still depends on the result of the SLB server health check. • If you plan to use gateway health as a failover trigger for High Avail-

ability (HA), a different configuration option is required. See “Gatewaybased Failover” on page 231 (for the older implementation of HA) or “Dynamic Priority Reduction” on page 195 (for VRRP-A).

Overview Gateway health monitoring uses ARP to test the availability of nexthop gateways. When the AX device needs to send a packet through a gateway, the AX device begins sending ARP requests to the gateway. • If the gateway replies to any ARP request within a configurable timeout,

the AX device forwards the packet to the gateway. • The ARP requests are sent at a configurable interval. The AX 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 AX device selects another gateway and begins the health monitoring process again.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

101 of 486

AX Series - System Configuration and Administration Guide Overview The following parameters are used for gateway health monitoring: • Interval – The interval specifies the amount of time between health

check attempts (ARP requests), and can be 1-180 seconds. The default is 5 seconds. • Retries – The retries specifies the number of seconds the AX 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 AX device waits for a

reply to any of the ARP requests, and can be 1-60 seconds. The default is 15 seconds. Using the default gateway health monitoring settings, a gateway must respond to a gateway health check within 15 seconds. Figure 21 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 21

102 of 486

Gateway Health Check Using Default Settings – Timeout

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration Figure 22 shows an example in which a gateway responds before the timeout. FIGURE 22 Responds

Gateway Health Check Using Default Settings – Gateway

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

USING THE GUI The current release does not support configuration of this feature using the GUI.

USING THE CLI To enable gateway health monitoring, use the following command at the global configuration level of the CLI: slb gateway-health-check [interval seconds [timeout seconds]] The interval and timeout options are described above. To display gateway health monitoring statistics, use the following command: Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

103 of 486

AX Series - System Configuration and Administration Guide Configuration show health gateway CLI Example The following command enables gateway health monitoring with the default settings: AX(config)#slb gateway-health-check

The following command displays gateway health monitoring statistics: AX(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

104 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Support for Multiple OSPFv2 and OSPFv3 Processes

Open Shortest Path First (OSPF) The AX device supports the following OSPF versions: • OSPFv2 for IPv4 • OSPFv3 for IPv6

This chapter provides configuration examples. For detailed CLI syntax information, see the AX Series CLI Reference.

Support for Multiple OSPFv2 and OSPFv3 Processes The AX device supports up to 65535 OSPFv2 processes on a single AX device. Only a single OSPFv2 process can run on a given interface. Each IPv6 link can run up to 65535 OSPFv3 processes, on the same link. Each OSPF process is completely independent of the other OSPF processes on the device. They do not share any information directly. However, you can configure redistribution of routes between them.

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

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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

105 of 486

AX Series - System Configuration and Administration Guide OSPF Configuration Example

OSPF Configuration Example The configuration excerpts in this example configure OSPFv2 and OSPFv3 on an AX 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. interface ethernet 1 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 ! interface ethernet 2 ip address 3.3.3.1 255.255.255.0 ipv6 address 5f00:1:2:20::1/64 ip ospf cost 25 ipv6 router ospf area 0 tag 1

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 !

106 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide OSPF Configuration Example 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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

107 of 486

AX Series - System Configuration and Administration Guide OSPF Configuration Example

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 AX Series CLI Reference. 1. 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: router log syslog To enable output to a local file, use the following command at the global configuration level of the CLI:

108 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide OSPF Configuration Example [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. 2. Set severity level and facility: The default severity level for router logging is 7 (debugging). The default facility is local0. To change set the severity level for messages output to the terminal, use the following command at the global configuration level of the CLI: logging monitor severity-level The severity-level can be one of the following: • 0 or emergency • 1 or alert • 2 or critical • 3 or error • 4 or warning • 5 or notification • 6 or information • 7 or debugging

To change the severity level for messages output to the local logging buffer, use the following command at the global configuration level of the CLI: logging buffered severity-level To change the severity level for messages output to external log servers, use the following command at the global configuration level of the CLI: logging syslog severity-level

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

109 of 486

AX Series - System Configuration and Administration Guide OSPF Configuration Example 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

3. Enable debug options to generate output: To enable debugging for OSPF, use the following commands at the global configuration level or Privileged EXEC level of the CLI: debug a10 [ipv6] ospf debug [ipv6] ospf type The ipv6 option enables debugging for OSPFv3. Without the ipv6 option, debugging is enabled for OSPFv2. The type specifies the types of OSPF information to log, and can be one or more of the following: • all – Enables debugging for all information types listed below. • events – Enables debugging for OSPF events. • ifsm – Enables debugging for the OSPF Interface State Machine

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

(NFSM).

110 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide OSPF Configuration Example • 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. CLI Example The following commands configure OSPFv2 logging to a local file. AX(config)#router log file name ospf-log AX(config)#router log file per-protocol AX(config)#router log file size 100 AX(config)#debug a10 ospf all AX(config)#debug ospf packet

These commands create a router log file named “ospf-log”. The per-protocol option will log messages for each routing protocol separately. The log file will hold a maximum 100 MB of data, after which the messages will be saved in a backup and the log file will be cleared. The following command displays the contents of the local router log file: AX(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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

111 of 486

AX Series - System Configuration and Administration Guide OSPF Configuration Example 2010/04/21 09:57:20 OSPF:

Auth Data Len 16

2010/04/21 09:57:20 OSPF:

Sequence number 1271830931

2010/04/21 09:57:20 OSPF: Hello 2010/04/21 09:57:20 OSPF:

NetworkMask 255.255.255.0

2010/04/21 09:57:20 OSPF:

HelloInterval 10

2010/04/21 09:57:20 OSPF:

Options 0x2 (-|-|-|-|-|-|E|-)

2010/04/21 09:57:20 OSPF:

RtrPriority 1

2010/04/21 09:57:20 OSPF:

RtrDeadInterval 40

2010/04/21 09:57:20 OSPF:

DRouter 1.1.1.200

2010/04/21 09:57:20 OSPF:

BDRouter 1.1.1.2

2010/04/21 09:57:20 OSPF:

# Neighbors 1

2010/04/21 09:57:20 OSPF:

Neighbor 31.31.31.31

2010/04/21 09:57:20 OSPF: ----------------------------------------------------2010/04/21 09:57:21 OSPF: IFSM[ethernet 2:3.3.3.1]: Hello timer expire 2010/04/21 09:57:21 OSPF: SEND[Hello]: To 224.0.0.5 via ethernet 2:3.3.3.1, length 48 2010/04/21 09:57:21 OSPF: ----------------------------------------------------2010/04/21 09:57:21 OSPF: Header 2010/04/21 09:57:21 OSPF:

Version 2

2010/04/21 09:57:21 OSPF:

Type 1 (Hello)

2010/04/21 09:57:21 OSPF:

Packet Len 48

2010/04/21 09:57:21 OSPF:

Router ID 2.2.2.2

2010/04/21 09:57:21 OSPF:

Area ID 0.0.0.0

2010/04/21 09:57:21 OSPF:

Checksum 0x49eb

2010/04/21 09:57:21 OSPF:

Instance ID 0

2010/04/21 09:57:21 OSPF:

AuType 0

2010/04/21 09:57:21 OSPF: Hello 2010/04/21 09:57:21 OSPF:

NetworkMask 255.255.255.0

2010/04/21 09:57:21 OSPF:

HelloInterval 10

2010/04/21 09:57:21 OSPF:

Options 0x2 (-|-|-|-|-|-|E|-)

2010/04/21 09:57:21 OSPF:

RtrPriority 1

2010/04/21 09:57:21 OSPF:

RtrDeadInterval 40

2010/04/21 09:57:21 OSPF:

DRouter 3.3.3.2

2010/04/21 09:57:21 OSPF:

BDRouter 3.3.3.1

2010/04/21 09:57:21 OSPF:

# Neighbors 1

2010/04/21 09:57:21 OSPF:

Neighbor 81.81.81.81

...

112 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

DHCP Relay This chapter describes Dynamic Host Configuration Protocol (DHCP) relay support and how to configure it.

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 configure the AX 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 AX device as a DHCP relay, configure the DHCP server IP address as a helper address on the AX IP interface connected to DHCP clients. The AX device intercepts broadcast DHCP packets sent by clients on the interface configured with the helper address. The AX device then places the receiving interface’s IP address (not the helper address) in the relay gateway address field, and forwards the DHCP

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

113 of 486

AX Series - System Configuration and Administration Guide Configuration packet to the server. When the DHCP server replies, the AX device forwards the response to the client. Notes • In the current release, the helper-address feature provides service for

DHCP packets only. • The AX 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 AX

interface or an IP address used for SLB.

Configuration To configure DHCP relay, use the CLI.

USING THE GUI The current release does not support this feature in the GUI.

USING THE CLI To configure a helper address, use the following command at the configuration level for the AX IP interface connected to the DHCP clients: [no] ip helper-address ipaddr To display DHCP relay information, use the following command: show ip helper-address [detail] To clear statistics counters for DHCP relay, use the following command: clear ip helper-address statistics CLI Example The following commands configure two helper addresses. The helper address for DHCP server 100.100.100.1 is configured on AX 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. AX(config)#interface ethernet 1 AX(config-if:ethernet1)#ip helper-address 100.100.100.1 AX(config-if:ethernet1)#interface ve 5 AX(config-if:ve5)#ip helper-address 100.100.100.1

114 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration AX(config-if:ve5)#interface ve 7 AX(config-if:ve7)#ip helper-address 100.100.100.1 AX(config-if:ve7)#interface ve 9 AX(config-if:ve9)#ip helper-address 20.20.20.102

The following command shows summary DHCP relay information: AX3200(config)#show ip helper-address Interface Helper-Address RX --------- -------------- -----------eth1 100.100.100.1 0 ve5 100.100.100.1 1669 ve7 1668 ve8 100.100.100.1 0 ve9 20.20.20.102 0

TX -----------0 1668 1668 0 0

No-Relay -----------0 0 0 0 0

Drops -----------0 1 0 0 0

Table 4 describes the fields in the command output. TABLE 4

show ip helper-address fields

Field Interface

Description AX interface. Interfaces appear in the output in either of the following cases: • A helper address is configured on the interface.

Helper-Address RX TX No-Relay

• DHCP packets are sent or received on the interface. Helper address configured on the interface. Number of DHCP packets received on the interface. Number of DHCP packets sent on the interface. Number of packets that were examined for DHCP relay but were not relayed, and instead received regular Layer 2/3 processing. Generally, this counter increments in the following cases: • DHCP packets are received on an interface that does not have a helper address and the packets are not destined to the relay.

Drops

• DHCP packets are received on an interface that does have a helper address, but the packets are unicast directly from the client to the server and do not need relay intervention. Number of packets that were ineligible for relay and were dropped.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

115 of 486

AX Series - System Configuration and Administration Guide Configuration The following command shows detailed DHCP relay information: AX#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 BootRequest Packets : 0 BootReply Packets

: 0

No-Relay: 0 Drops: Invalid BOOTP Port

: 0

Invalid IP/UDP Len

: 0

Invalid DHCP Oper

: 0

Exceeded DHCP Hops

: 0

Invalid Dest IP

: 0

Exceeded TTL

: 0

No Route to Dest

: 0

Dest Processing Err : 0 IP Interface: ve5 -----------Helper-Address: 100.100.100.1 Packets: RX: 16 BootRequest Packets : 16 BootReply Packets

: 0

TX: 14 BootRequest Packets : 0 BootReply Packets

: 14

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

116 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration No Route to Dest

: 2

Dest Processing Err : 0 IP Interface: ve7 -----------Helper-Address: None Packets: RX: 14 BootRequest Packets : 0 BootReply Packets

: 14

TX: 14 BootRequest Packets : 14 BootReply Packets

: 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

Table 5 describes the fields in the command output. TABLE 5

show ip helper-address detail fields

Field IP Interface Helper-Address

Description AX interface. IP address configured on the AX interface as the DHCP helper address.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

117 of 486

AX Series - System Configuration and Administration Guide Configuration TABLE 5 Field Packets

show ip helper-address detail fields (Continued) Description DHCP packet statistics: • RX – Total number of DHCP packets received on the interface. • BootRequest Packets – Number of DHCP boot request packets (Op = BOOTREQUEST) received on the interface. • BootReply Packets – Number of DHCP boot reply packets (Op = BOOTREPLY) received on the interface. • TX – Total number of DHCP packets sent on the interface. • BootRequest Packets – Number of DHCP boot request packets (Op = BOOTREQUEST) sent on the interface.

No-Relay

• BootReply Packets – Number of DHCP boot reply packets (Op = BOOTREPLY) sent on the interface. Number of packets that were examined for DHCP relay but were not relayed, and instead received regular Layer 2/3 processing. Generally, this counter increments in the following cases: • DHCP packets are received on an interface that does not have a helper address and the packets are not destined to the relay. • DHCP packets are received on an interface that does have a helper address, but the packets are unicast directly from the client to the server and do not need relay intervention.

118 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration TABLE 5 Field Drops

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

The following command clears the DHCP relay counters: AX#clear ip helper-address statistics

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

119 of 486

AX Series - System Configuration and Administration Guide Configuration

120 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide

AX Virtual Chassis System AX Virtual Chassis System (aVCS) enables you to manage multiple AX devices as a single, virtual chassis. One AX device in the virtual chassis is the virtual master (vMaster). The other AX devices are virtual blades (vBlades) within the virtual chassis, and are managed by the vMaster. This chapter describes aVCS and how to configure it. Note:

The current release supports up to 4 devices in a virtual chassis. You can configure up to 8 but a maximum of 4 devices are supported.

Note:

aVCS reload is required to place any aVCS-related configuration changes into effect.

Note:

For deployment and upgrade instructions, see the following sections: • “Deploying a Virtual Chassis (first-time deployment only)” on

page 140 • “Upgrading a Virtual Chassis” on page 146 • “Adding a Configured AX Device to a Virtual Chassis” on page 146 • “Replacing a Device in a Virtual Chassis” on page 152

Caution:

If you use the system-reset command to restore an AX device to its factory default state, the command affects all AX 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 management IP address and admin-configured admin and enable passwords are also removed.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

121 of 486

AX Series - System Configuration and Administration Guide Overview

Overview An aVCS virtual chassis contains multiple AX devices (Figure 23). The vMaster acts as a controller for the other devices (vBlades), which function as blades in the virtual chassis. FIGURE 23

122 of 486

Virtual Chassis – multiple physical devices

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview aVCS elects a single device within the virtual chassis as the vMaster for the chassis. The vMaster provides a single point of control for all devices in the virtual chassis, as shown in Figure 24. FIGURE 24

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 profiles. This includes the startup-config and any custom configuration profiles.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

123 of 486

AX Series - System Configuration and Administration Guide Overview Software Version Management The vMaster also ensures that each device is running the same software version. For example, in Figure 25, 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 25

vMaster - upgrades software on other devices

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.

124 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

High Availability This release supports the same High Availability (HA) features supported in previous releases. AX Release 2.6 and later also supports VRRP-A, an HA implementation based on VRRP. You can use either HA or VRRP-A with aVCS. However, if you use HA, an aVCS virtual chassis can contain a maximum of only 2 devices.

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. First-Time Deployment The first time you deploy a virtual chassis, the vMaster is elected based on one of the following parameters: • Priority – The device with the highest configured aVCS priority is

elected to be the vMaster • 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 26 and Figure 27 show examples for each of these parameters. In these examples, all devices in the virtual chassis are booted at the same time.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

125 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 26 vMaster Election in First-Time Deployment - same priority value on each device

126 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview FIGURE 27 vMaster Election in First-Time Deployment - different priority values configured

If you boot one of the devices first and allow it to become the vMaster, the device remains the vMaster when the other devices join the virtual chassis, even if the configured priority is higher on another device. This is due to the dynamic priority value assigned by aVCS. Figure 28 shows an example.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

127 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 28 booted first

vMaster Election in First-Time Deployment - one device

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 possible. 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 Takeover” on page 131.)

128 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

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 29. FIGURE 29

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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

129 of 486

AX Series - System Configuration and Administration Guide Overview Split Chassis If one or more vBlades lose contact with the vMaster, the vMaster remains in control for the vBlades that can still receive the vMaster’s heartbeat 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 30. FIGURE 30

vMaster Election - split chassis

After the links among the disconnected devices are restored, the devices again use the vMaster election process to elect a vMaster Generally, the vMaster that was in effect before the virtual chassis divided continues to be the vMaster after the virtual chassis is rejoined, based on the device’s dynamic priority value. (See “Dynamic Priority” on page 128.)

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.

130 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview FIGURE 31

Forced vMaster Takeover

Automated Configuration Synchronization aVCS automatically synchronizes configuration information within the virtual chassis. Configuration changes are synchronized 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 configuration information for itself and for each of the other devices. For example, configuration synchronization ensures that each device has the complete aVCS configuration for the virtual chassis (Figure 32).

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

131 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 32

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 33).

132 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview FIGURE 33

Common Parameters

Interface parameters are unique to each device and include the aVCS device number (Figure 34).

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

133 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 34

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 also can manually synchronize the configuration to specific devices. See “Manual Configuration Synchronization” on page 134.

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 vMaster, then reboots to place the image into effect. When a vBlade upgrades in this way, the new image replaces the older image, in the same image area. For example, if the vBlade boots the older image from the primary image area on the hard drive, the upgrade image downloaded from the vMaster replaces the image in the primary image area.

134 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

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 configuration changes only on the vMaster The vMaster automatically sends the changes to the vBlades. If necessary, you can change the context of the management session to a specific vBlade. In this case, the management session changes from the vMaster to the specified vBlade.

Requirements aVCS has the following requirements. Layer 2 Connectivity aVCS uses IP multicast. All AX 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. The aVCS protocol can run over a single physical interface and does not support VE interfaces or trunks. aVCS Image Location The aVCS-capable image must be installed in the same image area on each device. For example, install the image in the primary image area of the hard disk or solid state drive (SSD) on each device.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

135 of 486

AX Series - System Configuration and Administration Guide Overview Memory Requirements for aVCS with Layer 2/3 Virtualization Table 6 lists the amount of memory required in aVCS deployments that also use partitions with Layer 2/3 virtualization enabled. TABLE 6

Memory Requirements for aVCS with Layer 2/3 Virtualization

Number of Partitions with Layer 2/3 Virtualization 32 partitions 64 partitions 128 partitions

Memory Required* 6 GB memory 12 GB memory 24 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.

136 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide aVCS Parameters

aVCS Parameters Table 7 lists the aVCS parameters you can configure. Note:

TABLE 7 Parameter

aVCS reload is required to place any aVCS-related configuration changes into effect.

aVCS Parameters Description and Syntax

Supported Values

Virtual Chassis Parameters Set ID

High availability domain. All devices in the aVCS virtual chassis must also belong to the same VRRP-A set.

For set ID, use 1-7. If using HA, use 1-2 for the device ID. Default: not set

Note: The set ID does not automatically configure VRRP-A on the devices in the virtual chassis. VRRP-A requires additional configuration. (See “VRRP-A High Availability” on page 187.) [no] vrrp-a set-id num or [no] ha id {1 | 2} [set-id num] Config > HA > Setting > HA Global - General

Device ID

Note: The current release does not support VRRP-A configuration using the GUI. 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: The current release does not support VRRP-A configuration using the GUI. Floating IP address

Note: If using HA, see the “Set ID” row above. Management address of the virtual chassis. Navigating to a floating IP address accesses the current vMaster of the virtual chassis.

Valid IPv4 or IPv6 address Default: not set

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} Note: The current release does not support aVCS configuration using the GUI.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

137 of 486

AX Series - System Configuration and Administration Guide aVCS Parameters TABLE 7

aVCS Parameters (Continued)

Parameter Multicast IP address

Description and Syntax IP address to which devices in the virtual chassis send vMaster-election traffic.

Supported Values Valid IPv4 multicast address Default: 224.0.0.210

[no] vcs multicast-ip ipaddr

Multicast port

Note: The current release does not support aVCS configuration using the GUI. Protocol port from which devices in the virtual chassis send vMaster-election traffic.

1-65535 Default: 41217

[no] vcs multicast-port portnum

SSL

Note: The current release does not support aVCS configuration using the GUI. Secure Sockets Layer (SSL) for encryption of unicast traffic, such as configuration synchronization traffic, between devices.

Enabled or disabled Default: disabled

This option does not apply to multicast traffic. [no] vcs ssl-enable

Heartbeat time interval

Note: The current release does not support aVCS configuration using the GUI. Number of seconds between transmission of keepalive messages from the vMaster to vBlades.

1-60 seconds Default: 3 seconds

[no] vcs time-interval seconds

Heartbeat dead interval

Note: The current release does not support aVCS configuration using the GUI. Maximum number of seconds to wait for a keepalive message from the vMaster before triggering vMaster re-election.

5-60 seconds Default: 10 seconds

[no] vcs dead-interval seconds Note: The current release does not support aVCS configuration using the GUI.

138 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide aVCS Parameters TABLE 7 Parameter

aVCS Parameters (Continued) Description and Syntax

Supported Values

Device Configuration Parameters Device ID

Priority

Unique ID of the device within the virtual chassis.

1-8

[no] vcs device device-id

Default: not set

Note: The current release does not support aVCS configuration using the GUI. Static priority value used during vMaster election. Higher priority values are preferred over lower priority values. For example, priority value 200 is preferred over priority value 2.

1-255 Default: 0 (not set)

Note: This is only one of the parameters used during vMaster election. See “vMaster Election” on page 125. [no] priority num

Unicast port

Note: The current release does not support aVCS configuration using the GUI. Protocol port used to create TCP connections between the vMaster and vBlades. This connection is used for configuration synchronization.

1-65535 Default: 41216

[no] unicast-port portnum

Election interfaces

Note: The current release does not support aVCS configuration using the GUI. Ethernet port(s) used for vMaster election traffic.

One or more 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 vMaster and a vBlade, and cause the vBlade to reload. [no] interfaces {ethernet portnum | management | trunk trunk-num | ve ve-num} Note: The current release does not support aVCS configuration using the GUI.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

139 of 486

AX Series - System Configuration and Administration Guide Deploying a Virtual Chassis (first-time deployment only)

Deploying a Virtual Chassis (first-time deployment only) To deploy aVCS for the first time, perform the following steps. Caution:

Use this procedure only for first-time deployment of aVCS. If you are upgrading AX devices on which aVCS is already configured, see “Upgrading a Virtual Chassis” on page 146. 1. On the AX device to be used as the vMaster, configure aVCS. (See “Details for step 1” on page 140.)

Note:

If you plan to use Layer 2/3 virtualization, do not configure it yet. 2. After completing aVCS configuration on the vMaster, enable aVCS on the vBlades, and configure aVCS-related parameters for the vBlades. 3. Reload aVCS on the vBlades. At this point, the vMaster synchronizes the configuration to the vBlades. 4. View the running-config on the vMaster and on the vBlades to verify that both the vMaster and vBlades configurations are synchronized. The steps above establishes the first-time base aVCS configuration 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 2/3 virtualization, configure it on the vMaster

Details for step 1 This section provides details for step 1 in the procedure above. Use these steps only for first-time aVCS deployment. For first-time aVCS deployment only, perform the following steps on each device. 1. Configure basic system settings: • Management interface and default gateway • Hostname • Ethernet interfaces • VLANs • Routing 2. Enable aVCS.

140 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Deploying a Virtual Chassis (first-time deployment only) 3. Configure the following aVCS settings related to high availability: • Chassis ID – Assign each device to the same set. If you plan to use

VRRP-A, this is the VRRP-A set ID. If you plan to use HA (the older implementation of high availability), this is the HA set ID. • Device ID – Assign a unique device ID to each device. If you plan to use VRRP-A, this is the VRRP-A device ID. If you plan to use HA (the older implementation of high availability), this is the HA device ID. You can use HA (the older implementation of high availability) or VRRP-A. Use the same type of high availability on all devices. (See “High Availability” on page 125.) 4. Configure aVCS device settings: • vMaster-election interface – Ethernet interface(s) to use for vMaster

election. Generally, these are the interfaces connected to the other devices in the virtual chassis. • (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.

Note:

The current release does not support configuration or management of aVCS using the GUI.

USING THE GUI

USING THE CLI Perform the following steps on each device. 1. To enable aVCS, enter the following command at the Privileged EXEC level of the CLI: vcs enable Enter the configure command to access the global configuration level of the CLI. 2. To specify the chassis ID and device ID, use the following VRRP-A commands or HA command at the global configuration level of the CLI. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

141 of 486

AX Series - System Configuration and Administration Guide Deploying a Virtual Chassis (first-time deployment only) 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 specify the floating interface for virtual chassis management, use the following command at the global configuration level of the CLI: [no] vcs floating-ip ipaddr {subnet-mask | /mask-length} The address must be in the same subnet as an IP interface configured on the device. Make sure the address is not already assigned to another device on the network. 4. 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:

142 of 486

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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Deploying a Virtual Chassis (first-time deployment only)

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 command enables aVCS:

AX-1#vcs enable

The following commands configure the high availability set ID and device ID: AX-1#configure AX-1(config)#vrrp-a set-id 1 AX-1(config)#vrrp-a device-id 1

The following command configures the management address for the virtual chassis: AX-1(config)#vcs floating-ip 192.168.100.169 /24

The following commands configure the aVCS profile for the device: AX-1(config)#vcs device 1 AX-1(config-vcs-dev)#enable AX-1(config-vcs-dev)#interfaces management AX-1(config-vcs-dev)#priority 125 AX-1(config-vcs-dev)#exit AX-1(config)#vcs reload

Commands on Device 2 AX-2#vcs enable AX-2#configure AX-2(config)#vrrp-a set-id 1 AX-2(config)#vrrp-a device-id 2 AX-2(config)#vcs floating-ip 192.168.100.169 /24 AX-2(config)#vcs device 2 AX-2(config-vcs-dev)#enable AX-2(config-vcs-dev)#interfaces management AX-2(config-vcs-dev)#priority 126 AX-2(config-vcs-dev)#exit AX-2(config)#vcs reload

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

143 of 486

AX Series - System Configuration and Administration Guide Deploying a Virtual Chassis (first-time deployment only)

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 144.) Temp-priority Value This command does not change the configured aVCS priority on the vBlade. The command only temporarily overrides the configured priority. If you enter this command on only one vBlade, you can specify any value within the valid range (1-255). The takeover occurs regardless of priority settings on the current vMaster If you enter the vcs vmaster-take-over command on more than one vBlade, the device on which you enter the highest temp-priority value becomes the vMaster If you enter the same temp-priority value on more than one vBlade, the same parameters used for initial vMaster election are used to select the new vMaster: • The device with the highest configured aVCS priority is selected. (This

is the priority configured by the priority command at the configuration level for the aVCS device.) • If there is a tie (more than one of the devices has the same highest con-

figured aVCS priority), then the device with the lowest device ID is selected. In either case, the new vMaster is selected from among only the vBlades on which you enter the vcs vmaster-take-over command.

144 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Deploying a Virtual Chassis (first-time deployment only)

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 inter-

face or a data interface, the asterisk indicates the device. • If you are logged onto the floating IP address of the virtual chassis, the

asterisk indicates the vMaster (This is true unless you changed the device context of the management session. In this case, you are logged onto the vBlade to which you changed the device context. See “Virtual Chassis Management Interface” on page 135.) 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: AX#show running-config | include local-device vcs local-device 2

Displaying aVCS Information To display aVCS information, use the following commands: show vcs summary This command shows global virtual chassis parameters, and lists the current role (vMaster or vBlade) of each device in the virtual chassis. show vcs stat This command shows detailed statistics. show vcs images This command lists the installed aVCS-capable AX software image.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

145 of 486

AX Series - System Configuration and Administration Guide Upgrading a Virtual Chassis

Upgrading a Virtual Chassis To upgrade, see the release notes for the AX release to which you plan to upgrade.

Adding a Configured AX Device to a Virtual Chassis Caution:

By default, when you add a configured AX 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. Procedure To add an AX device that already has a configuration to an aVCS chassis: 1. Upgrade the virtual chassis to AX Release 2.6.1 or later. (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: show vcs summary command 3. Connect the configured AX device to the Layer 2 network that contains the other virtual chassis members. 4. Configure aVCS settings on the new device and reload aVCS. (See “CLI Example” below.) 5. Verify that the device is now a member of the virtual chassis: show vcs summary command

Note:

146 of 486

Do not use the disable-merge option when you reload aVCS. This option is used only when replacing an existing virtual chassis member with a new device. (See “Replacing a Device in a Virtual Chassis” on page 152.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Adding a Configured AX Device to a Virtual Chassis

Overview Figure 35 shows the process that occurs when you add an AX device that is already configured to a virtual chassis. FIGURE 35 Previously Configured Device Added to Virtual Chassis and Merged with Virtual Chassis

The following process occurs when you add a previously configured AX device to a virtual chassis: 1. The previously configured AX 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 synchronization process.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

147 of 486

AX Series - System Configuration and Administration Guide Adding a Configured AX Device to a Virtual Chassis 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.

148 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Adding a Configured AX Device to a Virtual Chassis More Detailed Example Figure 36 shows the configuration information present on the vMaster and on a configured AX device added to the virtual chassis, before the configuration merge. FIGURE 36 Configured Device Added to Virtual Chassis - before configuration merge

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

149 of 486

AX Series - System Configuration and Administration Guide Adding a Configured AX Device to a Virtual Chassis Figure 37 shows the results of the configuration merge. FIGURE 37 Configured Device Added to Virtual Chassis - after configuration merge

150 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Adding a Configured AX Device to a Virtual Chassis Figure 38 shows the completed merge process, after the admin reloads aVCS. FIGURE 38

Configuration with New Device Synchronized to all vBlades

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

151 of 486

AX Series - System Configuration and Administration Guide Replacing a Device in a Virtual Chassis The disable-merge Option The configuration merge behavior described above occurs by default. If you want the vMaster to also remove the device-specific configuration information from the new device, use the disable-merge option when you reload aVCS.

Procedure CLI Example The following commands configure aVCS settings on a configured AX device to be added to a virtual chassis, and reload aVCS to activate the aVCS configuration: AX-3#vcs enable AX-3#configure AX-3(config)#vrrp-a set-id 1 AX-3(config)#vrrp-a device-id 3 AX-3(config)#vcs floating-ip 192.168.100.169 /24 AX-3(config)#vcs device 3 AX-3(config-vcs-dev)#enable AX-3(config-vcs-dev)#interfaces management AX-3(config-vcs-dev)#priority 197 AX-3(config-vcs-dev)#exit AX-3(config)#vcs reload

Following the reload of aVCS, the AX device joins the virtual chassis as a vBlade, and its configuration information is migrated to the virtual chassis’ vMaster

Replacing a Device in a Virtual Chassis By default, when you add an AX 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 AX device from the network and inserting another AX device of the same model, you may want the vMaster to migrate the removed device’s configuration information to the new device. In this case, when you reload aVCS on the new device, make sure to use the following option: disable-merge

152 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Replacing a Device in a Virtual Chassis CLI Example The following commands configure aVCS settings on a replacement AX device to be inserted into a virtual chassis, and reload aVCS to activate the aVCS configuration: AX-3#vcs enable AX-3#configure AX-3(config)#vrrp-a set-id 1 AX-3(config)#vrrp-a device-id 3 AX-3(config)#vcs floating-ip 192.168.100.169 /24 AX-3(config)#vcs device 3 AX-3(config-vcs-dev)#enable AX-3(config-vcs-dev)#interfaces management AX-3(config-vcs-dev)#priority 197 AX-3(config-vcs-dev)#exit AX-3(config)#vcs reload disable-merge

Following the reload of aVCS, the AX device joins the virtual chassis as a vBlade, and receives its configuration information from the virtual chassis’ vMaster

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

153 of 486

AX Series - System Configuration and Administration Guide Replacing a Device in a Virtual Chassis

154 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide

Role-Based Administration with Layer 2/3 Virtualization The AX Series provides Virtualized Management, through Role-Based Administration (RBA). RBA allows administrators (“admins”) to configure and view network and SLB resources based on administrative domains (“partitions”). RBA supports separate partitions for these types of resources. Partitioning allows the AX device to be logically segmented to support separate configurations for different customers; for example, separate companies or separate departments within an enterprise. Admins assigned to a partition can manage only the resources inside that partition. Optionally, Layer 2/3 virtualization can be enabled on individual partitions, allowing partitions to own their own network resources. Note:

RBA is backwards compatible with configurations saved under earlier AX releases. All resources are automatically migrated to a single, shared partition.

Note:

RBA is also called “Application Delivery Partitioning (ADP)”. The Layer 2/3 virtualization functionality that you can enable on individual partitions is sometimes called “L3V”.

Note:

The older implementation of High Availability (HA) is not supported with Layer 2/3 virtualization. To use redundancy with Layer 2/3 virtualization, use VRRP-A. (See “VRRP-A High Availability” on page 187.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

155 of 486

AX Series - System Configuration and Administration Guide Overview

Overview Figure 39 shows an example of an AX device with multiple partitions. FIGURE 39

Role-Based Administration

In this example, a service provider hosts an AX device shared by two companies: A.com and B.com. Each company has its own dedicated servers that they want to manage in entirety. The partition for A.com contains A.com's SLB resources. Likewise, the partition for B.com contains B.com's SLB resources. Admins assigned to the partition for A.com can add, modify, delete and save only those resources contained in A.com's partition. Likewise, B.com's admins can add, modify, delete and save only the resources in B.com's partition. The following sections describe RBA in more detail.

156 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Resource Partitions AX system resources are contained in partitions. The AX device has a single shared partition and can have multiple private partitions. • Shared partition – The shared partition contains resources that can be

configured only by admins with Read Write privileges. By default, all resources are in the shared partition. There is one shared partition for the device and it is the default partition. The shared partition cannot be deleted. • Private partitions – A private partition can be accessed only by the

admins who are assigned to it, and by admins with Read Write or Read Only privileges. The AX device does not have any private partitions by default. Private partitions can be created or deleted only by admins who have Read Write privileges. A maximum of 128 partitions are supported. (For descriptions of admin privileges, see Table 8 on page 160.) Types of Resources That Can Be Contained in Private Partitions The following types of resources can be contained in private partitions: • Layer 2 resources: • VLANs • Virtual Ethernet (VE) interfaces • Static MAC entries • Layer 3 resources: • IP addresses • ARP entries • Routing tables • SLB resources: • Real servers • Virtual servers • Service groups • Templates • Health monitors • Certificates and keys • aFleX policies

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

157 of 486

AX Series - System Configuration and Administration Guide Overview All other types of resources can reside only in the shared partition and are not configurable by admins assigned to private partitions. Resource names must be unique within a partition. However, the same name can be used for resources in different partitions. For example, partitions “A.com” and “B.com” can each have a real server named “rs1”. The AX device is able to distinguish between them. Use of Shared Resources by Private Resources SLB resources in private partitions can use SLB resources in the shared partition, but cannot use resources in other private partitions. For example, a virtual service port in a private partition can be configured to bind to a service group in the shared partition, as shown in the following GUI example. FIGURE 40

Shared SLB Resource Used by Private SLB Resource

Resources in a private partition cannot be used by resources in any other partition, whether private or shared. aFleX Policies By default, aFleX policies act upon resources within the partition that contains the aFleX policy. Some aFleX commands have an option to act upon service groups in the shared partition instead. (For more information, see the AX Series aFleX Reference.)

158 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview Partition Logos Each private partition has a logo file associated with it. The logo appears in the upper left corner of the Web GUI. By default, the A10 Networks logo is used. Partition admins can replace the A10 Networks logo with a company logo. The recommended logo size is 180x60 pixels. The following examples show Web GUI pages for two private partitions. A company-specific logo has been uploaded for each partition. FIGURE 41

Configurable Partition Logos

Administrator Roles Admins with Read Write privileges can configure other admin accounts, including partition admin accounts. Each account includes a GUI access role (GUI), 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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

159 of 486

AX Series - System Configuration and Administration Guide Overview Each private partition admin can have one GUI access role and one CLI privilege level. Table 8 describes the GUI access roles and CLI privilege levels. TABLE 8

Admin Privilege Levels

GUI Access Role PartitionReadWrite PartitionNetworkOperator

PartitionSlbServiceAdmin PartitionSlbServiceOperator

CLI Privilege Level Partition-write No equivalent CLI privilege level. Use Partition-write.

No equivalent CLI privilege level. Use Partition-write. Partition-enable-disable

Access to Shared Partition Read-only None

None None

Access to the Private Partition Read-write for all resources. Read-only for network resources, with permission to enable or disable interfaces. Note: Layer 2/3 virtualization must be enabled in the partition. Otherwise, no access to network resources is allowed. Read-write for SLB resources. 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.

PartitionReadOnly

Partition-read

Read-only

All access is restricted to the partition to which the admin is assigned. Read-only.

In addition to the pre-configured GUI access roles described here, admins with global read-write access can configure additional GUI access roles or customize the preconfigured ones. (See “GUI Access Roles” on page 324.)

Partition-Based Logging Note:

In the current release, it is not recommended to configure dedicated logging within private partitions. Attempting to configure logging within a private partition will result in global syslog messages being added to the log. On AX devices that do not support Layer 2/3 virtualization, the output of the log command in aFleX scripts is written into the log of the shared partition, even if the aFlex script is active in another partition.

160 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview 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 virtual ports The CLI commands and GUI options for configuring logging are the same as those in previous releases. To configure logging for a private partition, access the configuration level for the partition, then configure the logging parameters. • The logging buffer for the shared partition holds a maximum of 30,000

logs by default. The maximum number of logs can be changed to 10,000-50,000 logs. • Each private partition’s logging buffer holds a maximum of 3,000 logs

by default. The maximum number of logs can be changed to 1,000-5,000 logs. Note:

If the private partition is running from compact flash instead of the hard drive, the default is 600 logs. The configurable range is 200-1000 logs.

Partition-Based CLI Banner Admins with the proper privilege level can configure the banner message displayed when the Privileged EXEC level of the CLI is accessed by a partition admin. The CLI commands and GUI options are the same as those in previous releases.

Layer 2/3 Virtualization Layer 2/3 virtualization allows a private partition to have its own network resources. You can enable Layer 2/3 virtualization on an individual partition basis. Admins with the proper privilege level for a private partition on which Layer 2/3 virtualization is enabled can configure the following network resources for exclusive use by the individual partition:

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

161 of 486

AX Series - System Configuration and Administration Guide Overview • Layer 2 resources: • VLANs • Virtual Ethernet (VE) interfaces • Static MAC entries • Layer 3 resources: • IP addresses • ARP entries • Routing tables

Each partition has its own MAC table and ARP table, and its own IPv4 and IPv6 route tables. They are completely separate from the MAC, ARP, and IP route tables in other partitions. After a network resource belongs to a partition, the resource does not appear in show command output except for the shared partition and the partition to which the interface belongs. Likewise, statistics for the resource are not included in the statistics counters for other private partitions. Note:

An exception is tagged VLAN ports. A port that is a tagged member of any VLAN is available to all partitions. The VLAN tag ensures that a given partition’s traffic remains within that partition’s Layer 2 broadcast domain.

Requirements Layer 2/3 resources must be unique within a given partition. However, some types of Layer 2/3 resources can be the same in multiple partitions, as long as they remain unique within a given partition: • VE number • NAT pool • Interface IP addresses • IP addresses in source NAT pools • Virtual server IP addresses (VIPs)

For example, multiple partitions can use a real server that has IP address 10.10.10.10, but a given partition can have only one instance of the server. Each private partition in which Layer 2/3 virtualization is enabled supports a maximum of 2 loopback interfaces, with IDs 1-2. Loopback interface IDs 1-10 are valid in the shared partition.

162 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview Table 9 lists the operational differences between RBA partitions in which Layer 2/3 virtualization is enabled or disabled. .

TABLE 9

Operational Comparison Between Layer 2/3 Virtualization Enabled and Disabled Layer 2/3 Virtualization Enabled

Resource Port state

Private Partition Enabling and disabling allowed

Untagged VLAN ports

Visible only in the partition they belong to

Tagged VLAN ports

Trunks

VLANs

VEs

Layer 2/3 Virtualization Disabled

Shared Partition Enabling and disabling of any port allowed from shared partition Visible in the shared partition

Private Partition Enabling and disabling allowed

Shared Partition Enabling and disabling allowed

Visible in all the private partitions

Visible in the shared partitions

Can not be configured if it belongs to some partition other than shared

Can be configured, disabled, enabled from all the partitions

Can be configured, disabled, enabled from the shared partition

Visible in all the partitions

Visible in all the partitions

Visible in all the partitions

Disabling or enabling a tagged port within a partition does not disable the port in other partitions

Disabling or enabling a tagged port within the shared partition also disables the port in all other partitions

Disabling or enabling a tagged port within a partition also disables or enables the port in other partitions

Allowed

Allowed

Allowed

Disabling or enabling a tagged port in the shared partition also disables or enables the port in all private partitions Allowed

Note: The trunk can be configured only in the shared partition. Same VLAN ID can not be configured in different partitions Same VE numbers allowed in different partitions

Same VLAN ID can not be configured in shared partition Same VE numbers allowed in shared partition

Same VLAN ID can not be configured in different partitions Same VE numbers not allowed in different partitions

Same VLAN ID can not be configured in shared partition Same VE numbers not allowed in different partitions

Can not be configured from a partition which they do not belong to Visible in all the partitions

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

163 of 486

AX Series - System Configuration and Administration Guide Overview TABLE 9

Operational Comparison Between Layer 2/3 Virtualization Enabled and Disabled (Continued) Layer 2/3 Virtualization Enabled

Resource IP addresses

Private Partition Same subnet allowed in different partitions A tagged port can have same subnet across different partitions under different VLANs

ACLs NAT pools

Static routing Dynamic routing VIPs

Real servers

Note: Duplicate IP addresses are not supported. Supported Same NAT pools allowed across different partitions Supported Supported VIPs with same name or same subnet not allowed in different partitions

Servers with same name or same IP address allowed in different partitions

Shared Partition Same subnet with regard to different partitions allowed in shared partition A tagged port can have same subnet as other partitions but with different VLAN ID

Supported Same NAT pools allowed in shared partition Supported Supported VIPs with same name or same subnet not allowed in different partitions

Servers with same name or same IP address allowed in different partitions

Layer 2/3 Virtualization Disabled Private Partition Same subnets not allowed in different private partition

Shared Partition Same subnets not allowed in shared partition

A tagged port is not allowed to have same subnets even with different VLAN IDs

A tagged port is not allowed to have same subnets even with different VLAN IDs in shared partition

Not supported Same NAT pools not allowed

Supported Same NAT pools not allowed

Not supported Not supported VIPs with same name or same subnet not allowed in different partitions

Supported Supported VIPs with same name or same subnet not allowed in different partitions

VIPs from other partitions allowed

VIPs from shared partition can be used by any other partition Servers with same name or same subnet not allowed in different partitions

Servers with same name or same subnet not allowed in different partitions Servers from other partitions allowed

164 of 486

Servers from shared partition can be used by any other partition

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Per-partition Feature Support for Layer 2/3 Virtualization The following features can be configured in private partitions on which Layer 2/3 virtualization is enabled. The CLI and GUI syntax for configuring and monitoring these features is the same as in previous releases. Configuration of these features takes effect in the partition where the configuration is performed. Note:

This enhancement applies only to partitions in which Layer 2/3 virtualization is enabled. If Layer 2/3 virtualization is disabled, these features can not be configured within the partition. Features that can be configured at the global configuration level within a private partition: • Hardware-based SYN cookies • Disable of Layer 3 forwarding between VLANs • Source-IP connection-rate limiting • DNS caching • ICMP rate limiting • Session filtering • Global SLB options: • SLB peak-connection statistics (extended-stats) • SLB graceful shutdown • Default compression block size for SLB • Transparent TCP template • Source NAT gateway for Layer 3 • Source NAT on VIP • Reset stale session • Application templates: • TCP • Source-IP persistence • Destination-IP persistence

(Also see “Per-partition Default SLB Templates for Layer 2/3 Virtualization” on page 166.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

165 of 486

AX Series - System Configuration and Administration Guide Overview 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 2/3 Virtualization Layer 2/3 Virtualization supports partition-specific default server and port templates. If access to the shared partition by private partition admins is disabled, each private partition on which Layer 2/3 virtualization is enabled has its own set of default templates of the following types: • 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 2/3 virtualization is enabled. This behavior does not apply to feature templates such as HTTP, TCP, or source-IP persistence templates. This behavior is available only if access to the shared partition by private partition admins is disabled. This access is enabled by default. (See “Disabling Private Partition Admin Access to the Shared Partition” on page 172.)

Limitations Firewall Load Balancing (FWLB) is not supported in individual private partitions. This feature can be configured only in the shared partition. Link Load Balancing (LLB) is supported in private partitions only if the feature is configured using a wildcard VIP.

166 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration

Configuring Role-Based Administration To configure role-based administration, log in using an admin account with Read Write privileges, and perform the following steps: 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. 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.

Configuring Private Partitions To configure a private partition, use either of the following methods.

USING THE GUI 1. Select Config > System > Admin. 2. On the menu bar, select Partition. 3. Click New. The Partition section appears. 4. Enter a name for the partition. 5. To upload a logo for the partition, click Browse and navigate to the logo file. 6. If a partition logo is not uploaded, the A10 Networks logo is used by default. 7. Click OK. The new partition appears in the partition list.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

167 of 486

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration FIGURE 42

Config > System > Admin > Partition

FIGURE 43

Config > 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 [network-partition]] id num] The partition-name can be 1-14 characters. The max-aflex-file option specifies the maximum number of aFleX policies the partition can have. You can specify 1-128. The default is 32. The network-partition option enables Layer 2/3 virtualization, which allows the partition to have its own network resources, separate from the shared partition and other private partitions. (For more information, see “Layer 2/3 Virtualization” on page 161.) 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

168 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration deployments (HA, VRRP-A, aVCS). The partition ID can be 1-128. The AX 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).

Migrating Resources Between Partitions Resources cannot be moved directly from one partition to another. To move resources, an admin must delete the resources from the partition they are in, then recreate the resources in the new partition.

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 > System > Admin. 2. On the menu bar, select Partition. 3. Select the partition. (Click the checkbox next to the partition name.) 4. Click Delete.

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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

169 of 486

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration

Configuring a Custom GUI Access Role Note:

Configuration of GUI access roles is supported only in the GUI. 1. Select Config > Settings > 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 can not 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” on page 329.

USING THE GUI To configure an admin account for a private partition: 1. Select Config > 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.

170 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration 5. To restrict login access by the admin to a specific host or subnet: a. Enter the address in the Trusted Host IP Address field. b. To restrict access to just a single host, edit the value in the Netmask field to 255.255.255.255. c. To restrict access to a subnet, edit the value in the Netmask field to the subnet mask for the subnet. Note:

To allow access from any host, leave the Trusted Host IP Address and Netmask fields blank. 6. Select the role from the Role drop-down list. The role defines the read or write access allowed to the admin for each GUI page. (See “GUI Access Roles” on page 324.) 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 Role-Based Administration (RBA) partition, select the partition from the Partition drop-down list. 9. Leave the Status enabled. 10. Click OK. The new admin appears in the Admin table.

Note:

For information about the SSH Key File section, see “SSH Public Key Authentication for SSH Management Access” on page 337. 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 command syntax shown here includes the password option. You can specify the password with the admin command, or with the separate password command at the configuration level for the account. The default password is “a10”. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

171 of 486

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration The privilege command specifies the privilege level for the account and assigns the account to a partition. Note:

The other admin configuration commands do not apply specifically to role-based administration. For information about these other commands, see “Configuring Additional Admin Accounts” on page 322.

Disabling Private Partition Admin Access to the Shared Partition Admins of the shared partition to can prevent private partition admins from changing their active partition to the shared partition. By default, a private partition admin is allowed to change the active 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 partition admins from changing their active partition to the shared partition, use the following command at the global configuration level of the CLI: [no] partition no-sharing

172 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration

CLI Examples The following subsections show RBA configuration examples. The first example does not use Layer 2/3 virtualization. The second examples does.

RBA Configuration Without Layer 2/3 Virtualization The following commands configure two private partitions, “companyA” and “companyB”, and verify that they have been created. AX(config)#partition companyA id 1 AX(config)#partition companyB id 2 AX(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: AX(config)#admin compAadmin password compApwd AX(config-admin:compAadmin)#privilege partition-write companyA Modify Admin User successful ! AX(config-admin:compAadmin)#exit AX(config)#admin compBadmin password compBpwd AX(config-admin:compBadmin)#privilege partition-write companyB Modify Admin User successful ! AX(config-admin:compBadmin)#exit

The following command displays the admin accounts: AX(config)#show admin UserName

Status

Privilege Partition

------------------------------------------------------admin

Enabled

R/W

compAadmin

Enabled

P.R/W

companyA

compBadmin

Enabled

P.R/W

companyB

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

173 of 486

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration The show admin command shows privilege information for CLI access as follows: • R/W – The admin has Read-Write privileges. • R – The admin has Read-Only privileges. • P.R/W – The admin is assigned to a private partition and has Partition-

write (read-write) privileges within that partition. • P.R – The admin is assigned to a private partition and has Partition-read

(read-only) privileges within that partition. • P.RS Op – The admin is assigned to a private partition but has permis-

sion only to view service port statistics for real servers in the partition, and to disable or re-enable the real servers.

RBA Configuration With Layer 2/3 Virtualization Enabling Layer 2/3 Virtualization The following commands log onto the CLI with Read Write admin access, and enable Layer 2/3 virtualization for partitions dmz1 and dmz2: login as: admin Welcome to AX Using keyboard-interactive authentication. Password:*** [type ? for help] AX>enable AX#configure AX(config)#partition dmz1 network-partition id 3 AX(config)#partition dmz2 network-partition id 4

Configuring Partition-Specific Layer 2/3 Resources The following commands log onto the CLI and access partition dmz1: login as: admin-dmz1 Welcome to AX Using keyboard-interactive authentication. Password:*** [type ? for help] AX[dmz1]>enable AX[dmz1]#configure AX[dmz1](config)#

174 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration The following commands configure Layer 2/3 resources for the partition: AX[dmz1](config)#vlan 100 AX[dmz1](config-vlan:100)#tagged ethernet 1 AX[dmz1](config-vlan:100)#untagged ethernet 2 AX[dmz1](config-vlan:100)#router-interface ve 100 AX[dmz1](config-vlan:100)#exit AX[dmz1](config)#interface ve 100 AX[dmz1](config-if:ve100)#ip address 20.20.1.1 255.255.255.0 AX[dmz1](config-if:ve100)#exit AX[dmz1](config)#ip route 0.0.0.0 /0 20.20.101.50

The following command saves the configuration. AX[dmz1](config)#write memory Building configuration... [OK]

The following commands log onto the CLI and access partition dmz2: login as: admin-dmz2 Welcome to AX Using keyboard-interactive authentication. Password:*** [type ? for help] AX[dmz2]>enable AX[dmz2]#configure AX[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. AX[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 4 Disb None None None 1 001f.a002.0873 0.0.0.0/0 0 5 Disb None None None 1 001f.a002.0874 0.0.0.0/0 0 6 Disb None None None 1 001f.a002.0875 0.0.0.0/0 0 7 Disb None None None 1 001f.a002.0876 0.0.0.0/0 0 8 Disb None None None 1 001f.a002.0877 0.0.0.0/0 0 9 Disb None None None 1 001f.a002.78ec 0.0.0.0/0 0

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

175 of 486

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration 10 11 12

Disb Disb Disb

None None None

None None None

None None None

1 1 1

001f.a002.78ed 001f.a002.78ee 001f.a002.78ef

0.0.0.0/0 0.0.0.0/0 0.0.0.0/0

0 0 0

The following commands configure Layer 2/3 resources for partition dmz2, and list the interfaces: AX[dmz2](config)#vlan 200 AX[dmz2](config-vlan:200)#tagged ethernet 1 AX[dmz2](config-vlan:200)#untagged ethernet 3 AX[dmz2](config-vlan:200)#router-interface ve 200 AX[dmz2](config-vlan:200)#exit AX[dmz2](config)#interface ve 200 AX[dmz2](config-if:ve200)#ip address 20.20.2.1 255.255.255.0 AX[dmz2](config-if:ve200)#exit AX[dmz2](config)#ip route 0.0.0.0 /0 20.20.102.50 AX[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 Up Full 1000 None 200 001f.a002.0871 0.0.0.0/0 0 4 Disb None None None 1 001f.a002.0873 0.0.0.0/0 0 5 Disb None None None 1 001f.a002.0874 0.0.0.0/0 0 6 Disb None None None 1 001f.a002.0875 0.0.0.0/0 0 7 Disb None None None 1 001f.a002.0876 0.0.0.0/0 0 8 Disb None None None 1 001f.a002.0877 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 ve1 Up N/A N/A N/A 200 001f.a002.0870 20.20.2.1/24 1

The following command saves the configuration. AX[dmz2](config)#write memory Building configuration... [OK]

The following commands again log onto the CLI and access partition dmz1, and display the list of Ethernet interfaces. Ethernet 3 is not listed since it now belongs exclusively to partition dmz2. login as: admin-dmz1 Welcome to AX Using keyboard-interactive authentication. Password:***

176 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Role-Based Administration [type ? for help] AX[dmz1]>enable AX[dmz1]#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 2 Up Full 1000 None 100 001f.a002.0871 0.0.0.0/0 0 4 Disb None None None 1 001f.a002.0873 0.0.0.0/0 0 5 Disb None None None 1 001f.a002.0874 0.0.0.0/0 0 6 Disb None None None 1 001f.a002.0875 0.0.0.0/0 0 7 Disb None None None 1 001f.a002.0876 0.0.0.0/0 0 8 Disb None None None 1 001f.a002.0877 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 ve1 Up N/A N/A N/A 100 001f.a002.0870 20.20.1.1/24 1

The following commands log onto the CLI with Read Write admin access, and display the list of Ethernet interfaces in the shared partition. All 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 AX Using keyboard-interactive authentication. Password:*** [type ? for help] AX>enable AX#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 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 4 Disb None None None 1 001f.a002.0872 0.0.0.0/0 0 5 Disb None None None 1 001f.a002.0874 0.0.0.0/0 0 6 Disb None None None 1 001f.a002.0875 0.0.0.0/0 0 7 Disb None None None 1 001f.a002.0876 0.0.0.0/0 0 8 Disb None None None 1 001f.a002.0877 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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

177 of 486

AX Series - System Configuration and Administration Guide Viewing and Saving the Configuration

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 AX device configured with private partitions, use either of the following methods.

USING THE GUI See “Switching To Another Partition” on page 180.

USING THE CLI To view the configuration, use the following commands: show running-config [all-partitions | partition partition-name] show startup-config [all-partitions | partition partition-name] 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:

178 of 486

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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Viewing and Saving the Configuration tion-name, an “Insufficient privilege” warning message appears. The resources of the other partition are not displayed.

Saving the Configuration To save the configuration on an AX 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 command is applied. Unless the

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

179 of 486

AX Series - System Configuration and Administration Guide Switching To Another Partition resources in the shared partition are being saved, the configuration profile name used with the write memory command must already exist. The command does not create new configuration profiles for private 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.

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”: AX#active-partition companyA Currently active partition: companyA AX[companyA]#

The name of the partition is shown in the CLI prompt.

180 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Synchronizing the Configuration

Synchronizing the Configuration In High Availability (HA) deployments, either VRRP-A or the older implementation of HA, partition resources can be synchronized to the backup AX device. If the AX device uses the AX Series Virtual Chassis System (aVCS) feature, configuration synchronization is automatic. (See “Automated Configuration Synchronization” on page 131.) Otherwise, the configuration must be synchronized manually. Note:

Even if aVCS is used, you still can manually synchronize the configuration at any time.

Manual Synchronization When an admin assigned to a private partition manually synchronizes the configuration to the other AX device in a High-Availability (HA) pair, the resources in the private partition are synchronized for that partition. No other resources are synchronized. An admin with Read Write privileges can specify any partitions(s) to synchronize. Note:

If you plan to synchronize the Active AX device’s running-config to the Standby AX device’s running-config, make sure to use one of the following synchronization options. Performing any one of these options ensures that new private partitions appear correctly in the Standby AX device’s configuration. – Synchronize all partitions – Synchronize the shared partition to the startup-config first, then synchronize the private partition to the running-config. – On the Active AX device, synchronize the shared partition to the running-config first. Log onto the Standby AX device and save the shared partition (write memory partition shared). Then, on the Active AX 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. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

181 of 486

AX Series - System Configuration and Administration Guide Synchronizing the Configuration

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-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ipaddr ha sync running-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ipaddr ha sync data-files [all-partitions | partition partition-name] ipaddr To synchronize the configuration for all partitions, use the all-partitions option. To synchronize only a specific private partition, use the partition partition-name option. By default, the synchronization applies only to the current partition. If you plan to use the ha sync running-config to-running-config command, see the note at the beginning of this section first. For admins logged on with Partition Write privileges, the following syntax is available: ha sync all to-startup-config ipaddr ha sync startup-config to-startup-config ipaddr ha sync running-config to-startup-config ipaddr ha sync data-files ipaddr Admins with Partition Write privileges are not allowed to synchronize to the running-config or to reload the other AX device.

182 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Operator Management of Real Servers

Operator Management of Real Servers This section is for admins with Partition Real Server Operator privileges. The procedures in this section explain how to view service port statistics, and how to disable or re-enable real servers and individual service ports on the servers. Note:

Service port statistics are not available in the GUI. To display service port statistics, use the CLI instead.

USING THE GUI This section describes how to enable or disable real servers and service ports using the GUI. To Disable or Re-Enable Servers 1. Log in with your Partition-enable-disable account. 2. Select the checkbox next to each server you want to disable or re-enable, or click Select All to select all of the servers. 3. Click Disable or Enable. FIGURE 44

Note:

Real Server Management in Operator Mode

Although the GUI displays the Delete and New buttons, these buttons are not supported for admins with Partition Real Server Operator privileges. To Disable or Re-Enable Individual Real Server Ports 1. Log in with your Partition Real Server Operator account. 2. Select the checkbox next to each server for which you want to disable or re-enable service ports, or click Select All to select all of the servers. 3. Click Edit. 4. A list of all the service ports on the selected servers is displayed.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

183 of 486

AX Series - System Configuration and Administration Guide Operator Management of Real Servers 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 45

Disabling Service Ports – Selecting the Servers

FIGURE 46

Disabling Service Ports – Selecting the Ports

USING THE CLI To View Service Statistics To view configuration information and statistics for real servers used by the partition, log in with your Partition-enable-disable account and use the following command: show slb server [server-name] [config]

184 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Operator Management of Real Servers CLI Example login as:compAoper Welcome to AX Using keyboard-interactive authentication. Password:******** Last login: Wed Aug 20 08:58:45 2008 from 192.168.1.130 [type ? for help] AX[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

AX[companyA]>show slb server config Total Number of Services configured: 2 H-check = Health check Service

Max conn = Max. Connection

Address

H-check

Wgt = Weight

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:80/tcp

8.8.8.8

Default

Enable

1000000

1

compArs2

8.8.8.8

Default

Enable

1000000

1

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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

185 of 486

AX Series - System Configuration and Administration Guide Operator Management of Real Servers Use one of the following commands to change the state of the server: {disable | enable} To verify the state change, use the show slb server command. To Disable or Re-Enable Real Service Ports Access the configuration level, then use the following command to access the operation level for the server: slb server server-name [ipaddr] Use the following command to access the operation level for the service port: port port-num {tcp | udp} Use one of the following commands to change the state of the service port: {disable | enable} To verify the state change, use the show slb server command. CLI Example The following commands access the configuration level and disable real server “compArs1” and verify the change: AX[companyA]>enable Password:******** AX[companyA]#config AX[companyA](config)#slb server compArs1 AX[companyA](config-real server)#disable AX[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

AX[companyA](config)#show slb server compArs1 config Total Number of Services configured on Server compArs1: 1 H-check = Health check Service

Max conn = Max. Connection

Address

H-check

Wgt = Weight

Status

Max conn Wgt

-----------------------------------------------------------------------------compArs1:80/tcp

7.7.7.7

Default

Enable

1000000

1

compArs1

7.7.7.7

Default

Disable

1000000

1

186 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

VRRP-A High Availability This chapter describes VRRP-A, the AX Series implementation of Virtual Router Redundancy Protocol (VRRP). VRRP-A simplifies configuration of multi-system redundancy, and allows up to 8 AX devices to serve as mutual backups for IP addresses. Note:

In the current release, up to 4 devices are supported. VRRP-A is supported only on AX 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.

Overview VRRP-A can provide redundancy for the following IP resources: • Virtual server IP addresses (VIPs) • Floating IP addresses used as default gateways by downstream devices • IPv6 NAT pools • IPv4 NAT pools • IPv4 static range lists and individual mappings for inside source NAT

Virtual Router ID Each IP resource can be associated with a virtual router ID (VRID). At any given time, the VRID is active on one of the devices in the VRRP-A set. The VRID is in standby state on the other devices. If network conditions change (the active device becomes unavailable or a link goes down), a standby device can assume the active role for the VRID. Figure 47 shows a simple VRRP-A deployment with 2 devices.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

187 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 47

VRRP-A

In this example, a pair of AX devices are configured with private partitions. The VIPs and other IP resources in each partition are backed up by the partition’s VRID. (Partition support and VRIDs are described in more detail below.) At any given time, one of the devices is the active device for a VRID and the other device is the standby for the VRID, as shown in Figure 48. FIGURE 48

VRRP-A Active and Standby for each VRID

In this example, device 1 is the active device for the shared partition and for private partition CorpB. Device 2 is the standby device for these partitions. Likewise, device 2 is the active device for private partitions CorpA and CorpC, and device 1 is the standby for these partitions.

Partition Support VRRP-A is supported on AX devices configured with Role-Based Administration (RBA) partitions, as long as Layer 2/3 virtualization is enabled in each partition. Layer 2/3 virtualization allows each private partition to have its own VRID, independent from the VRIDs belonging to other partitions.

188 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview By default, each partition has a single, independent VRID (VRID 0). Private partitions can have one VRID each. If the device is not configured with RBA partitions, the device has a shared partition only, which has a single VRID by default. Optionally, you can enable support for 32 independent VRIDs in the shared partition. Note:

Use of VRRP-A on an AX device that has RBA partitions that are not enabled for Layer 2/3 virtualization has not been tested and is not supported.

Default VRID By default, the shared partition and each private partition in which Layer 2/3 virtualization is enabled has its own VRID. The VRID name is “default”. (The numerical ID for the default VRID is 0.) The default VRID is disabled by default. When the default VRID is enabled, IP resources that belong to a partition are automatically assigned to its default VRID. For example, when a 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 192.)

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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

189 of 486

AX Series - System Configuration and Administration Guide Overview

Floating IP Addresses VRRP-A supports use of floating IP addresses. Floating IP addresses can reside on any device in the VRRP-A set, and always reside on the device that is currently active. Because floating IP addresses are always reachable regardless of the VRRP-A states of individual devices, the floating IP addresses provide network stability. In a typical VRRP-A deployment, floating IP addresses are configured for each of the AX interfaces that are used as nexthop interfaces by other devices. Figure 49 shows a simple example. FIGURE 49

Floating IP Address

In this example, a device uses AX IP address 10.8.8.6 as its default gateway. This address is configured as a floating IP address on the AX device, and always resides on the active VRRP-A device. Because the address is configured as a floating IP address on the AX 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:

190 of 486

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 AX interface can not be a floating IP address.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview Advertisement of the Floating IP MAC Address After Failover When a floating IP address moves from one AX 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 AX device sends IPv4 gratuitous ARPs (for an IPv4 floating IP address) or ICMPv6 neighbor advertisements (for an IPv6 floating IP address). The other devices in the network learn the new MAC address from the gratuitous ARPs or neighbor advertisements.

Configuration Synchronization VRRP-A supports the following methods of configuration synchronization: • Automated – Uses A10 Virtual Chassis System (aVCS) to automatically

synchronize the configuration. See “Automated Configuration Synchronization” on page 131. • Manual – See “Manually Synchronizing the Configuration” on

page 206.

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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

191 of 486

AX Series - System Configuration and Administration Guide Overview

Active / Standby Device Selection One device in the VRRP-A set can be active at any given time for a given VRID. The active device for a given VRID is selected based on VRRP-A priority. The device with the highest VRRP-A priority for a VRID becomes the active device for that VRID. Each VRID has its own priority value, which can be 1-255. The default is 150. Figure 50 shows an example. FIGURE 50

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. 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 51 shows an example.

192 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview FIGURE 51

Selection of Standby Device

The priority for VRID 0 in partition CorpB is set to 255 on device 1 but is left to its default value on the other devices. Since device 2 is has the lowest device ID among the remaining devices, device 2 becomes the standby for the VRID. The other devices are backups. If session synchronization is enabled, sessions are copied from device 1 to device 2. If a failover occurs, device 2 becomes the active device and device 1 becomes the standby device. Sessions are not synchronized to the backups. If the standby device becomes unavailable or its priority value is reduced below the priority value on another backup device, the other device becomes the new standby for the VRID, as shown in Figure 52.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

193 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 52

Note:

Selection of New Standby Device

In VRRP-A deployments of 3 or more devices, moving the active role to a backup other than the standby can cause loss of synchronized sessions, since sessions are synchronized only from the active device to the standby device. To avoid loss of sessions in this case, first change the priority on the backup so that it will assume the role of standby. Then, when VRRP-A fails over, the standby will have the synchronized sessions.

Failover Failover of a VRID from the active AX device to the standby AX device can be triggered by any of the following events: • The standby AX device stops receiving VRRP-A hello messages from

the active AX 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.

194 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview • The VRRP-A priority on the active device is manually reduced below

the priority on the standby device by an administrator, and pre-emption is enabled. • The force-self-standby option is used on the active device by an admin-

istrator.

VRRP-A Hello Messages The active AX device for a VRID periodically sends hello messages to the standby AX device and other backup devices. The hello messages indicate that the active device for the VRID is still operating. If the standby device stops receiving hello messages from the active device, operation for the VRID fails over to the standby device. The device to which operation fails over becomes the new active device for the VRID. Hello Message Timers By default, the active device sends hello messages every 200 milliseconds (ms). Standby devices, by default, wait a maximum of 1 second for a hello message. If no hello message is received within 1 second, failover occurs. The hello interval and maximum wait time (dead time) are configurable, on a device basis. Configuration of the VRRP-A timers requires write access to the shared partition. The timers can not be configured by partition admins. Hello Message Destination Addresses VRRP-A sends hello messages to the following addresses: • IPv4 multicast address 224.0.0.210, MAC address 01:00:5e:00:00:D2 • IPv6 link-local multicast address FF02::D2, MAC address

33:33:00:00:00:D2

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 53 shows an example.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

195 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 53

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 therefore becomes the active device for the VRID. The priority value of a VRID on a device can be dynamically reduced based on any of the following events: • Lost connection to a default gateway – VRRP-A periodically tests con-

nectivity to the IPv4 and IPv6 default gateways by pinging them. If a gateway stops responding, VRRP-A reduces the device’s priority for the VRID. The priority value to subtract can be specified individually for each gateway. • Lost link on Ethernet data port – If the link goes down on an Ethernet

data port, VRRP-A reduces the device’s priority for the VRID. The 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.

196 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview • VLAN inactivity – If VRRP-A stops detecting traffic on a VLAN,

VRRP-A reduces the device’s priority for the VRID. The priority value to subtract can be specified individually for each VLAN. • Real server health-check failure – If a real server in a virtual port’s ser-

vice group fails a health check, VRRP-A reduces the device’s priority for the VRID. This type of tracking can be configured an individual VIP basis. By default, none of the dynamic failover triggers are configured. They can be configured on an individual partition basis. Note:

If a tracked interface is a member of a trunk, only the lead port in the trunk is shown in the tracking configuration and in statistics. For example, if a trunk contains ports 1-3 and you configure tracking of port 3, the 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 subtracted during the next priority calculation.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

197 of 486

AX Series - System Configuration and Administration Guide Overview 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 Threshold By default, when pre-emption is enabled, even the smallest difference in priority values can trigger a failover. Optionally, you can configure a failover threshold, 1-255. In this case, the difference in priority values must be greater than the threshold, in order for failover to be triggered. The default pre-emption threshold is 0.

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.

198 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

VRRP-A Interfaces VRRP-A sends hello messages and session synchronization messages on the device’s VRRP-A interfaces. Each AX device providing VRRP-A for a VRID must have at least one Up Ethernet interface that can reach the other AX devices. If an AX device can not receive hello messages from the other devices for the VRID, the AX 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 AX device that does not have a connection to the other devices. The other active VRRP-A device is the AX device that can still reach the other AX devices (standby VRRP-A devices). By default, no VRRP-A interfaces are explicitly configured. In this case, VRRP-A uses all Up Ethernet interfaces to send and listen for hello messages. For an interface that belongs to more than 1 VLAN, the AX 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 AX interfaces to use as VRRP-A interfaces. In this case, the specified interfaces are used as VRRP-A interfaces by the shared partition and by all private partitions in which Layer 2/3 virtualization is enabled.

Explicitly Configured VRRP-A Interfaces (optional) Optionally, you can explicitly configure individual interfaces to act as VRRP-A interfaces. In this case, the AX device uses only the configured VRRP-A interfaces for hello messages. For individual Layer 2/3 virtualization (L3V) partitions, the interface requirement differs depending on whether VRRP-A interfaces are explicitly configured: • If no VRRP-A interfaces are explicitly configured (the default situa-

tion), each L3V partition must have at least one Ethernet interface that can reach the other L3V partitions for the VRID. • If at least one interface in the shared partition is explicitly configured as

an VRRP-A interface, that interface is used for the shared partition's VRID hello messages, and for the hello messages of all the VRIDs in the L3V partitions.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

199 of 486

AX Series - System Configuration and Administration Guide Overview 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.

Comparison of VRRP-A and HA VRRP-A includes numerous improvements over the HA feature available in AX releases earlier than 2.6. The older implementation is still supported for backwards compatibility. However, an AX device running AX Release 2.6 or later can run VRRP-A or HA but not both. • If you are deploying AX redundancy for the first time, it is recom-

mended to use VRRP-A. • If you are upgrading AX devices that run the earlier implementation of

HA, it is not required to change the configuration 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 10 compares the features in VRRP-A and the earlier implementation of HA. TABLE 10 Feature Comparison – VRRP-A and HA Feature Private partition support

Capacity

VRRP-A Each private partition in which Layer 2/3 virtualization is enabled has its own VRID.

Earlier Implementation of HA IP resources are shared with other partitions and can be added to an HA group for backup.

IP resources belonging to the partition are automatically added to the VRID. 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 other devices available as potential standbys.

200 of 486

An active device can have 1 other device as a standby.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview TABLE 10 Feature Comparison – VRRP-A and HA (Continued) Feature Configuration requirements

VRRP-A Only minimal configuration is required. On each device in the VRRP-A set:

Earlier Implementation of HA Configuration of HA is more complex than configuration of VRRP-A.

1. Specify the device ID. IP resources that can be backed up

2. Enable VRRP-A. • Virtual server IP addresses (VIPs)

• Virtual server IP addresses (VIPs)

• Floating IP address used as default gateway by downstream devices

• Floating IP address used as default gateway by downstream devices

• IPv4 NAT pools

• IPv4 NAT pools

• IPv6 NAT pools

• IPv6 NAT pools

• IPv4 static range lists and individual mappings for inside source NAT

• IPv4 static range lists and individual mappings for inside source NAT • Source address for IPv6 router advertisements

Configuration synchronization

If A10 Networks Virtual Chassis System (aVCS) is configured and enabled, it automatically performs configuration synchronization. Otherwise, configuration synchronization must be performed manually.

• FWLB virtual firewall address Must be performed manually

See the following: • “Automated Configuration Synchronization” on page 131

Session synchronization

Failover triggers

Pre-emption

• “Manually Synchronizing the Configuration” on page 206 Must be enabled manually on individual virtual ports

Must be enabled manually on individual virtual 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 VRRP-A priority Failover can be triggered on individual VRID basis, manually or dynamically.

Requires manual configuration of peer IP address Failover can be triggered on individual HA group basis, manually or dynamically.

(See “Failover” on page 194.) Supported

Supported

Enabled by default

Disabled by default

Configurable threshold

No threshold

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

201 of 486

AX Series - System Configuration and Administration Guide Overview

VRRP-A Parameters Table 10 lists the VRRP-A parameters you can configure. Note:

In the current release, VRRP-A is not supported in the GUI.

TABLE 11 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 given VRID must belong to the same VRRP-A set.

1-7 Default: 1

[no] vrrp-a set-id num

Device Parameters VRRP-A state

State of VRRP-A on the device.

Enabled or disabled

VRID

[no] vrrp-a enable Virtual router ID. IP resources that are backed up by VRRP-A are associated with the VRID.

Default: disabled 1-31 or “default”

ARP repeat count

Dead timer

Device ID Use of the default VRID in the shared partition

Hello interval

[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. Number of additional IPv4 gratuitous ARPs or ICMPv6 neighbor advertisements, in addition to the first one, an AX sends after transitioning from standby to active. [no] vrrp-a arp-retry num Number of hello intervals during which a backup device will wait for a hello message from the active device, before beginning failover. [no] vrrp-a dead-timer num Unique ID of the device within the VRRP-A set. [no] vrrp-a device-id num Disables use of the default VRID in the shared partition and all private partitions.

1-255 Default: 4 additional gratuitous ARPs by default, for a total of 5.

2-255 Default: 5

1-8 Default: not set Enabled or disabled Default: enabled.

Note: Disabling the default VRID allows you to use VRIDs 1-31 instead of VRID 0 (the default VRID) in the shared partition. In private partitions, disabling the default VRID disables VRRP-A. [no] vrrp-a disable-default-vrid Interval at which the active device sends VRRP-A hello messages to the backup devices. [no] vrrp-a hello-interval 100-msec-units

202 of 486

Default: “default”

1-255 units of 100 milliseconds (ms) each Default: 200 ms

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview TABLE 11 VRRP-A Parameters (Continued) Parameter VRRP-A interfaces

Description and Syntax Interfaces used for VRRP-A management.

Supported Values AX Ethernet interfaces

Note: This option is configurable only in the shared partition. If you use this option to explicitly specify VRRP-A interfaces, the interfaces are used by the shared partition and by all private partitions in which Layer 2/3 virtualization is enabled.

Default: All up interfaces in a partition are VRRP-A interfaces for that partition. (See “VRRP-A Interfaces” on page 199.)

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.

Track event delay

[no] vrrp-a interface ethernet port-num [router-interface | server-interface | both] [no-heartbeat | vlan vlan-id] Delay waited by the AX device before failover following a dynamic priority change. The track event delay helps avoid unnecessary failovers caused by brief, temporary network changes. (For more information, see “Dynamic Priority Reduction” on page 195.) [no] vrrp track-event-delay 100-ms-unit

100 milliseconds (ms) to 10000 ms, in increments of 100 ms Default: 3000 ms (3 seconds)

VRID Parameter Floating IP address

IP addresses that downstream devices should use as their default IPv4 or IPv6 gateways. Regardless of which device is active for the VRID, downstream devices can reach their default IPv4 or IPv6 gateway at the floating IP address. [no] floating-ip { ipaddr | ipv6addr [ethernet port-num | ve ve-num | trunk num] }

Valid IPv4 or IPv6 address Default: Not set 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 AX 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 2/3 virtualization (both FPGA and non-FPGA models): 64 VRRP-A floating IPs

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

203 of 486

AX Series - System Configuration and Administration Guide Overview TABLE 11 VRRP-A Parameters (Continued) Parameter Pre-emption

Description and Syntax Controls whether failovers can be caused by configuration changes to VRRP-A priority or device ID.

Supported Values Enabled or disabled

The threshold specifies the maximum difference in priority value that can exist between the active and standby devices without failover occurring.

Defaults:

[no] preempt-mode disable Priority

Tracking options (shared partition only)

[no] preempt-mode threshold num Preference of the device to become the active device for the VRID. The device that has the highest priority value for the VRID becomes the active device for the VRID. [no] priority num Tracking for dynamic priority reduction used in dynamic failover. (See “Dynamic Priority Reduction” on page 195.)

Threshold: 1-255 • enabled • threshold 0

1-255 Default: 150

Priority to subtract – 1-255 VLAN timeout – 2-600 seconds Default: not set

You can configure tracking of the following network 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

204 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Deploying VRRP-A

Deploying VRRP-A Basic VRRP-A deployment requires only the following steps on each AX 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 202.)

Specify the VRRP-A Device ID To specify the VRRP-A device ID, use either of the following methods: Use the following command at the global configuration level of the CLI: [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]

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

205 of 486

AX Series - System Configuration and Administration Guide Manually Synchronizing the Configuration

Enable VRRP-A Use the following command at the global configuration level of the CLI: [no] vrrp-a enable

Displaying VRRP-A Information To display VRRP-A information, use the following commands: show vrrp-a [detail] This command shows VRRP-A configuration information. The detail option shows statistics. show vrrp-a config This command shows the VRRP-A configuration on the device. Note:

Parameters that are set at their default values are not shown. show vrrp-a mac This command lists the virtual MAC addresses in use by VRRP-A.

Manually Synchronizing the Configuration VRRP-A can be used to provide high availability without the need to also configure aVCS. Notes: • Before synchronizing the configuration, save the configuration for all

partitions (write memory all-partitions). • Do not reload the AX device before synchronizing the configuration. • If aVCS is configured, manual configuration synchronization is not

available.

VRRP-A Information Included If VRRP-A is configured, the non-device-specific VRRP-A configuration information is included in the configuration synchronized to the other AX device.

206 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Manually Synchronizing the Configuration The following VRRP-A commands are synchronized: • vrrp-a arp-retry • vrrp-a hello-interval • vrrp-a dead-timer • vrrp-a track-event-delay • vrrp-a enable • vrrp-a disable-default-vrid • vrrp-a set-id • vrrp-a vrid • floating-ip • preempt-mode

Device-specific commands, such as commands that include the vrid option, are not synchronized.

Peer IP Address Option You must specify the destination IP address to which to synchronize the configuration. Previous releases require the connection mirror IP address to be configured, and allow manual synchronization only to that IP address. The connection mirror IP address is still supported. If configured, the 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

207 of 486

AX Series - System Configuration and Administration Guide Manually Synchronizing the Configuration

USING THE GUI To identify the Destination IP Address: Enter the show vrrp detail command. The Peer IP field lists the IP address of the VRRP-A peer. Note:

The current release does not support configuration or monitoring of VRRP-A in the GUI. To Enable SSH on an Interface: Perform the following steps on the local AX device and on the peer AX device. 1. Select Config > System > 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 AX device) in this field. Here is the complete procedure: 1. Select Config > HA > Config Sync. 2. Enter the admin username and password required for read-write access to the peer AX device. 3. If Role-Based Administration (RBA) is configured on the AX 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 unselected. 4. Next to Operation, select the information to be copied to the other AX device: • All – Copies all the following to the other AX device: • Admin accounts and settings • Floating IP addresses • IP NAT configuration • Access control lists (ACLs) • Health monitors • Policy-based SLB (black/white lists)

208 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Manually Synchronizing the Configuration • SLB • FWLB • GSLB • Data files (see below)

The items listed above that appear in the configuration file are copied to the other AX 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 AX device • Running-config – Copies everything listed for the All option, except the data files, from this AX device’s running-config • Startup-config – Copies everything listed for the All option, except the data files, from this AX 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

AX device’s running-config • To Startup-config – Copies the items selected in step 4 to the other AX device’s startup-config 6. To reload the other AX device after synchronization, select With Reload. Otherwise, the other AX 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 280. 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 detail command. The Peer IP field lists the IP address of the VRRP-A peer. To Enable SSH on an Interface: Use the following command at the global configuration level of the CLI: [no] enable-management service ssh {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

209 of 486

AX Series - System Configuration and Administration Guide Configuration Examples Use this command on the local AX device and on the peer AX 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 ha sync startup-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ipaddr ha sync running-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ipaddr ha sync data-files [all-partitions | partition partition-name] ipaddr

Configuration Examples The following sections show configuration examples for VRRP-A. The first example shows a very basic deployment using the minimum required commands. The second example includes priority configuration changes and tracking.

Simple Deployment The following commands deploy VRRP-A on a set of 4 AX devices. Commands on AX-1 AX-1(config)#vrrp-a device-id 1 AX-1(config)#vrrp-a enable

210 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration Examples Commands on AX-2 AX-2(config)#vrrp-a device-id 2 AX-2(config)#vrrp-a enable

Commands on AX-3 AX-3(config)#vrrp-a device-id 3 AX-3(config)#vrrp-a enable

Commands on AX-4 AX-4(config)#vrrp-a device-id 4 AX-4(config)#vrrp-a enable

Deployment with Custom Priority Settings The following commands configure VRRP-A on 2 AX devices, with the priority settings shown in Figure 50 on page 192. • On AX device AX-1, the priority value is set to 255 on the shared parti-

tion’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 AX 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 50 on page 192 does not include the floating IP addresses. (For more on floating IP addresses, see “Floating IP Addresses” on page 190.) Commands on AX-1 AX-1(config)#vrrp-a device-id 1 AX-1(config)#vrrp-a enable AX-1(config)#vrrp-a vrid default AX-1(config-vrid)#priority 255 AX-1(config-vrid)#floating-ip 10.10.10.2 AX-1(config-vrid)#end AX-1#active-partition CorpB Currently active partition: CorpB AX-1[CorpB]#config AX-1[CorpB](config)#vrrp-a vrid default

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

211 of 486

AX Series - System Configuration and Administration Guide Configuration Examples AX-1[CorpB](config-vrid-default)#priority 255 AX-1[CorpB](config-vrid-default)#floating-ip 30.30.30.2

Commands on AX-2 AX-2(config)#vrrp-a device-id 2 AX-2(config)#vrrp-a enable AX-2#active-partition CorpA Currently active partition: CorpA AX-2[CorpA]#config AX-2[CorpA](config)#vrrp-a vrid default AX-2[CorpA](config-vrid-default)#priority 255 AX-2[CorpA](config-vrid-default)#floating-ip 20.20.20.2 AX-2[CorpA](config-vrid-default)#end AX-2(config)#vrrp-a enable AX-2#active-partition CorpC Currently active partition: CorpC AX-2[CorpC]#config AX-2[CorpC](config)#vrrp-a vrid default AX-2[CorpC](config-vrid-default)#priority 255 AX-2[CorpC](config-vrid-default)#floating-ip 40.40.40.2

Configuration of Tracking Options The following commands configure VRRP-A tracking options. For 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. AX(config-vrid-tracking)#interface ethernet 1 priority-cost 100

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

The following commands configure the AX device to track the status of a trunk, as well as the status of ports within the trunk. If trunk 2 goes down,

212 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration Examples the priority of the associated VRID is reduced by 150. If a port within the trunk goes down, the priority of the associated VRID is reduced by 40. AX2500(config)#vrrp-a vrid 2 AX2500(config-vrid)#tracking-options AX2500(config-vrid-tracking)#trunk 2 priority-cost 150 per-port-pri 40

VLAN Tracking The following command configures tracking of VLAN 69. If the VLAN is quiet for more than 30 seconds, 50 is subtracted from the VRID priority. AX(config-vrid-tracking)#vlan 69 timeout 30 priority-cost 50

Gateway Tracking The following commands configure tracking of gateway 10.10.10.1. If the gateway stops responding to pings, 100 is subtracted from the VRID’s priority value. AX(config)#health monitor gatewayhm1 AX(config-health:monitor)#method icmp AX(config-health:monitor)#exit AX(config)#slb server gateway1 10.10.10.1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit AX(config)#vrrp-a vrid default AX(config-vrid)#tracking-options AX(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 contain any routes to the destination, 105 is subtracted from the VRID priority. AX(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 contain any routes to the destination, 80 is subtracted from the VRID priority. AX2500(config)#vrrp-a vrid 1 AX2500(config-vrid)#tracking-options AX2500(config-vrid-tracking)#route 5000::/64 priority-cost 80

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

213 of 486

AX Series - System Configuration and Administration Guide Configuration Examples 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. AX(config)#slb virtual-server vip1 192.168.1.88 AX(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.

214 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

High Availability This chapter describes High Availability (HA) and how to configure it. Note:

The version of HA described in this chapter is the version that is also supported in previous releases. For information about the new HA, VRRP-A, added in AX Release 2.6, see “VRRP-A High Availability” on page 187.

Note:

The implementation of HA described in this chapter is not supported with Layer 2/3 virtualization. To use redundancy with Layer 2/3 virtualization, use VRRP-A.

Overview High Availability (HA) is an AX feature that provides AX-level redundancy to ensure continuity of service to clients. In HA configurations, AX devices are deployed in pairs. If one AX device in the HA pair becomes unavailable, the other AX device takes over. You can configure either of the following types of HA: • Active-Standby – One AX device is the primary SLB device for all vir-

tual services on which HA is enabled. The other AX device is a hot Standby for the virtual services. • Active-Active – Each AX device is the primary SLB device for some of

the configured virtual services, and is a hot Standby for the other configured virtual services. Active-Active is supported only on AX devices that are deployed in route mode. Active-Standby is supported on AX devices deployed in transparent mode or route mode. Note:

In High Availability (HA) deployments, the AX devices must be the same model and must be running the same software version. For example, if one of the AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

215 of 486

AX Series - System Configuration and Administration Guide Overview

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

216 of 486

Active-Standby HA

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview In this example, each AX device provides SLB for two virtual servers, VIP1 and VIP2. Each AX 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 AX

device in an HA deployment must have a unique HA ID. The ID must be different on each AX device. The ID can be used as a tie breaker to select the Active AX device. (See “How the Active AX Device Is Selected” on page 234.) • HA group – HA group 1 is configured on each AX device. An AX

device can have up to 31 HA groups. Both VIPs on each AX 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 AX 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 AX device. If a failover occurs, the client sessions are maintained without interruption. (For a complete list of configurable HA parameters, see “HA Configuration Parameters” on page 238.) Maximum Number of Supported HA Floating IP Addresses • For all FPGA models: 256 floating IPs • For non-FPGA models: 64 floating IPs • For private partitions enabled for Layer 2/3 virtualization (both FPGA

and non-FPGA models): 64 floating IPs

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

217 of 486

AX Series - System Configuration and Administration Guide Overview

Layer 3 Active-Active HA Figure 55 shows an example of an Active-Active configuration. FIGURE 55

Active-Active HA

In the Active-Active configuration, as in the Active-standby configuration. only one AX is active for a given VIP. But unlike the Active-Standby configuration, the same AX device does not need to be the Active AX device for all the VIPs. Instead, each of the AX devices can be the Active AX device for some VIPs. In this example, AX1 is Active for VIP2 and AX2 is Active for VIP1.

218 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview This configuration is similar to the configuration for Active-Standby shown in Figure 54, with the following exceptions: • Both HA groups are configured on each of the AX 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 AX device than it does on the other AX 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 AX device, one of the VIPs is assigned to HA group 1 and the

other VIP is assigned to HA group 2. • On both AX 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 AX device for each VIP. Without HA pre-emption, the AX selection is based on which of the AX devices comes up first.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

219 of 486

AX Series - System Configuration and Administration Guide Overview

Layer 2 Active-Standby HA (Inline Deployment) AX devices support Layer 2 hot standby inline deployment. Inline deployment allows you to insert a pair of AX 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 AX switches would cause a Layer 2 loop, as shown in this example. FIGURE 56

Topology Supported for Layer 2 Inline HA Deployment

In this example, a pair of routers configured as a redundant pair route traffic between clients and servers. The redundant router pair can be implemented using Virtual Router Redundancy Protocol (VRRP), Extreme Standby Router Protocol (ESRP), or another equivalent router redundancy protocol.

220 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview Each real server is connected to the router pair through a Layer 2 switch. Neither the Layer 2 switches nor the routers are running Spanning Tree Protocol (STP). The network does not have any Layer 2 loops because the Layer 2 switches are not connected directly together, and the routers do not forward Layer 2 traffic. If a pair of AX switches in transparent mode are added, the AX 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 AX devices. Inline mode automatically blocks redundant paths through the Standby AX device, without the need to enable STP on any devices.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

221 of 486

AX Series - System Configuration and Administration Guide Overview FIGURE 57

Layer 2 Inline HA Deployment

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 AX running in inline mode.

222 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview • In order to prevent Layer 2 loops in a Layer 2 host-standby environ-

ment, the Standby AX does not forward traffic. In addition, the Active AX in the HA pair is designed to not forward packets destined for the Standby AX. Depending on the network topology, certain traffic to the Standby AX might be dropped if it must first pass through the Active AX.

Preferred HA Port When you enable inline mode on an AX, the AX uses a preferred HA port for session synchronization and for management traffic between the AX devices in the HA pair. For example, if you use the CLI on one AX to ping the other AX, the ping packets are sent only on the preferred HA port. Likewise, the other AX sends the ping reply only on its preferred HA port. Management traffic between AX 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 57 on page 222, Ethernet interface 5 on each AX has been configured as the preferred HA port. The AX selects the Active AX 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 AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

223 of 486

AX Series - System Configuration and Administration Guide Overview

Port Restart When a transition from Standby to Active occurs because the formerly Active AX device becomes unavailable, the other devices that are directly connected to the unavailable AX detect that their links to the AX have gone down. The devices then flush their cached MAC entries on the down links. For example, in Figure 57 on page 222, 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 AX. 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 AX 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 AX 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 AX by disabling the ports, waiting for a specified number of milliseconds, then re-enabling the ports. Toggling the ports causes the links to go down, which in turn causes the devices on the other ends of the links to flush their learned MAC entries on the links. The devices then can relearn MACs through links with the newly Active AX.

224 of 486

Note:

You must omit at least one port connecting the AX devices from the restart port-list. This is so that heartbeat messages between the AX devices are maintained; otherwise, flapping might occur.

Note:

On model AX 2000 or AX 2100, A10 recommends that you do not include Fiber ports in the restart port list.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Layer 3 Active-Standby HA (Inline Deployment) Inline mode HA is also supported for AX devices deployed in route mode (Layer 3). Layer 3 HA for inline mode is beneficial in network topologies where the AX interfaces with the clients and real servers are in the same subnet. Figure 58 shows an example. FIGURE 58

Inline Mode for Layer 3 HA

In this example, each AX device has multiple Ethernet ports connected to the clients, and multiple Ethernet ports connected to the servers. On each AX device, all these Ethernet interfaces are configured as a single Virtual Ethernet (VE) interface with a single IP address. The routers, both AX devices, and the servers are all in the same subnet.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

225 of 486

AX Series - System Configuration and Administration Guide Overview Normally, this topology would introduce a traffic loop. However, the HA inline mode prevents loops by logically blocking through traffic on the standby AX device. Spanning Tree Protocol (STP) is not required in order to prevent loops. A dedicated link between the AX devices is used for HA management traffic. In this example, the dedicated link is in another subnet. Comparison to Layer 2 Inline Mode Layer 3 inline configuration is similar to Layer 2 inline mode configuration, with the following exceptions: • Layer 3 inline mode does not require designation of a preferred port or

configuration of port restart. • CPU processing must be enabled on the Ethernet interfaces that will

receive server replies to client requests. CPU processing is required on these interfaces in order to change the source IP address from the server’s real IP address back into the VIP address. Restrictions • Supported for Active-Standby HA deployments only. Not supported for

Active-Active HA. • Inline mode is designed for one HA group in Hot-Standby mode. Do not

configure more than one HA group on an AX running in inline mode. • In order to prevent Layer 2 loops in a Layer 2 host-standby environ-

ment, the Standby AX does not forward traffic. In addition, the Active AX in the HA pair is designed to not forward packets destined for the Standby AX. Depending on the network topology, certain traffic to the Standby AX might be dropped if it must first pass through the Active AX.

HA Messages The AX devices in an HA pair communicate their HA status with the following types of messages: • HA heartbeat messages • Gratuitous ARP requests and replies

226 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

HA Heartbeat Messages Each of the AX devices regularly sends HA heartbeat messages out its HA interfaces. The Standby AX device listens for the heartbeat messages. If the Standby AX device stops receiving heartbeat messages from the Active AX device, the Standby AX device transitions to Active and takes over networking and SLB operations from the other AX device. By default, heartbeat messages are sent every 200 milliseconds. If the Standby AX device does not receive a heartbeat message for 1 second (5 times the heartbeat interval), the Standby AX device transitions to Active. The heartbeat interval and retry count are configurable. (See “HA Configuration Parameters” on page 238.)

Gratuitous ARPs (IPv4) and ICMPv6 Neighbor Advertisement (IPv6) For IPv4, when an AX device transitions from Standby to Active, the newly Active AX device sends gratuitous ARP requests and replies (ARPs) for the IPv4 address under HA control. Similarly, for IPv6, when an AX device transitions from Standby to Active, the newly Active AX 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 AX HA pair has moved, and update their forwarding tables accordingly. The Active AX device sends the gratuitous ARPs or ICMPv6 neighbor advertisements immediately upon becoming the Active AX device. To make sure ARPs or ICMPv6 neighbor advertisements are being received by the target addresses, the AX device re-sends them 4 additional times, at 500millisecond intervals.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

227 of 486

AX Series - System Configuration and Administration Guide Overview After this, the AX device sends gratuitous ARPs or ICMPv6 neighbor advertisements every 30 seconds to keep its IP information current. The retry count is configurable. (See “HA Configuration Parameters” on page 238.)

HA Interfaces When configuring HA, you specify each of the interfaces that are HA interfaces. An HA interface is an interface that is connected to an upstream router, a real server, or the other AX 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. Note:

The maximum number of HA interfaces you can configure is the same as the number of Ethernet data ports on the AX device.

Note:

If the heartbeat messages from one AX device to the other will pass though a Layer 2 switch, the switch must be able to pass UDP IP multicast packets.

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. 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 AX device is based on the status of the AX link with the real server and/or upstream router. The HA status can be one of the following:

228 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview • Up – All configured HA router and server interfaces are up. • Partially Up – Some HA router or server interfaces are down but at least

one server link and one router link are up. • Down – All router interfaces, or all server interfaces, or both are down.

The status also is Down if both router interfaces and server interfaces are not configured and an HA interface goes down. If both types of interfaces (router interfaces and server interfaces) are configured, the HA interfaces for which a type has not been configured are not included in the HA interface status determination. During selection of the active AX, the AX with the highest state becomes the active AX and all HA interfaces on that AX become active. For example, if one AX is UP and the other AX is only Partially Up, the AX that is UP becomes the active AX. If each AX has the same state, the active AX is selected as follows: • If HA pre-emption is disabled (the default), the first AX to come up is

the active AX. • If HA pre-emption is enabled, the AX with the higher HA group priority

becomes active for that group. If the group priorities on the two AX devices are also the same, the AX that has the lowest HA ID (1 or 2) becomes active. Note:

You can configure up to 31 HA groups on an AX, and assign a separate HA priority to each. For Active-Standby configurations, use only one group ID. For Active-Active configurations, use multiple groups IDs and assign VIPs to different groups.

Session Synchronization HA session synchronization sends information about active client sessions to the Standby AX device. If a failover occurs, the client sessions are maintained without interruption. Session synchronization is optional. Without it, a failover causes client 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 AX device will create a new flow for the session following failover. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

229 of 486

AX Series - System Configuration and Administration Guide Overview To enable session synchronization, see “Enabling Session Synchronization” on page 277. Session synchronization is required for config sync. Config sync uses the session synchronization link. (For more information, “Manually Synchronizing Configuration Information” on page 280.) Note:

Session synchronization is also called “connection mirroring”.

Optional Failover Triggers In addition to HA interface-based failover, you can configure failover based one any of the following: • Inactive VLAN (VLAN-based failover) • Unresponsive gateway router (gateway-based failover) • Unresponsive real servers (VIP-based failover)

VLAN-based Failover You can enable HA checking for individual VLANs. When HA checking is enabled for a VLAN, the active AX 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 AX device attempts to generate traffic by issuing ping requests to servers if configured, or broadcast ARP requests through the VLAN. If the AX device does not receive any traffic on the VLAN before the timeout expires, a failover occurs. The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default, A10 recommends trying 30 seconds. This HA checking method provides a passive means to detect network health, whereas heartbeat messages are an active mechanism. You can use either or both methods to check VLAN health. If you use both methods on a VLAN, A10 recommends that you specify an HA checking interval (timeout) that is much longer than the heartbeat interval. For a configuration example, see “VLAN-Based Failover Example” on page 270.

230 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Gateway-based Failover Gateway-based failover uses ICMP health monitors to check the availability of the gateways. If any of the active AX device’s gateways fails a health check, the AX device changes its HA status to Down. If the HA status of the other AX device is higher than Down, a failover occurs. Likewise, if the gateway becomes available again and all gateways pass their health checks, the AX device recalculates its HA status according to the HA interface counts. If the new HA status of the AX device is higher than the other AX device’s HA status, a failover occurs. Configuration of gateway-based failover requires the following steps: 1. Configure a health monitor that uses the ICMP method. 2. Configure the gateway as an SLB real server and apply the ICMP health monitor to the server. 3. Enable HA checking for the gateway. For a configuration example, see “Gateway-Based Failover Example” on page 271.

Route-based Failover Route-based failover reduces the HA priority of all HA groups on the AX 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 AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

231 of 486

AX Series - System Configuration and Administration Guide Overview For a configuration example, see “Route-Based Failover Example” on page 273.

Real Server or Port Health-based Failover You can configure the AX device to decrease the HA priority of an HA group, if a real server or port’s health status changes to Down. You can configure this feature on individual real servers and ports. The feature is disabled by default. To enable the feature, assign an HA weight to the server or port. If the server or port’s health status changes to Down, the weight value is subtracted from the priority value of the HA group. You can 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 AX 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 AX device in an HA pair to the other AX 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 AX device in the HA pair becomes the Active AX for the HA group. In this case, the AX device that has a higher value for the group’s priority becomes the Active AX device for the group. If you enable the dynamic HA option on a virtual server, the AX 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

232 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview Down by the AX 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 AX device in the HA pair, and HA pre-emption is enabled, service of the virtual serve is failed over to the other AX 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 AX device, the virtual server is failed over again to the AX 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 274.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

233 of 486

AX Series - System Configuration and Administration Guide Overview

How the Active AX Device Is Selected In Active-Standby configurations, only one AX device is Active and the other is the Standby. After you configure HA, the Active AX device is selected using the process shown in Figure 59. FIGURE 59

Initial Selection of Active AX Device

After initial selection of the Active AX device, that device remains the Active AX device unless one of the following events occurs: • The Standby AX device stops receiving HA heartbeat messages from

the Active AX device. • The HA interface status of the Active AX device becomes lower than

the HA interface status of the Standby AX device. • VLAN-based failover is configured and the VLAN becomes inactive.

234 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview • Gateway-based failover is configured and the gateway becomes unavail-

able. • HA pre-emption is enabled, and the configured HA priority is changed

to be higher on the Standby AX device. Figure 60 shows the events that can cause an HA failover. FIGURE 60

HA Failover

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

235 of 486

AX Series - System Configuration and Administration Guide Overview

HA Pre-Emption By default, a failover occurs only in the following cases: • The Standby AX device stops receiving HA heartbeat messages form

the other AX device in the HA pair. • HA interface state changes give the Standby AX device a better HA

state than the Active AX device. (See “HA Interfaces” on page 228.) • VLAN-based failover is configured and the VLAN becomes inactive.

(See “VLAN-based Failover” on page 230.) • Gateway-based failover is configured and the gateway becomes unavail-

able. (See “Gateway-based Failover” on page 231.) • VIP-based failover is configured and the unavailability of real servers

causes the Standby AX to have the greater HA priority for the VIP’s HA group. (See “VIP-based Failover” on page 232.) By default, failover does not occur due to HA configuration changes to the HA priority. To enable the AX devices to failover in response to changes in priority, enable HA pre-emption. When pre-emption is enabled, the AX device with the higher HA priority becomes the Active AX device. If the HA priority is equal on both AX devices, then the AX device with the lower HA ID (1) becomes the Active AX device. Note:

236 of 486

To force Active groups to change to Standby status, without changing HA group priorities and enabling pre-emption, see “Forcing Active Groups to Change to Standby Status” on page 276.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

HA Sets Optionally, you can provide even more redundancy by configuring multiple sets of HA pairs. FIGURE 61

Multiple HA Pairs

In this example, two HA pairs are configured. Each pair is distinguished by an HA set ID. Each HA pair can be used to handle a different set of real servers. You can configure up to 7 HA sets. This feature is supported for Layer 2 and Layer 3 HA configurations. The set ID can be specified along with the HA ID. (For syntax information, see Table 12 on page 238.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

237 of 486

AX Series - System Configuration and Administration Guide Overview

HA Configuration Parameters Table 12 lists the HA parameters. TABLE 12 HA Parameters Parameter

Description and Syntax

Supported Values

HA ID

HA ID of the AX device, and HA set to which the AX device belongs.

HA ID: 1 or 2

The HA ID uniquely identifies the AX device within the HA pair.

Default: Neither parameter is set

Global HA Parameters and HA set ID

HA set ID: 1-7

The HA set ID specifies the HA set to which the AX device belongs. This parameter is applicable to configurations that use multiple AX pairs. [no] ha id {1 | 2} [set-id num] HA group ID

Config > HA > Setting > HA Global - General Uniquely identifies the HA group on an individual AX device.

HA group ID: 1-31

The priority value can be used during selection of the Active AX device. (See“How the Active AX Device Is Selected” on page 234.)

Default: not set

Priority: 1 (low priority) to 255 (high priority

[no] ha group group-id priority num Floating IP address

Config > HA > Setting > HA Global - Group IP address that downstream devices should use as their default gateway. The same address is shared by both AX devices in the HA pair. Regardless of which device is Active, downstream devices can reach their default gateway at this IP address.

Default: not set

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 AX interface can not be a floating IP address. [no] floating-ip ipaddr ha-group group-id Config > HA > Setting > HA Global - Floating IP Address

238 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview TABLE 12 HA Parameters (Continued) Parameter HA interfaces

Description and Syntax Interfaces used for HA management.

Supported Values AX Ethernet interfaces

HA heartbeat messages are sent on HA interfaces, unless you use the option to disable the messages.

Default: not set

At least one HA interface must be specified. If the interface is tagged, then a VLAN ID must be specified if heartbeat messages are enabled on the interface. If you specify the interface type (server, router, or both), changes to the interface state can control failover. (See “HA Interfaces” on page 228 and “How the Active AX Device Is Selected” on page 234.) [no] ha interface ethernet port-num [router-interface | server-interface | both] [no-heartbeat | vlan vlan-id]

VLAN-based HA

Config > Network > Interface > LAN - Select the interface and then click HA. Enables the AX device to change its HA status based on the health of a VLAN. When HA checking is enabled for a VLAN, the active AX 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 AX device attempts to generate traffic by issuing ping requests to servers if configured, or broadcast ARP requests through the VLAN.

Valid VLAN ID Default: not set The timeout can be 2-600 seconds. Although there is no default timeout, A10 recommends trying 30 seconds.

If the AX device does not receive any traffic on the VLAN before the timeout expires, a failover occurs. [no] ha check vlan vlan-id timeout seconds Gateway-based HA

Config > HA > Setting > HA Global - Status Check Enables the AX device to change its HA status based on the health of a gateway router.

IP address of the gateway

If the gateway fails a Layer 3 (ICMP) health check, the AX device changes its HA status to Down. If the HA status of the other AX device is higher than Down, a failover occurs.

Additional configuration is required. (See “Gateway-based Failover” on page 231.)

Default: not set

[no] ha check gateway ipaddr Config > HA > Setting > HA Global - Status Check

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

239 of 486

AX Series - System Configuration and Administration Guide Overview TABLE 12 HA Parameters (Continued) Parameter Session synchronization (Also called “connection mirroring”)

Description and Syntax Enables the AX devices to share information about active client sessions. If a failover occurs, client sessions continue uninterrupted. The Standby AX device, when it becomes Active, uses the session information it received from the Active AX device before the failover to continue the sessions without terminating them.

Supported Values IP address of the other AX device Default: not set

To enable session synchronization, specify the IP address of the other AX 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

Config > HA > Setting > HA Global - General Controls whether failovers can be caused by configuration changes to HA priority or HA ID.

Enabled or disabled Default: disabled

[no] ha preemption-enable HA heartbeat interval

Config > HA > Setting > HA Global - General Interval at which the AX device sends HA heartbeat messages on its HA interfaces. [no] ha time-interval 100-msec-units

Retry count

Config > HA > Setting > HA Global - General Number of HA heartbeat intervals the Standby device will wait for a heartbeat message from the Active AX device before failing over to become the Active AX device.

1-255 units of 100 milliseconds (ms) each Default: 200 ms

2-255 Default: 5

[no] ha timeout-retry-count num ARP repeat count

240 of 486

Config > HA > Setting > HA Global - General Number of additional gratuitous ARPs, in addition to the first ones, an AX sends after transitioning from Standby to Active in an HA configuration. [no] ha arp-retry num Config > HA > Setting > HA Global - General

1-255 Default: 4 additional gratuitous

ARPs, for a total of 5

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview TABLE 12 HA Parameters (Continued) Parameter Forced failover

Layer 2/3 forwarding of Layer 4 traffic on the Standby AX device

Description and Syntax Forces HA groups to change from Active to Standby status. [no] ha force-self-standby [group-id] Note: This option provides a simple method to force a failover, without the need to change HA group priorities and enable pre-emption. The option is not added to the configuration and does not persist across reboots. Note: The current release does not support configuration of this parameter using the GUI. Enables Layer 2/3 forwarding of Layer 4 traffic on the Standby AX device. [no] ha forward-l4-packet-onstandby Note: The current release does not support configuration of this parameter using the GUI.

Supported Values Valid HA group ID. If you do not specify a group ID, all Active groups are forced to change from Active to Standby status.

Enabled or disabled Default: Disabled. Layer 4 traffic is dropped by the Standby AX device.

Global HA Parameters for Layer 2 Inline Mode Inline mode state

Enables Layer 2 inline mode and, optionally, specifies the HA interface to use for session synchronization and for management traffic between the AX devices. [no] ha inline-mode [preferred-port port-num]

Restart port list

Config > HA > Setting - HA Inline Mode List of Ethernet interfaces on the previously Active AX device to toggle (shut down and restart) following HA failover.

Enabled or disabled Default: disabled When inline mode is enabled, the preferred port is selected as described in “Preferred HA Port” on page 223.

AX Ethernet interfaces Default: not set

[no] ha restart-port-list ethernet port-list Port restart time

Config > HA > Setting - HA Inline Mode Amount of time interfaces in the restart port list remain disabled following a failover. [no] ha restart-time 100-msec-units

1-100 units of 100 milliseconds (ms) Default: 20 units of 100 ms (2 seconds)

Config > HA > Setting - HA Inline Mode

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

241 of 486

AX Series - System Configuration and Administration Guide Overview TABLE 12 HA Parameters (Continued) Parameter

Description and Syntax

Supported Values

Global HA Parameters for Layer 3 Inline Mode Inline mode state

OSPF on Standby AX device

Enables Layer 3 inline mode.

Enabled or disabled

[no] ha l3-inline-mode

Default: disabled

Config > HA > Setting - HA Inline Mode Leaves OSPF enabled on the Standby AX device.

Enabled or disabled

[no] ha ospf-inline vlan vlan-id Note: This option is not configurable using the GUI.

Default for all HA modes except Layer 3 inline: disabled. OSPF is disabled on the Standby AX device. Default for Layer 3 inline mode: enabled. OSPF is allowed to run on all VLANs by default. 100 milliseconds (ms) to 10000 ms, in increments of 100 ms Default: 3000 ms (3 seconds)

Link event delay

Change the delay waited by the AX device before changing the HA state (Up, Partially Up, or Down) in response to link-state changes on HA interfaces. [no] ha link-event-delay 100-ms-unit Config > HA > Setting - HA Inline Mode

HA group ID

HA group ID for a virtual server.

1-31

This is required to enable HA for the VIP.

Default: not set

HA Parameters for Virtual Servers

[no] ha-group group-id Server weight

Config > Service > SLB > Virtual Server Weight value assigned to real servers bound to the virtual server.

1-255 Not set

The weight is used for VIP-based failover. (See “VIP-based Failover” on page 232.) [no] ha-dynamic server-weight

Link event delay

242 of 486

Config > Service > SLB > Virtual Server - Select the HA group, then select the Dynamic Server Weight. Change the delay waited by the AX device before changing the HA state (Up, Partially Up, or Down) in response to link-state changes on HA interfaces. [no] ha link-event-delay 100-ms-unit Config > HA > Setting - HA Inline Mode

100 milliseconds (ms) to 10000 ms, in increments of 100 ms Default: 3000 ms (3 seconds)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview TABLE 12 HA Parameters (Continued) Parameter

Description and Syntax

Supported Values

HA Parameters for Virtual Service Ports Session synchronization

Enables active client sessions on this virtual port to continue uninterrupted following a failover.

(Also called “connection mirroring”)

Note: This option also requires session synchronization to be enabled globally. (See “Global HA Parameters” above.)

Enabled or disabled Default: disabled

[no] ha-conn-mirror Config > Service > SLB > Virtual Server - Port

HA Parameters for Real Servers Priority cost

Decreases the HA priority of an HA group, if the real server’s health status changes to Down. [no] ha-priority-cost weight [ha-group group-id] Note: The current release does not support configuration of this option using the GUI.

Weight: 1-255 HA group: 1-31. If no group is specified, the weight applies to all HA groups. Default: not set

HA Parameters for Real Ports Priority cost

Decreases the HA priority of an HA group, if the real port’s health status changes to Down. [no] ha-priority-cost weight [ha-group group-id] Note: The current release does not support configuration of this option using the GUI.

Weight: 1-255 HA group: 1-31. If no group is specified, the weight applies to all HA groups. Default: not set

HA Parameters for Firewall Load Balancing (FWLB) HA group ID

HA group ID for a virtual firewall or virtual firewall port.

1-31 Default: not set

[no] ha-group group-id Config > Service > Firewall > Firewall Virtual Server (for virtual firewall)

Session synchronization

Config > Service > Firewall > Firewall Virtual Server - Port (for virtual firewall port) Enables active client sessions on this virtual firewall port to continue uninterrupted following a failover.

Enabled or disabled Default: disabled

Note: This option also requires session synchronization to be enabled globally. (See “Global HA Parameters” above.) [no] ha-conn-mirror Config > Service > Firewall > Firewall Virtual Server (for virtual firewall) Config > Service > Firewall > Firewall Virtual Server - Port (for virtual firewall port)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

243 of 486

AX Series - System Configuration and Administration Guide Overview TABLE 12 HA Parameters (Continued) Parameter

Description and Syntax

Supported Values

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 command: ha-group group-id

Default: not set

Config > Service > IP Source NAT > IPv4 Pool Config > Service > IP Source NAT > IPv6 Pool Config > Service > IP Source NAT > NAT Range

HA Parameters for IP Routes Priority cost

Reduces the HA priority of all HA groups on the AX device, if the specified route is missing from the IPv4 or IPv6 route table.

Default: not set

For IPv4 routes: [no] ha check route destination-ipaddr /mask-length priority-cost weight [gateway ipaddr] [protocol {static | dynamic}] [distance num] For IPv6 routes: [no] ha check route destination-ipv6addr/mask-length priority-cost weight [gateway ipv6addr] [protocol {static | dynamic}] [distance num] Note: The current release does not support configuration of this option using the GUI.

244 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide HA Status Indicators

HA Status Indicators The HA status of an AX device is displayed in the GUI and CLI. The HA status indicators provide the following information: • Current HA status of the AX device: Active or Standby • Configuration status: • Most recent configuration update – The system time and date when

the most recent configuration change was made. • Most recent configuration save – The system time and date when the configuration was saved to the startup-config. • Most recent config-sync – The system time and date when the most recent configuration change was made. If the AX device is configured with multiple Role-Based Administration (RBA) partitions, separate configuration status information is shown for each partition.

In the GUI The current HA status is shown as one of the following: • Active • Standby • Not Configured

The config-sync status is shown as one of the following: • Sync • Not-Sync

The GUI does not indicate when the most recent configuration update or save occurred. This information is available in the CLI. (See below.) Note:

In the current release, the configuration synchronization status is not updated from Not-Sync to Sync if the synchronization target is the running-config.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

245 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA

In the CLI In the CLI, the HA the status is shown in the command prompt. For example: • AX-Active#

or • AX-Standby#

Note:

If HA is not configured, the prompt is simply the hostname (“AX” by default). Configuration status is displayed in show running-config output. Here is an example:

AX-Active#show running-config !Current configuration: 8134 bytes partition partition-1 ! !Configuration last updated at 08:11:05 IST Mon May 17 2010 !Configuration last saved at 15:16:49 IST Sat May 15 2010 !Configuration last synchronized at 08:15:02 IST Mon May 17 2010

Disabling HA Status Display in the CLI Prompt Display of the HA status in the CLI prompt is enabled by default. To disable it, use the following command at the global configuration level of the CLI: [no] terminal no-ha-prompt

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.

246 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA 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 > HA > Setting. a. In the Identifier drop-down list, select the HA ID for the AX 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 AX device in the HA Mirroring IP Address field. Note:

Enter the real IP address of the AX device, not the floating IP address that downstream devices will use as their default gateway address. 2. In the Group section, configure HA group parameters: a. Select HA group 1 from the Group Name drop-down list. b. In the Priority field, enter the priority for HA group 1 and click Add. c. If you are configuring Active-Active, select the next HA group from the Group Name drop-down list, enter its priority in the Priority field, and click Add. Repeat for each additional group used in the configuration. 3. In the Floating IP Address section, configure the floating IP addresses for the HA groups. a. Select an HA group from the Group Name drop-down list. b. Select the address type (IPv4 or IPv6). c. Enter the floating IP address for the group. d. Click Add. e. If you are configuring Active-Active, select the next HA group from the Group Name drop-down list, and repeat the previous steps. 4. Click OK.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

247 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA Configuring HA Interfaces 1. Select Config > Network > Interface. 2. On the menu bar, select LAN. The list of the AX device’s physical Ethernet data interfaces appears. 3. Perform the following steps for each HA interface. (For information, see “HA Interfaces” on page 228.) a. Click on the interface number. b. In the HA section, select Enabled next to HA Enabled. c. To specify the interface type, select one of the following or leave the setting None: • Router-Interface • Server-Interface • Both d. To enable HA heartbeat messages, select Enabled next to Heartbeat. e. To restrict the HA heartbeat messages to a specific VLAN, enter the VLAN ID in the VLAN field. f. Click OK. Configuring HA Parameters on a Virtual Server 1. Select Config > Service > SLB. 2. On the menu bar, select Virtual Server. 3. Click on the virtual server name or click Add to add a new one. 4. 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 232. 5. Configure other general settings, not related to HA, if needed. 6. 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.

248 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA 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. 7. Click OK to complete configuration of the virtual server. HA Configuration of AX1 FIGURE 62

Config > HA > Setting > HA Global

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

249 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA FIGURE 63

Note:

This example shows HA configuration of a single interface. Make sure to configure HA settings on the other HA interfaces too. FIGURE 64

250 of 486

Config > Service > Network > LAN (Ethernet interface 1)

Config > Service > SLB > Virtual Server (VIP1)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA FIGURE 65

Config > Service > SLB > Virtual Server (VIP2)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

251 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA HA Configuration of AX2

252 of 486

FIGURE 66

Config > HA > Setting

FIGURE 67

Config > Service > SLB > Virtual Server (VIP1)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA FIGURE 68

Config > Service > SLB > Virtual Server (VIP2)

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] [no-heartbeat | vlan vlan-id] ha conn-mirror ip ipaddr ha preemption-enable 2. To add a virtual server to an HA group, use the following command at the configuration level for the virtual server: ha-group group-id Use the same HA group ID for the same virtual server, on both AX 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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

253 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA 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 12 on page 238.) Commands on AX1 This examples shows the CLI commands to implement the Active-Active configuration shown in Figure 55 on page 218. 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 AX device. Likewise, the priority of group 2 is set to a high value on this AX device but will be set to a lower value on the other AX device. Later in the configuration, each virtual server will need to be added to one or the other of the HA groups. AX1(config)#ha id 1 AX1(config)#ha group 1 priority 1 AX1(config)#ha group 2 priority 255

The following commands configure the floating IP addresses for each HA group. The real servers and the Layer 2 switches connected to them will need to be configured to use the floating IP addresses as their default gateways. AX1(config)#floating-ip 10.10.10.1 ha-group 1 AX1(config)#floating-ip 10.10.10.100 ha-group 2

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

The following command enables session synchronization (connection mirroring). The feature also will need to be enabled on individual virtual ports,

254 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA later in the configuration. The IP address is the real address of the other AX device. AX1(config)#ha conn-mirror ip 10.10.30.2

The following command enables HA pre-emption, to ensure that the Active and Standby for each virtual server are chosen based on the configuration. By default, when HA is first configured, Active and Standby are selected based on which AX device comes up first. AX1(config)#ha preemption-enable

The following commands add each of the virtual servers to an HA group, and enables session synchronization on the virtual ports. (For brevity, this example does not show the complete SLB configuration, only the HA part of the SLB configuration.) AX1(config)#slb virtual-server VIP1 AX(config-slb virtual server)#ha-group 1 AX(config-slb virtual server)#port 80 tcp AX(config-slb virtual server-slb virtua...)#ha-conn-mirror AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#exit AX1(config)#slb virtual-server VIP2 AX1(config-slb virtual server)#ha-group 2 AX1(config-slb virtual server)#port 80 tcp AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror AX1(config-slb virtual server-slb virtua...)#exit AX1(config-slb virtual server)#exit

Commands on AX2 Here are the commands for AX2. The priority values for the groups are different from the values set on AX1, so that group 1 has higher priority on this AX device than on AX1. Likewise, the priority of group 2 is set so that its priority is higher on AX1. AX2(config)#ha id 2 AX2(config)#ha group 1 priority 255 AX2(config)#ha group 2 priority 1

The floating IP addresses must be the same as the ones set on AX1. AX2(config)#floating-ip 10.10.10.1 ha-group 1 AX2(config)#floating-ip 10.10.10.100 ha-group 2 AX2(config)#ha interface ethernet 1 router-interface no-heartbeat AX2(config)#ha interface ethernet 2 router-interface no-heartbeat AX2(config)#ha interface ethernet 3 server-interface no-heartbeat

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

255 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode) AX2(config)#ha interface ethernet 4 server-interface no-heartbeat AX2(config)#ha interface ethernet 5

The IP address for session synchronization is the address of AX1. AX2(config)#ha conn-mirror ip 10.10.30.1 AX2(config)#ha preemption-enable

The HA configuration for virtual servers and virtual ports is identical to the configuration on AX1. AX2(config)#slb virtual-server VIP1 AX2(config-slb virtual server)#ha-group 1 AX2(config-slb virtual server)#port 80 tcp AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror AX2(config-slb virtual server-slb virtua...)#exit AX2(config-slb virtual server)#exit AX2(config)#slb virtual-server VIP2 AX2(config-slb virtual server)#ha-group 2 AX2(config-slb virtual server)#port 80 tcp AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror AX2(config-slb virtual server-slb virtua...)#exit AX2(config-slb virtual server)#exit

Configuring Layer 2 HA (Inline Mode) To configure Layer 2 HA: 1. Configure the following global HA parameters: • HA ID • HA group ID and priority. Configure only one group ID. Configure the same ID on both AX devices. • Floating IP address (optional) • Inline mode and optional preferred port • Restart port list and time (optional) • HA interfaces • Session synchronization (optional) • HA pre-emption (optional) 2. Add each virtual server to the HA group.

256 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode) 3. If session synchronization is globally enabled, enable it on the individual virtual ports whose client sessions you want to 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 AX floating IP address, CPU processing must be enabled on the AX interfaces connected to the real servers. This 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.

Layer 2 Inline HA Configuration Example The following configuration examples implement the deployment shown in Figure 57 on page 222. 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 AX device’s summary link state for HA. (See “HA Interfaces” on page 228.) • 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 AX devices, rather than the IP address of the Active AX. Servers can still reach clients through their default gateway after an HA failover, without the need for the gateway address to be changed to the Standby AX device’s address.

USING THE GUI Configuring Global HA Parameters 1. Select Config > HA > Setting. a. In the General section, select the HA ID for the AX 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 AX device in the HA Mirroring IP Address field. Note:

Enter the real IP address of the AX device, not the floating IP address that downstream devices will use as their default gateway address.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

257 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode) 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 > Network > Interface. 2. On the menu bar, select LAN. The list of the AX device’s physical Ethernet data interfaces appears. 3. Perform the following steps for each HA interface. (For information, see “HA Interfaces” on page 228.) 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 AX floating IP address, select CPU Process in the General section. 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. g. Click OK.

258 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode) Configuring Inline Parameters 1. Select Config > HA > Setting. 2. Select HA Inline Mode on the menu bar. 3. Select Enabled next to Inline Mode Status. 4. Select the preferred port. 5. In Restart Port List section, select the HA interfaces. 6. Click >> to move them to the Selected list. 7. Click OK. The following GUI screens configure HA on AX1 in Figure 57 on page 222. FIGURE 69

Config > HA > Setting

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

259 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode) FIGURE 70

Note:

This example shows HA configuration of a single interface. Make sure to configure HA settings on the other HA interfaces too. FIGURE 71

260 of 486

Config > Service > Network > LAN (Ethernet interface 1)

Config > HA > Setting > HA Inline Mode

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode)

USING THE CLI Commands on AX1 The following commands configure the HA ID and set the HA priority. HA priority is associated with an HA group. Since inline mode is supported only in Active-Standby configurations, only one HA group is used. Later in the configuration, the VIP is assigned to this HA group. AX1(config)#ha id 1 AX1(config)#ha group 1 priority 255

The following command enables inline HA mode and specifies the preferred HA port. AX1(config)#ha inline-mode preferred-port 5

The following commands configure the HA interfaces. Each interface that is connected to a server, a router, or the other AX can be configured as an HA interface. Make sure to add the preferred HA port as one of the HA interfaces. AX1(config)#ha interface ethernet 1 router-interface no-heartbeat AX1(config)#ha interface ethernet 2 router-interface no-heartbeat AX1(config)#ha interface ethernet 3 server-interface AX1(config)#ha interface ethernet 4 server-interface AX1(config)#ha interface ethernet 5

The following command enables restart of the HA ports connected to the routers, to occur if the AX transitions to Standby. AX1(config)#ha restart-port-list ethernet 1 to 2

Note:

If source NAT is not configured for the VIP, but real servers send responses to a gateway IP address other than the AX 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 AX has higher priority, this will trigger a failover, but only if pre-emption mode is enabled.)

AX1(config)#ha preemption-enable

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

261 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode) The following command specifies the IP address of the other AX, to use for session synchronization. AX1(config)#ha conn-mirror ip 172.168.10.3

The following command configures the floating IP address for the real servers to use as their default gateway address. AX1(config)#floating-ip 172.168.10.1 ha-group 1

The following commands configure a health method, real servers, a server group, and a VIP for an HTTP service. AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX1(config-health:monitor)#method http url HEAD /index.html AX1(config-health:monitor)#exit AX1(config)#slb server s1 172.168.10.30 AX1(config-real server)#port 80 tcp AX1(config-real server-node port)#health-check myHttp AX1(config-real server-node port)#exit AX1(config-real server)#exit AX1(config)#slb server s2 172.168.10.31 AX1(config-real server)#port 80 tcp AX1(config-real server-node port)#health-check myHttp AX1(config-real server-node port)#exit AX1(config-real server)#exit AX1(config)#slb service-group g80 tcp AX1(config-slb service group)#member s1:80 AX1(config-slb service group)#member s2:80 AX1(config-slb service group)#exit AX1(config)#slb virtual-server v1 172.168.10.80 AX1(config-slb virtual server)#ha-group 1 AX1(config-slb virtual server)#port 80 tcp AX1(config-slb virtual server-slb virtua...)#service-group g80 AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror

262 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 2 HA (Inline Mode) Commands on AX2 Here are the commands for implementing HA on the standby AX, AX2. Most of the commands are the same as those on AX1, with the following exceptions: • The HA ID is 2. • The HA priority is 1. • The session synchronization (conn-mirror) IP address is the address of

the Active AX. (On the Active AX, the session synchronization IP address is the address of the Standby AX.) AX2(config)#ha id 2 AX2(config)#ha group 1 priority 1 AX2(config)#ha interface ethernet 1 router-interface no-heartbeat AX2(config)#ha interface ethernet 2 router-interface no-heartbeat AX2(config)#ha interface ethernet 3 server-interface AX2(config)#ha interface ethernet 4 server-interface AX2(config)#ha interface ethernet 5 AX2(config)#ha inline-mode preferred-port 5 AX2(config)#ha restart-port-list ethernet 1 to 2 AX2(config)#ha preemption-enable AX2(config)#ha conn-mirror ip 172.168.10.2 AX2(config)#floating-ip 172.168.10.1 ha-group 1 AX2(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX2(config-health:monitor)#method http url HEAD /index.html AX2(config-health:monitor)#exit AX2(config)#slb server s1 172.168.10.30 AX2(config-real server)#port 80 tcp AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb server s2 172.168.10.31 AX2(config-real server)#port 80 tcp AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb service-group g80 tcp AX2(config-slb service group)#member s1:80 AX2(config-slb service group)#member s2:80 AX2(config-slb service group)#exit

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

263 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA (Inline Mode) AX2(config)#slb virtual-server v1 172.168.10.80 AX2(config-slb virtual server)#ha-group 1 AX2(config-slb virtual server)#port 80 tcp AX2(config-slb virtual server-slb virtua...)#service-group g80 AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror

Configuring Layer 3 HA (Inline Mode) To configure Layer 3 HA: 1. Configure the following global HA parameters: • HA ID • HA group ID and priority. Configure only one group ID. Configure the same ID on both AX devices. • Floating IP address (optional) • Inline mode • HA interfaces • Session synchronization (optional) • HA pre-emption (optional) 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. 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 the HA group.

264 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA (Inline Mode)

Layer 3 Inline HA Configuration Example The following configuration example implements the deployment shown in Figure 58 on page 225. 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 AX1 The following commands configure the interfaces. Since Ethernet interfaces 3 and 4 will receive server replies to client requests, CPU processing is enabled on those interfaces. AX1(config)#interface ethernet 1 AX1(config-if:ethernet1)#enable AX1(config-if:ethernet1)#interface ethernet 2 AX1(config-if:ethernet2)#enable AX1(config-if:ethernet2)#interface ethernet 3 AX1(config-if:ethernet3)#enable AX1(config-if:ethernet3)#cpu-process AX1(config-if:ethernet3)#interface ethernet 4 AX1(config-if:ethernet4)#enable AX1(config-if:ethernet4)#cpu-process AX1(config-if:ethernet4)#interface ethernet 5 AX1(config-if:ethernet5)#enable AX1(config-if:ethernet5)#exit AX1(config)#vlan 100 AX1(config-vlan:100)#untagged ethernet 1 to 4 AX1(config-vlan:100)#router-interface ve 100 AX1(config-vlan:100)#exit

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

265 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA (Inline Mode) AX1(config)#vlan 5 AX1(config-vlan:5)#untagged ethernet 5 AX1(config-vlan:5)#router-interface ve 5 AX1(config-vlan:5)#exit AX1(config)#interface ve 100 AX1(config-if:ve100)#ip address 172.168.10.2 /24 AX1(config-if:ve100)#interface ve 5 AX1(config-if:ve5)#ip address 172.168.20.2 /24 AX1(config-if:ve5)#exit

The following commands configure the HA ID and set the HA priority. HA priority is associated with an HA group. Later in the configuration, the VIP is assigned to this HA group. AX1(config)#ha id 1 AX1(config)#ha group 1 priority 255

The following command enables Layer 3 inline HA mode. AX1(config)#ha l3-inline-mode

The following commands configure the HA interfaces. Each interface that is connected to a server, a router, or the other AX can be configured as an HA interface. (Make sure to add the dedicated HA link between the AX devices as one of the HA interfaces.) AX1(config)#ha interface ethernet 1 router-interface no-heartbeat AX1(config)#ha interface ethernet 2 router-interface no-heartbeat AX1(config)#ha interface ethernet 3 server-interface AX1(config)#ha interface ethernet 4 server-interface AX1(config)#ha interface ethernet 5

The following command enables restart of the HA ports connected to the routers, to occur if the AX transitions to Standby. AX1(config)#ha restart-port-list ethernet 1 to 2

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 AX has higher priority, this will trigger a failover, but only if pre-emption mode is enabled.) AX1(config)#ha preemption-enable

The following command specifies the IP address of the other AX, to use for session synchronization. AX1(config)#ha conn-mirror ip 172.168.10.3

266 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA (Inline Mode) The following command configures the floating IP address for the real servers to use as their default gateway address. AX1(config)#floating-ip 172.168.10.1 ha-group 1

The following commands configure a health method, real servers, a server group, and a VIP for an HTTP service. AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX1(config-health:monitor)#method http url HEAD /index.html AX1(config-health:monitor)#exit AX1(config)#slb server s1 172.168.10.30 AX1(config-real server)#port 80 tcp AX1(config-real server-node port)#health-check myHttp AX1(config-real server-node port)#exit AX1(config-real server)#exit AX1(config)#slb server s2 172.168.10.31 AX1(config-real server)#port 80 tcp AX1(config-real server-node port)#health-check myHttp AX1(config-real server-node port)#exit AX1(config-real server)#exit AX1(config)#slb service-group g80 tcp AX1(config-slb service group)#member s1:80 AX1(config-slb service group)#member s2:80 AX1(config-slb service group)#exit AX1(config)#slb virtual-server v1 172.168.10.80 AX1(config-slb virtual server)#ha-group 1 AX1(config-slb virtual server)#port 80 tcp AX1(config-slb virtual server-slb virtua...)#service-group g80 AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror

Commands on AX2 Here are the commands for implementing HA on AX2. Most of the commands are the same as those on AX1, with the following exceptions: • The IP interfaces are different. • The HA ID is 2. • The HA priority is 1.

The session synchronization (conn-mirror) IP address is the address of AX1. (On AX1, the session synchronization IP address is the address of AX2.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

267 of 486

AX Series - System Configuration and Administration Guide Configuring Layer 3 HA (Inline Mode) AX2(config)#interface ethernet 1 AX2(config-if:ethernet1)#enable AX2(config-if:ethernet1)#interface ethernet 2 AX2(config-if:ethernet2)#enable AX2(config-if:ethernet2)#interface ethernet 3 AX2(config-if:ethernet3)#enable AX1(config-if:ethernet3)#cpu-process AX2(config-if:ethernet3)#interface ethernet 4 AX2(config-if:ethernet4)#enable AX1(config-if:ethernet4)#cpu-process AX2(config-if:ethernet4)#interface ethernet 5 AX2(config-if:ethernet5)#enable AX2(config-if:ethernet5)#exit AX2(config)#vlan 100 AX2(config-vlan:100)#untagged ethernet 1 to 4 AX2(config-vlan:100)#router-interface ve 100 AX2(config-vlan:100)#exit AX2(config)#vlan 5 AX2(config-vlan:5)#untagged ethernet 5 AX2(config-vlan:5)#router-interface ve 5 AX2(config-vlan:5)#exit AX2(config)#interface ve 100 AX2(config-if:ve100)#ip address 172.168.10.23 /24 AX2(config-if:ve100)#interface ve 5 AX2(config-if:ve5)#ip address 172.168.20.3 /24 AX2(config-if:ve5)#exit AX2(config)#ha id 2 AX2(config)#ha group 1 priority 1 AX2(config)#ha interface ethernet 1 router-interface no-heartbeat AX2(config)#ha interface ethernet 2 router-interface no-heartbeat AX2(config)#ha interface ethernet 3 server-interface AX2(config)#ha interface ethernet 4 server-interface AX2(config)#ha interface ethernet 5 AX2(config)#ha l3-inline-mode AX2(config)#ha restart-port-list ethernet 1 to 2 AX2(config)#ha preemption-enable AX2(config)#ha conn-mirror ip 172.168.10.2 AX2(config)#floating-ip 172.168.10.1 ha-group 1 AX2(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX2(config-health:monitor)#method http url HEAD /index.html AX2(config-health:monitor)#exit

268 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Optional Failover Triggers AX2(config)#slb server s1 172.168.10.30 AX2(config-real server)#port 80 tcp AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb server s2 172.168.10.31 AX2(config-real server)#port 80 tcp AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb service-group g80 tcp AX2(config-slb service group)#member s1:80 AX2(config-slb service group)#member s2:80 AX2(config-slb service group)#exit AX2(config)#slb virtual-server v1 172.168.10.80 AX2(config-slb virtual server)#ha-group 1 AX2(config-slb virtual server)#port 80 tcp AX2(config-slb virtual server-slb virtua...)#service-group g80 AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror

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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

269 of 486

AX Series - System Configuration and Administration Guide Configuring Optional Failover Triggers

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 230.)

USING THE GUI 1. Select Config > HA > Setting > HA Global. 2. In the Status Check section, enter the VLAN ID in the VLAN ID field. 3. Enter the timeout in the Timeout field. The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default, A10 recommends trying 30 seconds. 4. Click Add. 5. Repeat step 2 through step 4 for each VLAN to be monitored for HA. 6. Click OK.

USING THE CLI To enable HA checking for a VLAN, use the following command at the global configuration level of the CLI: [no] ha check vlan vlan-id timeout seconds The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default, A10 recommends trying 30 seconds. The following command enables VLAN-based failover for VLAN 10 and sets the timeout to 30 seconds: AX(config)#ha check vlan 10 timeout 30

270 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Optional Failover Triggers

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 231.)

USING THE GUI 1. Configure a health monitor that uses the ICMP method: a. Select Config > Service > Health Monitor. b. Select Health Monitor on the menu bar. c. Click Add. d. In the Health Monitor section, enter a name for the monitor. e. In the Method section, select ICMP from the Type drop-down list. f. Click OK. 2. Configure the gateway as an SLB real server and apply the ICMP health monitor to the server: a. Select Config > Service > SLB. b. Select Server on the menu bar. c. Click Add. The General section appears. d. In the General section, enter a name for the gateway in the Name field. e. In the IP Address field, enter the IP address of the gateway. f. In the Health Monitor drop-down list, select the ICMP health monitor you configured in step 1. g. Click OK. 3. Enable gateway-based failover: a. Select Config > HA > Setting > 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

271 of 486

AX Series - System Configuration and Administration Guide Configuring Optional Failover Triggers

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

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

The following command enables HA health checking for the gateway: AX(config)#ha check gateway 10.10.10.1

272 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Optional Failover Triggers

Route-Based Failover Example You can configure HA route awareness for IPv4 routes and IPv6 routes. Note:

The current release does not support this feature in the GUI. HA Route Awareness for IPv4 Routes To configure HA route awareness for an IPv4 route, use the following command at the global configuration level of the CLI: [no] ha check route destination-ipaddr /mask-length priority-cost weight [gateway ipaddr] [protocol {static | dynamic}] [distance num] The destination-ipaddr /mask-length option specifies the destination IPv4 subnet of the route. The priority-cost weight option specifies the value to subtract from the HA priority of each HA group, if the IP route table does not have a route to the destination subnet. The gateway addr option specifies the next-hop gateway for the route. The protocol option specifies the source of the route: • static – The route was added by an administrator. • dynamic – The route was added by a routing protocol. (This includes

redistributed routes.) The distance num option specifies the metric value (cost) of the route. Omitting an optional parameter matches on all routes. For example, if you do not specify the next-hop gateway, routes that match based on the other parameters can have any next-hop gateway. HA Route Awareness for IPv6 Routes To configure HA route awareness for an IPv6 route, use the following command at the global configuration level of the CLI: [no] ha check route destination-ipv6addr/mask-length priority-cost weight [gateway ipv6addr] [protocol {static | dynamic}] [distance num] Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

273 of 486

AX Series - System Configuration and Administration Guide Configuring Optional Failover Triggers The destination-ipv6addr/mask-length option specifies the destination IPv6 address. The other options are the same as those for IPv4 routes. (See above.) CLI Examples The following command configures HA route awareness for a default IPv4 route. If this route is not in the IP route table, 255 is subtracted from the HA priority of all HA groups. AX(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.

AX(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 AX device subtracts only 5 from the HA priority of each HA group. AX(config)#ha check route 3000::/64 priority-cost 100 AX(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 247 and “Configuring HA Interfaces” on page 248. (For a description of the feature, see “VIP-based Failover” on page 232.)

274 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Optional Failover Triggers

USING THE GUI To configure VIP-based failover on a virtual server: 1. Configure HA global and interface parameters, if you have not already done so. 2. Select Config > Service > SLB. 3. On the menu bar, select Virtual Server. 4. Click on the virtual server name or click Add to create a new one. 5. 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 247. 6. Enter other parameters if needed (for example, the name, IP address, and virtual service ports). 7. Click OK.

USING THE CLI To configure VIP-based failover, use the following commands: [no] ha-group group-id Enter this command at the configuration level for a virtual server, to assign the virtual server to the HA group. The group-id can be 1-31. [no] ha-dynamic server-weight Enter this command at the configuration level for the virtual server to enable VIP-based failover. The server-weight specifies the amount to subtract from the HA group's priority value for each real server that becomes unavailable. The weight can be 1-255. The default is 1. CLI Example The following command configures HA group 6 on AX-1 and assigns priority 100 to the group: AX-1(config)#ha group 6 priority 100

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

275 of 486

AX Series - System Configuration and Administration Guide Forcing Active Groups to Change to Standby Status The following command enables HA pre-emption. HA pre-emption must be enabled in order for failover to occur based on HA group priority changes. AX-1(config)#ha preemption-enable

The following command configures a floating IP address and assigns it to HA group 6: AX-1(config)#floating-ip 192.168.10.1 ha-group 6

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.) AX-1(config)#slb virtual VIP2 192.168.10.22 AX-1(config-slb virtual server)#ha-group 6 AX-1(config-slb virtual server)#ha-dynamic 10

The following commands configure the HA settings on AX-2. The priority for HA group 6 is set to 80. The server weight for HA group 6 on VIP2 is set to 10, the same weight value set on AX-1. Up to 2 real servers bound to VIP2 can become unavailable on AX-1 without triggering a failover. 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 AX-2 for the group. In this case, a failover does occur for VIP2. AX-2(config)#ha group 6 priority 80 AX-2(config)#ha preemption-enable AX-2(config)#floating-ip 192.168.10.1 ha-group 6 AX-2(config)#slb virtual VIP2 192.168.10.22 AX-2(config-slb virtual server)#ha-group 6 AX-2(config-slb virtual server)#ha-dynamic 10

Forcing Active Groups to Change to Standby Status To force HA groups to change from Active to Standby status, use the following command at the global configuration level of the CLI: [no] ha force-self-standby [group-id] If you specify a group ID, only the specified group is forced to change from Active to Standby. If you do not specify a group ID, all Active groups are forced to change to Standby status.

276 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Enabling Session Synchronization CLI Example The following command forces HA group 1 to change from Active to Standby status: AX(config)#ha force-self-standby 1

Enabling Session Synchronization Session synchronization backs up live client sessions on the Backup AX device. To enable session synchronization: • Globally enable the feature, specifying the IP address of the other AX

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 AX 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 > HA > Setting. 2. On the menu bar, select HA Global. 3. In the Mirror IP Address field, enter the IP address of a data interface on the other AX device in the HA pair. 4. Click OK or Apply. To enable the feature on individual virtual ports: 1. Select Config > Service > Server. 2. On the menu bar, select Virtual Server. 3. Click on the virtual server name. 4. On the Port tab, select the port and click Edit.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

277 of 486

AX Series - System Configuration and Administration Guide Enabling Session Synchronization 5. Select Enabled next to HA Connection Mirror. Note:

If the HA Connection Mirror option is not displayed, session synchronization is not supported for this service type. 6. Click OK to redisplay the Port tab. 7. Click OK again.

USING THE CLI To globally enable session synchronization, use the following command at the global configuration level of the CLI: [no] ha conn-mirror ip ipaddr The ipaddr must be an IP address of a data interface on the other AX device. To enable session synchronization on a virtual port, use the following command at the configuration level for the port: [no] ha-conn-mirror CLI Example The following command sets the session synchronization address to 10.10.10.66, the IP address of the other AX in this HA pair: AX(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: AX(config)#slb virtual-server vip1 10.10.10.100 AX(config-slb virtual server)#port 80 tcp AX(config-slb virtual server-slb virtua...)#ha-conn-mirror

278 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide 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 AX 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 AX device is not aware of the HA state (Active or Standby) of the AX device. Consequently, following HA failover of an AX device, other OSPF routers might continue forwarding traffic to the Standby AX device (the former Active AX device), instead of the new Active AX device. Note:

In Layer 3 inline mode, all VLANs on the AX device participate in OSPF routing by default. (See “OSPF Support on Standby AX in Layer 3 Inline Mode” on page 280.) You can assign an additional cost to an AX 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 AX 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 AX device. Similarly, if a failover results in HA status Active for all HA groups on an AX 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 AX device and away from paths that use the Standby AX device. Note:

The additional cost for Standby status is removed only if the HA status for all HA groups on the device is Active. Otherwise, if the status of any of the groups is Standby, the additional cost remains in effect for all OSPF interfaces on the device.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

279 of 486

AX Series - System Configuration and Administration Guide Manually Synchronizing Configuration Information 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 AX 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 AX devices in the HA pair.

OSPF Support on Standby AX in Layer 3 Inline Mode In HA Layer 3 inline mode deployments, OSPF adjacencies are automatically formed between the Active and Standby AX 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

Manually Synchronizing Configuration Information Note:

This section describes how to manually synchronize the configuration. You can use the AX Virtual Chassis System (aVCS) to automate configuration synchronization. See “Configuration Synchronization without Reload” on page 289. You can use config-sync options to manually synchronize some or all of the following: • Startup-config, to the other AX device’s startup-config or running-con-

fig • Running-config, to the other AX device’s running-config or startup-con-

fig)

280 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Manually Synchronizing Configuration Information • 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 AX device is running aVCS. Requirements Session synchronization (connection mirroring) is required for manual config sync. Config sync uses the session synchronization link. To enable session synchronization, see “Enabling Session Synchronization” on page 277. SSH management access must be enabled on both ends of the link. (See “Securing Admin Access by Ethernet” on page 333.) The link must be on a data interface, not on the management interface.

Configuration Items That Are Backed Up The following configuration items are backed up during HA configuration synchronization: • Admin accounts and settings • AAA settings • DDoS protection settings • ICMP rate limiting • Floating IP addresses • IP NAT configuration, including LSN and DS-Lite • ACLs • Health monitors • IP limiting settings • PBSLB settings • SLB • RAM caching • DNS security and caching • FWLB

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

281 of 486

AX Series - System Configuration and Administration Guide Manually Synchronizing Configuration Information • GSLB • Data Files: • aFleX files • External health check files • SSL certificates, private-key files, and CRLs • Class-list files • Black/white-list files

Note:

For IP NAT configuration items to be backed up, you must specify an HA group ID as part of the NAT configuration.

Configuration Items That Are Not Backed Up The following configuration items are not backed up during HA configuration synchronization: • Interface-specific management access settings (the ones described in

“Securing Admin Access by Ethernet” on page 333) • AX Hostname • MAC addresses • Management IP addresses • Static Trunks or VLANs • LACP settings • Interface settings • OSPF or IS-IS settings • ARP entries or settings

Reload of the Target AX Device In certain cases, the target AX device is automatically reloaded, but in other cases, reload is either optional or is not allowed. Table 13 lists the cases in which reload is automatic, optional, or not allowed.

282 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Manually Synchronizing Configuration Information TABLE 13 Reload of Target AX Device After Config-Sync Admin Role Root or Super User (Read-Write)

Status of Target AX* Standby Active

Partition Write

Standby Active

Target Config startup-config running-config startup-config running-config startup-config running-config startup-config running-config

Reload? Automatic Automatic Optional† Not reloaded by default Automatic Not Allowed Not Allowed Not Allowed Not Allowed

*. “Active” means the AX device is currently the active device for at least one HA group. †. If the target AX device is not reloaded, the GUI Save button on the Standby AX device does not blink to indicate unsaved changes. It is recommended to save the configuration if required to keep the running-config before the next reboot.

An admin who is logged on with Root or Read-Write (Super Admin) privileges can synchronize for all Role-Based Administration (RBA) partitions or for a specific partition. An admin who is logged on with Partition Write privileges can synchronize only for the partition to which the admin is assigned, and can only synchronize to the startup-config on the other device. The with-reload and to-running-config options are not available to Partition Write admins. Caveats Before synchronizing the Active and Standby AX devices, verify that both are running the same software version. HA configuration synchronization between two different software versions is not recommended, since some configuration commands in the newer version might not be supported in the older version. The HA configuration synchronization process does not check user privileges on the Standby AX device and will synchronize to it using read-only privileges. However, you must be logged onto the Active AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

283 of 486

AX Series - System Configuration and Administration Guide Manually Synchronizing Configuration Information Do not make other configuration changes to the Active or Standby AX device during synchronization. Data that is synchronized from a Standby AX device to an Active AX device is not available on the Active AX device until that device is rebooted or the software is reloaded.

Performing HA Synchronization To synchronize the AX devices in an HA configuration, use the CLI commands described below.

USING THE GUI 1. Select Config > HA > Config Sync. 2. In the User and Password fields, enter the admin username and password for logging onto the other AX device. 3. If Role-Based Administration (RBA) is configured on the AX device, select whether to synchronize all partitions or only the currently selected partition. (For information, see “Synchronizing the Configuration” on page 181.) 4. Next to Operation, select the information to be copied to the other AX device: • All – Copies all the following to the other AX device: • Floating IP addresses • IP NAT configuration • Access control lists (ACLs) • Health monitors • Policy-based SLB (black/white lists) • SLB • FWLB • GSLB • Data files (see below) The items listed above that appear in the configuration file are copied to the other AX device’s running-config. • Data Files – Copies only the SSL certificates and private-key files, aFleX files, External health check files, and black/white-list files to the other AX device

284 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Manually Synchronizing Configuration Information • Running-config – Copies everything listed for the All option, except

the data files, from this AX device’s running-config • Startup-config – Copies everything listed for the All option, except the data files, from this AX 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 AX device’s running-config • To Startup-config – Copies the items selected in step 4 to the other AX device’s startup-config 6. To reload the other AX device after synchronization, select With Reload. Otherwise, the other AX device is not reloaded following the synchronization. Note:

In some cases, reload of the other AX device either is automatic or is not allowed. See Table 13 on page 283. 7. In the Destination IP field, enter the IP address of the other AX device. 8. Click OK.

USING THE CLI The ha sync commands are available at the global configuration level of the CLI. Note:

The all-partitions and partition partition-name options are applicable on AX devices that are configured for Role-Based Administration (RBA). For information, see “Role-Based Administration with Layer 2/3 Virtualization” on page 155. To synchronize data files and the running-config, use the following command: ha sync all {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ipaddr

Note:

The ipaddr option specifies the IP address of the other AX device. In some cases, reload of the other AX device either is automatic or is not allowed. See Table 13 on page 283. To synchronize the Active AX device’s startup-config to the Standby AX device’s startup-config or running-config, without also synchronizing the data files, use the following command:

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

285 of 486

AX Series - System Configuration and Administration Guide Tip for Ensuring Fast HA Failover ha sync startup-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ipaddr To synchronize the Active AX device’s running-config to the Standby AX device’s running-config or startup-config, without also synchronizing the data files, use the following command: ha sync running-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ipaddr To synchronize the data files by copying the Active AX device’s data files to the Standby AX device, use the following command: ha sync data-files [all-partitions | partition partition-name] ipaddr

Tip for Ensuring Fast HA Failover 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 AX device • How fast the MAC tables in the devices along the traffic paths are

updated To help reconvergence occur faster, you can create a real server configuration for each router, and use an ICMP health monitor for checking the health of the gateways. The health checks keep the ARP entries for the gateway routers active, which can help to reduce reconvergence time considerably. In a typical SLB configuration that includes a client-side router and a server-side router, configure a real server for each router.

286 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Tip for Ensuring Fast HA Failover 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 AX devices in the HA pair. Note:

The AX device also has an HA gateway health checking feature. This feature also uses ICMP health monitors. However, if you use the HA gateway health checking feature, HA failover is triggered if a gateway fails a health check. If you use real server configurations instead, as shown in the following examples, HA failover is not triggered by a failed health check. CLI Example – IPv4

AX(config)#health monitor gatewayhm1 AX(config-health:monitor)#method icmp interval 1 timeout 1 AX(config-health:monitor)#exit AX(config)#slb server gateway-upstream 192.168.10.1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit AX(config)#slb server gateway-downstream 10.10.10.1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit

To use the default ICMP health monitor instead, the configuration is even simpler: AX(config)#slb server gateway-upstream 192.168.10.1 AX(config-real server)#exit AX(config)#slb server gateway-downstream 10.10.10.1 AX(config-real server)#exit

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

287 of 486

AX Series - System Configuration and Administration Guide Tip for Ensuring Fast HA Failover CLI Example – IPv6 AX(config)#health monitor gatewayhm1 AX(config-health:monitor)#method icmp interval 1 timeout 1 AX(config-health:monitor)#exit AX(config)#slb server up-router 2309:e90::1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit AX(config)#slb server down-router 2309:e90::3 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit

To use the default ICMP health monitor: AX(config)#slb server up-router 2309:e90::1 AX(config-real server)#exit AX(config)#slb server down-router 2309:e90::3 AX(config-real server)#exit

288 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide

Configuration Synchronization without Reload You can use the AX Series 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 AX device(s) as soon as the change occurs. • Reload is not required.

Note:

VRRP-A does not use manual configuration synchronization. Instead, VRRP-A uses aVCS for automatic configuration synchronization.

Note:

The solution described in this chapter is supported only for two-device HA deployments. Figure 72 shows an example HA deployment that uses aVCS for automated configuration synchronization. FIGURE 72

aVCS Used for Automated Configuration Synchronization

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

289 of 486

AX Series - System Configuration and Administration Guide

VRRP-A with aVCS Deployment Example The following commands deploy the HA configuration shown in Figure 72. This example uses VRRP-A. If you plan to use the older implementation instead, see “HA with aVCS Deployment Example” on page 291. Commands on Device 1 To begin, the following command enables aVCS: AX-1#vcs enable

The following commands configure the high availability set ID and device ID: AX-1#configure AX-1(config)#vrrp-a set-id 1 AX-1(config)#vrrp-a device-id 1

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 AX device’s management IP address or one of the device’s data interface IP addresses. AX-1(config)#vcs floating-ip 192.168.209.23 /24

The following commands configure the aVCS profile for the device. AX-1(config)#vcs device 1 AX-1(config-vcs-dev)#priority 110 AX-1(config-vcs-dev)#interfaces management AX-1(config-vcs-dev)#interfaces ethernet 1 AX-1(config-vcs-dev)#enable AX-1(config-vcs-dev)#exit

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

290 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Commands on Device 2 AX-2#vcs enable AX-2#configure AX-2(config)#vrrp-a set-id 1 AX-2(config)#vrrp-a device-id 2 AX-2(config)#vcs floating-ip 192.168.209.23 /24 AX-2(config)#vcs device 2 AX-2(config-vcs-dev)#priority 100 AX-2(config-vcs-dev)#interfaces management AX-2(config-vcs-dev)#interfaces ethernet 1 AX-2(config-vcs-dev)#enable AX-2(config-vcs-dev)#exit AX-2(config)#write memory AX-2(config)#vcs reload

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. Commands on Device 1 AX-1#vcs enable AX-1#configure AX-1(config)#ha id 1 set-id 1 AX-1(config)#vcs floating-ip 192.168.209.23 /24 AX-1(config)#vcs device 1 AX-1(config-vcs-dev)#priority 110 AX-1(config-vcs-dev)#interfaces management AX-1(config-vcs-dev)#interfaces ethernet 1 AX-1(config-vcs-dev)#enable AX-1(config-vcs-dev)#exit AX-1(config)#write memory AX-1(config)#vcs reload

Commands on Device 2 AX-2#vcs enable AX-2#configure AX-2(config)#ha id 2 set-id 1 AX-2(config)#vcs floating-ip 192.168.209.23 /24 AX-2(config)#vcs device 2 AX-2(config-vcs-dev)#priority 100

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

291 of 486

AX Series - System Configuration and Administration Guide AX-2(config-vcs-dev)#interfaces management AX-2(config-vcs-dev)#interfaces ethernet 1 AX-2(config-vcs-dev)#enable AX-2(config-vcs-dev)#exit AX-2(config)#write memory AX-2(config)#vcs reload

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 152.

292 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

Network Address Translation This chapter describes Network Address Translation (NAT) and how to configure it. NAT translates the source or destination IP address of a packet before forwarding the packet. Note:

This chapter does not include information about NAT features for Server Load Balancing (SLB) or for IPv6 migration.

Overview The AX 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 AX device then retranslates addresses back into internal addresses before sending the reply to the client. You can configure dynamic or static IP source NAT: • Dynamic source IP NAT – Internal addresses are dynamically translated

into external addresses from a pool. • Static source IP NAT – Internal addresses are explicitly mapped to

external addresses. Configuration Elements for Dynamic NAT Dynamic NAT uses the following configuration elements: • Access Control List (ACL) – to identify the inside host addresses to be

translated • Pool – to identify a contiguous range of external addresses into which to

translate inside addresses • Optionally, pool group – to use non-contiguous address ranges. To use a

non-contiguous range of addresses, you can configure separate pools, then combine them in a pool group and map the ACL to the pool group. 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

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

293 of 486

AX Series - System Configuration and Administration Guide Overview same HA ID. A pool can be a member of multiple pool groups. Up to 50 NAT pool groups are supported. If a pool group contains pools in different subnets, the AX device selects the pool that matches the outbound subnet. For example, if there are two routes to a given destination, in different subnets, and the pool group has a pool for one of those subnets, the AX selects the pool that is in the subnet for the outbound route. The AX 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 AX 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 AX device enables you to specify the default gateway for an IP source NAT pool to use. However, the pool’s default gateway can be used only if the data route table already has either a default route or a direct route to the destination of the NAT traffic. In this case, the pool’s default gateway will override the route, for NAT traffic that uses the pool. If the data route table does not have a default route or a direct route to the NAT traffic destination, the pool’s default gateway can not be used. In this case, the NAT traffic can not reach its destination. Configuration Elements for Static NAT Static NAT uses the following configuration elements: • Static mappings or an address range list – A static mapping is a one-to-

one mapping of an inside address to an external address. An address range list is a contiguous range of inside addresses and external addresses to translate them into. • Inside NAT setting on the interface connected to the inside host. • Outside NAT setting on the interface connected to the Internet. Inside

host addresses are translated into external addresses from a static mapping or a range list before the host traffic is sent to the Internet.

294 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Dynamic IP Source NAT

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 noncontiguous 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 AX 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 > 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 > Service > 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

295 of 486

AX Series - System Configuration and Administration Guide Configuring Dynamic IP Source NAT f. Enter the network mask. g. If the AX 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 > Service > 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 > Service > 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.

296 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Dynamic IP Source NAT FIGURE 73

Configure > Network > ACL > Standard ACL

FIGURE 74

Configure > Service > IP Source NAT > IPv4 Pool

FIGURE 75

Configure > Service > IP Source NAT > Binding

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

297 of 486

AX Series - System Configuration and Administration Guide Configuring Dynamic IP Source NAT FIGURE 76

Configure > Service > 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

298 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Dynamic IP Source NAT access-list acl-num {permit | deny} {tcp | udp} {any | host host-src-ipaddr | net-src-ipaddr {filter-mask | /mask-length}} [eq src-port | gt src-port | lt src-port | range start-src-port end-src-port] {any | host host-dst-ipaddr | net-dst-ipaddr {filter-mask | /mask-length}} [eq dst-port | gt dst-port | lt dst-port | range start-dst-port end-dst-port] 2. To configure a pool of external addresses to use for translation, use one of the following commands at the global configuration level of the CLI. To configure an IPv4 pool: ip nat pool pool-name start-ipaddr end-ipaddr netmask {subnet-mask | /mask-length} [gateway ipaddr] [ha-group-id group-id [ha-use-all-ports]] Note:

The ha-use-all-ports option applies only to DNS virtual ports. Using this option with other virtual port types is not valid. (For information about this option, see the AX Series CLI Reference.)

To configure an IPv6 pool: ipv6 nat pool pool-name start-ipv6-addr end-ipv6-addr netmask mask-length [gateway ipaddr] [ha-group-id group-id]

To configure a pool group: ip nat pool-group pool-group-name {pool-name ...} 3. To enable inside source NAT and map the ACL to the pool, use the following command: ip nat inside source list acl-name pool {pool-name | pool-group-name}

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

299 of 486

AX Series - System Configuration and Administration Guide Configuring Dynamic IP Source NAT 4. To enable inside NAT on the interfaces connected to the inside hosts, use the following commands: interface [ethernet port-num | ve ve-num] ip nat inside The interface command changes the CLI to the configuration level for the interface connected to the internal hosts. These are the hosts 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: interface [ethernet port-num | ve ve-num] 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. AX(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: AX(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: AX(config)#ip nat inside source list 1 pool pool1

The following commands enable inside source NAT on the interface connected to the internal hosts: AX(config)#interface ethernet 4 AX(config-if:ethernet4)#ip nat inside

The following commands enable source NAT on the interface connected to the external hosts: AX(config-if:ethernet4)#interface ethernet 6 AX(config-if:ethernet6)#ip nat outside

300 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Static IP Source NAT

Configuring Static IP Source NAT You can configure individual static source NAT mappings or configure a range of static mappings. After configuring the static source NAT mappings, do the following: • Enable inside NAT on the interfaces connected to the inside hosts. • Enable outside NAT on the interfaces connected to the Internet.

Limitations for Static NAT Mappings • Application Layer Gateway (ALG) services other than FTP are not sup-

ported when the server is on the inside. • HA session synchronization is not supported. However, sessions will

not be interrupted by HA failovers. • Syn-cookies are not supported.

USING THE GUI Note:

The GUI supports configuring a static NAT range but does not support configuring individual mappings. 1. To configure the static translations of internal host addresses to external addresses: a. Select NAT Range on the menu bar. b. Click Add. c. Enter a name for the range. d. Select the address type (IPv4 or IPv6) e. In the From fields, enter the first (lowest numbered) address and network mask in the range of inside host addresses to be translated. f. In the To field, enter the first (lowest numbered) address and 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

301 of 486

AX Series - System Configuration and Administration Guide Configuring Static IP Source NAT 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 natipaddr is the address into which the AX device will translate the sourceipaddr before forwarding the requests. Similarly, for inbound static NAT, the following syntax is supported: [no] ip nat inside source static destinationipaddr nat-ipaddr The destination-ipaddr is the internal host to which external hosts send requests. The nat-ipaddr is the address into which the AX 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]

302 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Static IP Source NAT The source-ipaddr specifies the starting address in the range of internal host addresses. The nat-ipaddr command specifies the first address in the range of external addresses to use for the translations. The count option specifies how many mappings to create. 2. If you used the ip nat inside source command, enter the following command at the global configuration level of the CLI, to enable static NAT support: ip nat allow-static-host Note:

This step is not required if you use a static source NAT range list instead. 3. To enable inside NAT on the interfaces connected to the inside hosts, use the following commands: interface [ethernet port-num | ve ve-num] ip nat inside The interface command changes the CLI to the configuration level for the interface connected to the internal hosts. 4. To enable outside NAT on the interfaces connected to the Internet, use the following commands: interface [ethernet port-num | ve ve-num] 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. AX(config)#ip nat range-list nat-list-1 10.10.10.97 /16 192.168.22.50 /16 count 100 AX(config)#interface ethernet 2 AX(config-if:ethernet2)#ip nat inside AX(config-if:ethernet2)#exit AX(config)#interface ethernet 4 AX(config-if:ethernet4)#ip nat outside

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

303 of 486

AX Series - System Configuration and Administration Guide NAT ALG Support for PPTP

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-toPoint (PPP) traffic through the AX device over a Generic Routing Encapsulation (GRE) tunnel. PPTP is used to connect Microsoft Virtual Private Network (VPN) clients and VPN hosts. Figure 77 shows an example. FIGURE 77

NAT ALG for PPTP

The AX device is deployed between PPTP clients and the VPN server (VPN Server using PPTP). The AX interface connected to the PPTP clients is enabled for inside source NAT. The AX interface connected to the VPN server is enabled for outside source NAT. Each client runs a PPTP Network Server (PNS). To set up a VPN session, the PNS sends an Outgoing-Call-Request to the PPTP Access Concentrator (PAC), which is the VPN server. The destination TCP port is the PPTP port (1723 by default). The request includes a Call ID that the PNS chooses. Because multiple clients may share the same NAT address, the AX device must ensure that clients do not share the same Call ID as well. Therefore, the AX 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 AX device does not change the

304 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide NAT ALG Support for PPTP PAC’s Call ID. The PAC then assigns to the client an IP address belonging to the VPN subnet. On the AX 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 307.) In Figure 77 on page 304, 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 AX device will translate the Call ID into a unique Call ID for NAT. Once the VPN server replies with its own Call ID, the AX 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 AX device translates the NAT Call ID back into the client’s original Call ID before sending the packet to the client. Note:

One GRE session is supported per control session, which means one call at a time is supported. In practice, PPTP is used only for VPNs, in which case multiple concurrent calls do not occur.

Configuring NAT ALG for PPTP To configure an AX 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 AX interface connected to the VPN clients. • Enable outside IP source NAT on the AX interface connected to the VPN server. • If NAT ALG support for PPTP is disabled, enable it. (The feature is

enabled by default.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

305 of 486

AX Series - System Configuration and Administration Guide NAT ALG Support for PPTP 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} [gateway ipaddr] [ha-group-id group-id] 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.

306 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide NAT ALG Support for PPTP 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 77 on page 304. The following commands configure dynamic inside source NAT. AX(config)#access-list 1 permit 10.1.1.0 0.0.0.255 AX(config)#ip nat pool pptp-pool 192.168.1.100 192.168.1.110 netmask /24 AX(config)#ip nat inside source list 1 pool pptp-pool

The following commands specify the inside NAT interface and the outside NAT interface. AX(config)#interface ethernet 1 AX(config-if:ethernet1)#ip address 10.2.2.254 255.255.255.0 AX(config-if:ethernet1)#ip nat inside AX(config-if:ethernet1)#interface ethernet 2 AX(config-if:ethernet2)#ip address 10.3.3.254 255.255.255.0 AX(config-if:ethernet2)#ip nat outside

The following command displays session information: AX(config-if:ethernet2)#show session Prot Forward Source Age Hash

Forward Dest

Reverse Source

Reverse Dest

---------------------------------------------------------------------------------------------------------Gre 10.1.1.1:49152 240 1

10.3.3.2:32799

10.3.3.2:32799

192.168.1.100:2109

Tcp 10.1.1.1:2301 240 2

10.3.3.2:1723

10.3.3.2:1723

192.168.1.100:2109

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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

307 of 486

AX Series - System Configuration and Administration Guide Mapping Allocation Method The following command displays PPTP NAT ALG statistics. AX(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

Mapping Allocation Method By default, the AX 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. 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.

308 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Fast Aging for IP NATted ICMP and DNS Sessions

Fast Aging for IP NATted ICMP and DNS Sessions The AX device uses application-aware aging for IP NATted sessions, in cases where the AX 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 AX 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 AX device. For SLB DNS traffic, short aging based on the MSL time is the default aging mechanism. Table 14 summarizes the session timeouts and how to configure them.

TABLE 14 Session Timeout for IP NATted ICMP and UDP Sessions Default Timeout for IP NATted ICMP DNS Sessions SLB MSL timeout (2 seconds by default) Note: For DNS, this is the default only for the default DNS port (53).

Method To Change Timeout You can use either of the following methods: • Change the SLB MSL timeout. • 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”. • 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.

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: [no] ip nat translation icmp-timeout {seconds | fast}

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

309 of 486

AX Series - System Configuration and Administration Guide Client and Server TCP Resets for NATted TCP Sessions 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. CLI Example The following command displays the current IP NAT translation timeouts: AX#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 AX device does not send TCP Resets to the client and server when a NATted TCP session becomes idle. To enable this option, use the following command at the global configuration level of the CLI: ip nat reset-idle-tcp-conn

310 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide 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 11800 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 “Network Address Translation for SLB” chapter in the AX Series Application Delivery and Server Load Balancing Guide.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

311 of 486

AX Series - System Configuration and Administration Guide IP NAT Use in Transparent Mode in Multi-Netted Environment

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 CLI Example The following commands configure custom MSL values for system-level source NAT: AX(config)#access-list 123 permit tcp host 192.168.20.102 any eq 22 AX(config)#access-list 124 permit tcp host 192.168.20.102 any eq 80 AX(config)#ip nat pool ronpool 192.168.20.105 192.168.20.105 netmask /24 AX(config)#ip nat inside source list 123 pool ronpool msl 23 AX(config)#ip nat inside source list 124 pool ronpool msl 48

IP NAT Use in Transparent Mode in Multi-Netted Environment If the AX device is deployed in transparent mode, the device uses NAT IP addresses to perform health monitoring on servers that are outside the IP subnet or VLAN of the AX device. If there are multiple IP addresses in the NAT pool, the AX device uses only the last IP address in the pool for the health checks. Also, the AX 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 AX 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.

312 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide NAT Range List Requires AX Interface or Route Within the Global Subnet AX#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

AX#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 AX device will initiate health checks using the last IP address in the pool as the source IP address. In this example, the AX device will use IP address 173.168.10.25. In addition, the AX 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 AX 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 AX device. This can occur under the following circumstances: • IP source NAT is configured using a NAT range list. • The AX 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 AX device. This issue does not affect NATted traffic other than ICMP or UDP traffic, or use of an ACL with a NAT pool.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

313 of 486

AX Series - System Configuration and Administration Guide IP NAT in HA Configurations

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 AX 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 > Service > IP Source NAT > IPv4 Pool • Config > Service > IP Source NAT > IPv6 Pool • Config > Service > 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 [gateway ipaddr] [ha-group-id group-id] [no] ip nat range-list list-name source-ipaddr /mask-length nat-ipaddr count number [ha-group-id group-id]

314 of 486

/mask-length

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Dynamic IP NAT with Many Pools

Configuring Dynamic IP NAT with Many Pools The AX 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.

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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

315 of 486

AX Series - System Configuration and Administration Guide Configuring Dynamic IP NAT with Many Pools

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 AX 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 AX 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 AX device. The url specifies the file transfer protocol, username (if required), and directory path. You can enter the entire URL on the command line or press Enter to display a prompt for each part of the URL. If you enter the entire URL and a 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

316 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Dynamic IP NAT with Many Pools

Configuring a Class List Using the CLI To configure a class list in the CLI, use the following commands: [no] class-list name [file] Enter this command at the global configuration level of the CLI. The file option saves the class list as a separate file. Without this option, the class list is instead saved in the startup-config. The file option is valid only when you create the class list. After you create the list, the list remains either in the startup-config or in a separate file, depending on whether you use the file option when you create the list. Note:

If the class list contains 100 or more entries, as is likely with this feature, it is recommended to use the file option. A class list can be exported from the AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

317 of 486

AX Series - System Configuration and Administration Guide Configuring Dynamic IP NAT with Many Pools

Configuration Example The commands in this example configure dynamic NAT with more than 100 pools. Class List This example uses the following class list: 10.10.10.1 /32 glid 1 10.10.10.2 /32 glid 2 10.10.10.3 /32 glid 3 10.10.10.4 /32 glid 4 10.10.10.5 /32 glid 5 10.10.10.6 /32 glid 6 ... 10.10.10.254 /32 glid 254

For brevity, this example and the CLI example do not show LIDs or pools 7-253. This example uses mask length /32 for each entry, which uses a separate LID (and therefore, a separate pool) for each individual host. The entries are not required to be for individual hosts. For example, the following entry assigns all hosts in subnet 10.10.20.x to LID 10: 10.10.10.0 /24 glid 10

AX Configuration Commands The following commands configure the NAT pools: AX(config)#ip nat pool p1 192.168.217.201 192.168.217.201 netmask /24 AX(config)#ip nat pool p2 192.168.217.202 192.168.217.202 netmask /24 AX(config)#ip nat pool p3 192.168.217.203 192.168.217.203 netmask /24 AX(config)#ip nat pool p4 192.168.217.204 192.168.217.204 netmask /24 AX(config)#ip nat pool p5 192.168.217.205 192.168.217.205 netmask /24 AX(config)#ip nat pool p6 192.168.217.206 192.168.217.206 netmask /24 ... AX(config)#ip nat pool p254 192.168.217.254 192.168.217.254 netmask /24

318 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Dynamic IP NAT with Many Pools The following commands configure the LIDs: AX(config)#lid 1 AX(config-global lid)#use-nat-pool p1 AX(config-global lid)#lid 2 AX(config-global lid)#use-nat-pool p2 AX(config-global lid)#lid 3 AX(config-global lid)#use-nat-pool p3 AX(config-global lid)#lid 4 AX(config-global lid)#use-nat-pool p4 AX(config-global lid)#lid 5 AX(config-global lid)#use-nat-pool p5 AX(config-global lid)#lid 6 AX(config-global lid)#use-nat-pool p6 ... AX(config-global lid)#lid 254 AX(config-global lid)#use-nat-pool p254 AX(config-global lid)#exit

The following command imports the class list: AX(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: AX(config)#ip nat inside source class-list revnat

The following commands enable inside NAT on the interface connected to the internal clients: AX(config)#interface ethernet 1 AX(config-if:ethernet1)#ip nat inside

The following commands enable outside NAT on the interface connected to the Internet: AX(config)#interface ethernet 2 AX(config-if:ethernet2)#ip nat outside AX(config-if:ethernet2)#exit

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

319 of 486

AX Series - System Configuration and Administration Guide Configuring Dynamic IP NAT with Many Pools

320 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide

Management Security Features In addition to basic security provided by login and enable passwords, AX Series devices support the following advanced management access security features: • Multiple admin accounts with distinct levels of access – see “Configur-

ing Additional Admin Accounts” on page 322 • Admin account lockout in response to excessive invalid passwords – see

“Configuring Admin Lockout” on page 330 • Admin access control based on management interface (GUI, CLI, or

aXAPI) – see “Admin Access Control Based on Management Interface” on page 332 • Interface-level access control for individual management access types

(Telnet, SSH, and so on) – see “Securing Admin Access by Ethernet” on page 333 • Public key authentication for SSH management access – see “SSH Pub-

lic Key Authentication for SSH Management Access” on page 337 • Web access features for securing access through the GUI – see “Chang-

ing Web Access Settings” on page 340 • Command auditing – see “Command Auditing” on page 342 • Authentication, Authorization, and Accounting (AAA) for remotely

managed access security – see “Configuring AAA for Admin Access” on page 344 The following sections describe these features and show how to configure them. Note:

If you have not already changed the default “admin” password and the enable password, A10 Networks recommends that you do so now, before implementing security options described in this chapter.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

321 of 486

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts

Configuring Additional Admin Accounts The AX device comes with one admin account, “admin”, by default. The “admin” account has global Read Write privileges. The admin account, and other admin accounts with global Read Write privileges, can configure additional admin accounts. For each admin account, the following settings can be configured: • Username and password • IP host or subnet address from which the admin is allowed to log on • Management interfaces the admin is allowed to use (CLI, GUI, or

aXAPI) • GUI access Role (read-write privileges for GUI page access) • Role-Based Administration (RBA) partition, if applicable • Account state (enabled or disabled)

Note:

If you are configuring an admin account for a private partition, also see “Configuring Role-Based Administration” on page 167.

Configuring an Admin Account To configure an admin account, use either of the following methods.

USING THE GUI 1. Select Config > 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.

322 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts Note:

To allow access from any host, leave the Trusted Host IP Address and Netmask fields blank. 6. Select the role from the Role drop-down list. The role defines the read or write access allowed to the admin for each GUI page. (See “GUI Access Roles” on page 324.) 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 Role-Based Administration (RBA) partition, select the partition from the Partition drop-down list. 9. Leave the Status enabled. 10. Click OK. The new admin appears in the Admin table.

Note:

For information about the SSH Key File section, see “SSH Public Key Authentication for SSH Management Access” on page 337. FIGURE 78

Config > Admin > Admin

FIGURE 79

Config > Admin - new admin added

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

323 of 486

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts

GUI Access Roles Admin roles enable you to restrict the GUI options an admin is authorized to use. For each GUI page, the admin role specifies whether the admin is allowed to access (view) the page. If the admin is allowed to access the page, the role specifies whether the admin has read-only or read-write privileges for the page. You can assign an admin to a preconfigured role or a custom role that you configure. You also can customize the preconfigured roles. Table 15 on page 325 lists the preconfigured roles and the types of GUI page access allowed by each one. Table Column Descriptions In the Role and Access column, the numbers indicate the roles. Note:

If you configure GUI-based access in RADIUS or TACACS+, these are the numbers to use when specifying a preconfigured role. • 1 – ReadOnlyAdmin • 2 – ReadWriteAdmin • 3 – SystemAdmin • 4 – NetworkAdmin • 5 – NetworkOperator • 6 – SlbServiceAdmin • 7 – SlbServiceOperator • 8 – PartitionReadWrite • 9 – PartitionNetworkOperator • 10 – PartitionSlbServiceAdmin • 11 – PartitionSlbServiceOperator • 12 – PartitionReadOnly

The following letters indicate the access privileges for the GUI page: • R – Read-only • W – Read-write • H – Hidden (page can not be viewed by the admin)

324 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts .

TABLE 15 Preconfigured GUI Access Roles Role and Access GUI Page*

1

2

3

4

5

6

7

8

9

1 0

1 1

1 2

R H H H H H H H H H H H R R R R R R H H H H H

R H H H H H H H H H H H R R R R R R H H H H H

R R R R R R R R R R R R H H H H H H H H H R R

R R R R R R R R R R R R H H H H H H H H H R R

R R R R R H H H H R H R R R R R R R H H H H H

R H H H H H H H H H H H R R R R R R H H H H H

R R R R R H H H H R H R H H H H H H H H H H H

R R R R R H H H H R H R H H H H H H H H H H H

R R R R R H H H H R H R R R R R R R H H H H H

Monitor Pages Monitor > Overview > Summary Monitor > Overview > Status Monitor > Overview > Statistics Monitor > Overview > Performance Monitor > Service > SLB Monitor > Service > Health Monitor Monitor > Service > Firewall Monitor > Service > PBSLB Monitor > Service > GSLB Monitor > Service > aFleX Monitor > Service > IP Source NAT Monitor > Service > Application Monitor > Network > Interface Monitor > Network > Trunk Monitor > Network > VLAN Monitor > Network > ACL Monitor > Network > ARP Monitor > Network > Route Monitor > System > Admin Monitor > System > Logging Monitor > System > VCS Monitor > HA > Group Monitor > HA > Status

R R R R R R R R R R R R R R R R R R R R R R R

R R R R R R R R R R R R R R R R R R R R R R R

R H H H H H H H H H H H H H H H H H R R R H H

Config Pages Config > Get Started > Basic System Config > Get Started > Smart Template Config > Get Started > GSLB Easy Config Config > Service > SLB Config > Service > Template Config > Service > Health Monitor Config > Service > PBSLB Config > Service > Firewall Config > Service > GSLB Config > Service > aFleX Config > Service > IP Source NAT† Config > Service > SSL Management Config > Network >

Interface†

R R R R R R R R R R R

W W W W W W W W W W W

H H H H H H H H H H H

W H H H H H H H H H H

R H H H H H H H H H H

H W W W W W W W W W W

H R R R R R R R R R R

H W H W W W H H H W W

H H H H H H H H H H H

H W H W W W H H H W W

H R H R R R H H H R R

H R H R R R H H H R R

R R

W W

H H

H W

H R

W H

R H

W W

H R

W H

R H

R R

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

325 of 486

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts TABLE 15 Preconfigured GUI Access Roles (Continued) Role and Access

Config > Network > Trunk†

1 R

2 W

3 H

4 W

5 R

6 H

7 H

8 W

9 H

1 0 H

1 1 H

1 2 H

Config > Network > VLAN†

GUI Page*

R

W

H

W

R

H

H

W

R

H

H

R



R

W

H

W

R

H

H

W

R

H

H

R

Config > Network > ARP†

R

W

H

W

R

H

H

W

R

H

H

R

Config > Network > Route†

R

W

H

W

R

H

H

W

R

H

H

R

Config > Network > DNS†

R

W

H

W

R

H

H

H

H

H

H

H

Config > Network > ICMP Rate Limiting†

R

W

H

W

R

H

H

H

H

H

H

H

Config > Network > BPDU-Fwd-Group† Config > System > Settings > Web Config > System > Settings > Web Certificate Config > System > Settings > Terminal Config > System > Settings > Log Config > System > Settings > General Config > System > Settings > Boot Config > System > Settings > Action Config > System > Admin Config > System > Access Control Config > System > Time Config > System > SNMP Config > System > Maintenance Config > System > Console Config > System > Config File Config > System > showtech File Config > System > VCS Config > HA > Setting Config > HA > Config Sync

R

W

H

W

R

H

H

H

H

H

H

H

R R R R R R R R R R R R R R R R R R

W W W W W W W W W W W W W W W W W W

W W W W W W W W W W W W W W W W H H

H H H W H H H H W W W H H H H H H H

H H H R H H H H R R R H H H H H H H

H H H H H H H H H H H H H H H H W W

H H H H H H H H H H H H H H H H R R

H H H H H H H H H H H H H H H H W W

H H H H H H H H H H H H H H H H H H

H H H H H H H H H H H H H H H H H H

H H H H H H H H H H H H H H H H H H

H H H H H H H H H H H H H H H H H H

Config > Network > ACL

*. In some cases where the same access privileges apply to all pages at a given GUI level, only the high-level page name is listed in this table. However, access is configurable on an individual page basis for all GUI pages.

†. For the partition roles (8-12), the access privileges shown in the table are for admins of partitions in which Layer 2/3 virtualization is enabled. If Layer 2/3 virtualization is disabled in the partition, this page is hidden.

326 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts

USING THE CLI 1. Log on through the CLI and access the global configuration level. 2. Enter the following command to create the new admin account: [no] admin admin-username This command changes the CLI to the configuration level for the new account. 3. Use the following commands to complete the configuration: password string trusted-host ipaddr {subnet-mask | /mask-length} access {cli | web | axapi} privilege priv-level [partition-name] The password command assigns the password, which can be 1-63 characters. The default is “a10”. The trusted-host command specifies the host or subnet from which the admin is allowed to log in. The default is 0.0.0.0 /0 (any host or subnet). The access command specifies the management interfaces the admin is allowed to access. By default, access is allowed to all interfaces (CLI, GUI, and aXAPI). The privilege command specifies the privileges granted to the admin account: • read – The admin can access the User EXEC and Privileged EXEC levels of the CLI only. This is the default. • write – The admin can access all levels of the CLI. • partition-read – The admin has read-only privileges within the private partition to which the admin is assigned, and read-only privileges for the shared partition. • partition-write – The admin has read-write privileges within the private partition to which the admin is assigned. The admin has read-only privileges for the shared partition. • partition-enable-disable – The admin has read-only privileges for real servers, with permission to view service port statistics and to disable or re-enable the servers and their service ports. No other read-only or read-write privileges are granted. The partition-name – specifies the name of the private partition to which the admin is assigned. This option applies only to admins that have privilege level partition-read, partition-write, or partition-enable-disable.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

327 of 486

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts Note:

For information about the ssh-pubkey command, see “SSH Public Key Authentication for SSH Management Access” on page 337.

Note:

To restrict write access to specific configuration areas, see “Configuring AAA for Admin Access” on page 344. 4. To verify the new admin account, enter the following command: show admin

CLI EXAMPLES The following commands add admin “adminuser2” with password “12345678” and read-write privilege: AX(config)#admin adminuser2 AX(config-admin:adminuser2)#password 12345678 AX(config-admin:adminuser2)#privilege write AX(config-admin:adminuser2)#show admin UserName

Status

Privilege Partition

------------------------------------------------------admin

Enabled

R/W

adminuser2

Enabled

R/W

The following commands add admin “adminuser3” with password “abcdefgh” and read-write privilege, and restrict login access to the 10.10.10.x subnet only: AX(config)#admin adminuser3 AX(config-admin:adminuser3)#password abcdefgh AX(config-admin:adminuser3)#privilege write AX(config-admin:adminuser3)#trusted-host 10.10.10.0 /24 AX(config-admin:adminuser3)#show admin UserName

Status

Privilege Partition

------------------------------------------------------admin

Enabled

R/W

adminuser2

Enabled

R/W

adminuser3

Enabled

R/W

328 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Additional Admin Accounts AX(config-admin:adminuser3)#show admin adminuser3 detail User Name ...... adminuser3 Status ...... Enabled Privilege ...... R/W Partition ...... Access type .....cli web axapi GUI role ...... Trusted Host(Netmask) ...... 10.10.10.0(255.255.255.0) Lock Status ...... No Lock Time ...... Unlock Time ...... Password Type ...... Encrypted Password ...... $1$6334ba07$CKbWL/LuSNdY12kcE.KdS0

Deleting an Admin Account An admin with Root privileges can delete other admin accounts. If you need to delete an admin account: 1. Display the admin session table to determine whether the admin has any active admin sessions. 2. Clear any sessions the admin has open. 3. Delete the admin account. Note:

To delete an admin account, you first must terminate any active sessions the admin account has open. The account is not deleted if there are any open sessions for the account.

USING THE GUI 1. To display the admin session table, select Monitor > System > Admin. 2. To clear an admin session, click on the checkbox next to the session to select it, then click Delete. 3. To delete the admin account: a. Select Config > System > Admin. b. Click on the checkbox next to the admin name. c. Click Delete.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

329 of 486

AX Series - System Configuration and Administration Guide Configuring Admin Lockout

USING THE CLI 1. To display the admin session table, use the following command at the Privileged EXEC level or any configuration level: show admin session 2. To clear an admin session, use the following command at the Privileged EXEC level or any configuration level: clear admin session session-id The session-id is the ID listed in the ID column of the show admin session output. 3. To delete the admin account, use the following command at the global configuration level: no admin admin-username

Configuring Admin Lockout By default, there is no limit to the number of times an incorrect password can be entered with an admin account to attempt access. You can enable the AX device to lock admin accounts for a specific period of time following a specific number of invalid passwords entered for the account. Table 16 lists the admin lockout parameters you can configure. TABLE 16 Admin Lockout Parameters Parameter Feature state Threshold Reset time

Duration

Description Controls whether admin accounts can be locked. Number of failed login attempts allowed for an admin account before it is locked. Number of minutes the AX device remembers a failed login attempt. For an account to be locked, greater than the number of failed login attempts specified by the threshold must occur within the reset time. Number of minutes a locked account remains locked. To keep accounts locked until you or another authorized administrator unlocks them, set the value to 0.

Default Disabled 5 10 minutes

10 minutes

To configure admin lockout, use either of the following methods.

330 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring Admin Lockout

USING THE GUI To enable the lockout feature: 1. Select Config > System > Admin. 2. Select Lockout Policy on the menu bar. 3. Select Enable Administrator lockout Feature. 4. Optionally, change lockout settings. (For descriptions, see Table 16 on page 330.) 5. Click OK. To view lockout status or manually unlock a locked account: 1. Select Monitor > System > Admin. 2. Select the admin account. 3. Click Unlock.

USING THE CLI 1. Log on through the CLI and access the global configuration level. 2. Optionally, enter the following commands to change lockout settings: admin lockout threshold number admin lockout duration minutes admin lockout reset-time minutes (For descriptions, see Table 16 on page 330.) 3. Use the following command to enable admin lockout: admin lockout enable To view lockout status or manually unlock a locked account: 1. Log on through the CLI and access the global configuration level. 2. Enter the following command to view the lockout status of an admin account: show admin admin-username detail

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

331 of 486

AX Series - System Configuration and Administration Guide Admin Access Control Based on Management Interface 3. Enter the following command to access the configuration level for the admin account: admin admin-username 4. Use the following command to unlock the account: unlock

Admin Access Control Based on Management Interface AX Release 2.6 enables you to specify the AX management interfaces individual admins are allowed to access. In this release, you can deny an admin from accessing the AX device through one or more of the following management interfaces: • CLI • GUI • aXAPI

By default, admins are allowed to use any of the management interfaces. To deny access through specific management interfaces, use either of the following methods.

USING THE GUI 1. Select Config > Settings > Admin > Administrator. 2. Click on the admin name or click Add to add a new one. 3. If configuring a new admin, enter the username and password. 4. Next to Access Type, select the interfaces the admin is allowed to access. 5. If configuring an RBA partition admin, select the partition from the Partition drop-down list. 6. Click OK. Note:

332 of 486

For information about the admin roles listed in the Role drop-down list, see “Admin Access Control Based on Management Interface” on page 332. For information about the SSH Key File option, see “SSH Public Key Authentication for SSH Management Access” on page 337.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Securing Admin Access by Ethernet

USING THE CLI To deny or permit an admin to access the AX device through a specific management interface, use the following command at the configuration level for the admin account: [no] access {cli | web | axapi} The following commands deny management access by admin “admin2” using the CLI or aXAPI: AX(config)#admin admin2 AX(config-admin:admin2)#no access cli AX(config-admin:admin2)#no access axapi

Securing Admin Access by Ethernet By default, certain types of management access through the AX device’s Ethernet interfaces are blocked. Table 17 lists the default settings for each management service. TABLE 17 Default Management Access Management Service SSH Telnet HTTP HTTPS SNMP Ping

Ethernet Management Interface Enabled Disabled Enabled Enabled Enabled Enabled

Ethernet and VE Data Interfaces Disabled Disabled Disabled Disabled Disabled Enabled

You can enable or disable management access, for individual access types and interfaces. You also can use an Access Control List (ACL) to permit or deny management access through the interface by specific hosts or subnets. To set management access through Ethernet interfaces, use either of the following methods. Notes Regarding Use of ACLs If you use an ACL to secure management access, the action in the ACL rule that matches the management traffic’s source address is used to permit or deny access, regardless of other management access settings.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

333 of 486

AX Series - System Configuration and Administration Guide Securing Admin Access by Ethernet For example, if you disable Telnet access to a data interface, but you also enable access to the interface using an ACL with permit rules, the ACL permits Telnet (and all other) access to the interface, for traffic that matches the permit rules in the ACL. If you want certain types of management access to be disabled on an interface, do not use a permit ACL to control management access to the interface. Each ACL has an implicit deny any any rule at the end. If the management traffic’s source address does not match a permit rule in the ACL, the implicit deny any any rule is used to deny access. On data interfaces, you can disable or enable access to specific services and also use an ACL to control access. However, on the management interface, you can disable or enable access to specific services or control access using an ACL, but you can not do both.

USING THE GUI To change management access settings for interfaces: 1. Select Config > System > Access Control. 2. For each interface (each row), select or de-select the checkboxes for the access types. 3. To use an ACL to control access, select the ACL from the ACL dropdown list in the row for the interface. 4. After selecting the settings for all the interfaces, click OK. To reset the access settings to the defaults listed in Table 17, click Reset to Default.

USING THE CLI Disabling Management Access To disable management access, use either of the following commands at the global configuration level of the CLI: disable-management service {all | ssh | telnet | http | https | snmp | ping} {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} or

334 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Securing Admin Access by Ethernet disable-management service acl acl-num {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} In both commands, the following options specify the interfaces to protect: • management – The out-of-band Ethernet management interface

(MGMT) • ve ve-num [to ve-num] – A VE data interface or range of VE data inter-

faces • ethernet port-num [to port-num] – An Ethernet data interface or range

of Ethernet data interfaces In the first command, the following options specify the type of management access you are configuring: • all – Disables access to all the management services listed below. • ssh – Disables SSH access to the CLI. • telnet – Disables Telnet access to the CLI. • http – Disables HTTP access to the management GUI. • https – Disables HTTPS access to the management GUI. • snmp – Disables SNMP access to the AX device’s SNMP agent. • ping – Disables ping replies from AX interfaces. This option does not

affect the AX device’s ability to ping other devices. Note:

Disabling ping replies from being sent by the AX device does not affect the device’s ability to ping other devices. In the second command, the acl acl-id option specifies an ACL. Management access from any host address that matches the ACL is either permitted or denied, depending on the action (permit or deny) used in the ACL. CLI Examples: The following command disables HTTP access to the out-of-band management interface:

AX(config)#disable-management service http management You may lose connection by disabling the http service. Continue? [yes/no]:yes

Enabling Management Access To enable management access, use either of the following commands at the global configuration level of the CLI:

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

335 of 486

AX Series - System Configuration and Administration Guide Securing Admin Access by Ethernet enable-management service {all | ssh | telnet | http | https | snmp | ping} {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} or enable-management service acl acl-num {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} The options are the same as those for the disable-management command. CLI Example: The following command enables Telnet access to data interface 6: AX(config)#enable-management service telnet ethernet 6

Displaying the Current Management Access Settings To display the management access settings that are currently in effect, enter the following command at any level of the CLI: show management

CLI EXAMPLES Here is an example for an AX device that has 10 Ethernet data ports. In this example, all the access settings are set to their default values. AX#show management PING

SSH

Telnet HTTP

HTTPS

SNMP

ACL

-----------------------------------------------------mgmt on

on

off

on

on

on

-

1

on

off

off

off

off

off

-

2

on

off

off

off

off

off

-

3

on

off

off

off

off

off

-

4

on

off

off

off

off

off

-

5

on

off

off

off

off

off

-

6

on

off

off

off

off

off

-

7

on

off

off

off

off

off

-

9

on

off

off

off

off

off

-

10

on

off

off

off

off

off

-

ve1

on

off

off

off

off

off

-

336 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide SSH Public Key Authentication for SSH Management Access Here is an example after entering the commands used in the configuration examples above. AX#show management PING

SSH

Telnet HTTP

HTTPS

SNMP

ACL

-----------------------------------------------------mgmt on

on

off

off

on

on

-

1

on

off

off

off

off

off

1

2

on

off

off

off

off

off

1

3

on

off

off

off

off

off

1

4

on

off

off

off

off

off

1

5

on

off

off

off

off

off

1

6

on

off

on

off

off

off

1

7

on

off

off

off

off

off

1

9

on

off

off

off

off

off

1

10

on

off

off

off

off

off

1

ve1

on

off

off

off

off

off

-

Regaining Access if You Accidentally Block All Access If you disable the type of access you are using on the interface you are using at the time you enter a disable-management command, your management session will end. If you accidentally lock yourself out of the device altogether (for example, if you use the all option for all interfaces), you can still access the CLI by connecting a PC to the AX device’s serial port.

SSH Public Key Authentication for SSH Management Access AX Release 2.6 provides an option to simplify AX management access through the CLI, with support for public key authentication. Public key authentication allows an AX admin to log in through SSH without entering a password. When the admin enters their username and presses Enter, the SSH client on the admin’s PC sends a signature file for the admin. The AX device compares the signature file to the admin’s public key stored on the AX device. If they match, the admin is granted access.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

337 of 486

AX Series - System Configuration and Administration Guide SSH Public Key Authentication for SSH Management Access To use public key authentication for management access to the AX device: 1. On the PC from which the admin will access the AX CLI, use the PC’s SSH client to generate an RSA key pair for the admin. The key pair consists of a public key and a private key. Do not use a passphrase. Note:

In the current release, only the OpenSSH client is supported. 2. Log into the AX device with root or global read-write privileges. 3. Access the configuration level for the admin account. 4. Import only the public key onto the AX device. (Do not import the private key onto the AX device.) You can import public keys in separate files or grouped together into a single file.

Note:

The “admin” account has root privileges and can manage the public certificates for all admins. Any other admin account can manage only the public key belonging to that admin account.

USING THE CLI To import an SSH public key onto the AX device, use the following command at the configuration level for the admin account: ssh-pubkey import url The url specifies the file transfer protocol, username (if required), and directory path for exporting the public key file. 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

338 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide SSH Public Key Authentication for SSH Management Access To delete an SSH public key from the AX device, use the following command: ssh-pubkey delete num The num option specifies the key number on the AX device. The key numbers are displayed along with the keys themselves by the ssh-pubkey list command. (See below.) To verify installation of a public key, use the following command: ssh-pubkey list CLI Example The following commands configure public key authentication for “admin2”. Key Configuration on PC On the admin’s PC, the following OpenSSH commands configure the public-private key pair: OpenSSHclient$mkdir ~/.ssh OpenSSHclient$chmod 700 ~/.ssh OpenSSHclient$ssh-keygen -q -f ~/.ssh/ax_admin2 -t rsa Enter passphrase (empty for no passphrase): … Enter same passphrase again: …

Do not type “empty” at the passphrase prompts. Just press Enter.

Note:

Configuration on AX Device The following commands import admin2’s public key and verify its presence on the AX device: AX(config)#admin admin2 AX(config-admin:admin2)#ssh-pubkey import scp: Address or name of remote host []?10.10.10.69 User name []?axadmin2 Password []?********* File name [/]?ax_admin2.pem AX(config-admin:admin2)#ssh-pubkey list

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

339 of 486

AX Series - System Configuration and Administration Guide Changing Web Access Settings

Changing Web Access Settings By default, access to the AX management GUI is enabled and is secure. A valid admin username and password are required to log in. Table 18 lists the default settings for Web access. TABLE 18 Default Web Access Settings Parameter Auto-redirect

HTTP server HTTP port HTTPS server HTTPS port Timeout

aXAPI Timeout

Description Automatically redirects requests for the unsecured port (HTTP) to the secure port (HTTPS). HTTP server on the AX device. Protocol port number for the unsecured (HTTP) port. HTTPS server on the AX device. Protocol port number for the secure (HTTPS) port. Number of minutes a Web management session can remain idle before it times out and is terminated by the AX device.

Number of minutes an aXAPI session can remain idle before being terminated. Once the aXAPI session is terminated, the session ID generated by the AX device for the session is no longer valid. Note: For information about aXAPI, see the AX Series aXAPI Reference.

Note:

Default Enabled

Enabled 80 Enabled 443 Range: 0-60 minutes To disable the timeout, specify 0. Default: 10 minutes 0-60 minutes. f you

specify 0, sessions never time out. Default: 10 minutes

If you disable HTTP or HTTPS access, any sessions on the management GUI are immediately terminated.

USING THE GUI 1. Select Config > System > Settings. 2. On the menu bar, select Web. 3. Edit the settings you want to change. 4. Click OK.

340 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Changing Web Access Settings Note:

The Preference section sets the default IP address type (IPv4 or IPv6) for GUI configuration fields that require an IP address. The Preference section does not affect access to the GUI itself.

USING THE CLI At the global configuration level of the CLI, use the following command: [no] web-service { axapi-timeout-policy idle minutes | auto-redir | port protocol-port | secure-port protocol-port | server | secure-server | timeout-policy idle minutes } To view Web access settings, use the following command: show web-service

CLI EXAMPLE The following command disables management access on HTTP and verifies the change: AX(config)#no web-service server AX(config)#show web-service

AX Web server: Idle time: Http port: Https port: Auto redirect: Https: Http: aXAPI Idle time:

10 minutes 80 443 Enabled Enabled Disabled 10 minutes

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

341 of 486

AX Series - System Configuration and Administration Guide Command Auditing

Command Auditing You can enable command auditing to log the commands entered by AX admins. Command auditing logs the following types of system management events: • Admin logins and logouts for CLI, GUI, and aXAPI sessions • Unsuccessful admin login attempts • Configuration changes. All attempts to change the configuration are

logged, even if they are unsuccessful. • CLI commands at the Privileged EXEC level (if audit logging is enabled

for this level) • HA configuration synchronization

The audit log is maintained in a separate file, apart from the system log. The audit log is RBA-aware. The audit log messages that are displayed for an admin depend upon the admin’s role (privilege level). Admins with Root, Read Write, or Read Only privileges who view the audit log can view all the messages, for all system partitions. Admins who have privileges only within a specific partition can view only the audit log messages related to management of that partition. Partition Real Server Operator admins can not view any audit log entries. Note:

Backups of the system log include the audit log. Command auditing is disabled by default. To enable it, use either of the following methods. Audit Log Examples The following audit log indicates a change to the image to use for booting, performed using the CLI:

Jul 06 2010 23:27:25

admin cli: bootimage hd sec

The following audit logs indicate configuration and operational actions related to virtual server “vip1” performed using the GUI: Jun 08 2010 09:06:04 [12] web: [admin] vport1:8001(TCP).] successfully. Jun 08 2010 09:06:05 [12] web: [admin] vport1:8001(TCP).] successfully. Jun 08 2010 09:06:06 [12] web: [admin] Jun 08 2010 09:06:06 [12] web: [admin] Jun 08 2010 09:06:07 [12] web: [admin]

342 of 486

add virtual server [name:vip1, ip:1.1.1.1, edit virtual server [name:vip1, ip:1.1.1.1, disable virtual server [vip1] successfully. enable virtual server [vip1] successfully. delete virtual server [vip1] successfully.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Command Auditing The following audit logs indicate configuration actions related to virtual server “vip1” performed using the aXAPI: Jun 08 2010 09:06:13 [12] axapi: [admin] add virtual server [name:vip1, ip:1.1.1.1, vport1:8001(TCP).] successfully. Jun 08 2010 09:06:14 [12] axapi: [admin] edit virtual server [name:vip1, ip:1.1.1.1, vport1:8001(TCP).] successfully. Jun 08 2010 09:06:15 [12] axapi: [admin] delete virtual server [vip1] successfully.

USING THE GUI To enable command auditing: 1. Select Config > System > Settings > Log. 2. Click to expand the Audit section. 3. Select the audit level: • Disabled – Command auditing is disabled. • Enabled – Auditing of configuration commands is enabled. • Enable Privilege – Auditing of configuration commands and Privi-

leged EXEC commands is enabled. 4. To modify the maximum number of entries the log can hold, edit the number in the Audit Buffer Size field. You can specify 1000-30000 entries. The default is 20000. 5. Click OK. To show audit log entries, navigate to the following page: Monitor > System > Audit > Logging

USING THE CLI To enable command auditing, use the following command at the global configuration level of the CLI: [no] audit enable [privilege] The privilege option enables logging of Privileged EXEC commands also. Without this option, only configuration commands are logged. To specify the number of entries the audit log file can hold, use the following command at the global configuration level of the CLI: [no] audit size num-entries

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

343 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access You can specify 1000-30000 entries. When the log is full, the oldest entries are removed to make room for new entries. The default is 20,000 entries. To show audit log entries, use the following command: show audit [all-partitions | partition name]

Configuring AAA for Admin Access You can configure the AX device to use remote servers for Authentication, Authorization, and Accounting (AAA) for admin sessions. The AX device supports RADIUS and TACACS+ servers.

Authentication Authentication grants or denies access based on the credentials presented by the person who is attempting access. Authentication for management access to the AX device grants or denies access based on the admin username and password. By default, when someone attempts to log into the AX device, the device checks its local admin database for the username and password entered by the person attempting to gain access. Without additional configuration, the authentication process stops at this point. If the admin username and password are in the local database, the person is granted access. Otherwise, they are denied. You can configure the AX device to also use external RADIUS or TACACS+ servers for authentication. You can use TACACS+ or RADIUS for external authentication. Only one external authentication method can be used.

Authentication Process You can specify whether to check the local database or the remote server first. Figure 80 and Figure 81 show the authentication processes used if the AX device is configured to check remote AAA servers (RADIUS or TACACS+) first. If the RADIUS or TACACS+ server responds, the local database is not checked.

344 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access • If the admin name and password are found on the RADIUS or

TACACS+ server, the admin is granted access. • If the admin name and password are not found on the RADIUS or

TACACS+ server, the admin is denied access. Only if there is no response from any RADIUS or TACACS+ server, does the AX device check its local database for the admin name and password. Username “admin” Always Authenticated Locally By Default An exception is made for the “admin” account. By default, the AX device always uses local authentication for “admin”. Optionally, you can disable automatic local authentication for “admin”, in which case the authentication process is the same as for other admin accounts. FIGURE 80 Authentication Process When Remote Authentication Is First (2 remote servers configured) – Example shown is for RADIUS

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

345 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access FIGURE 81 Authentication Process When Remote Authentication Is First (1 remote server configured) – Example shown is for TACACS+

Token-based Authentication Support for RADIUS The AX Series supports RSA token-based RADIUS authentication. Tokenbased authentication provides additional login security by requiring the admin to enter a string, the token, in addition to the username and password. This enhancement supports the Access-Challenge function described in RFC 2865, Remote Authentication Dial In User Service (RADIUS). After the admin enters the username and password, the AX device sends them to the RADIUS server. If the username and password are valid, and the server is configured to use token-based authentication, the server replies with an Access-Challenge message. The AX device then displays a prompt for the required token.

346 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access • If the token is also valid, the admin is granted access. • If the token is invalid, access is denied, even though the username and

password are valid. Support for token-based RADIUS authentication is enabled by default and can not be disabled. No additional configuration is required on the AX device. The following sections show examples of login sessions in which a token is required for login.

USING THE GUI In the following example, an admin initiates login by entering their username and password. The AX device presents a challenge value and prompts for the response. FIGURE 82

GUI Token-based Login

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

347 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access

USING THE CLI In the following example, an admin initiates login by entering their username and password. The AX device presents a challenge value and prompts for the response. login as: admin2 Using keyboard-interactive authentication. Password: ******** Using keyboard-interactive authentication. Challenge: 133420 Response: ****** Last login: Fri Jul

1 21:51:35 2011 from 192.168.32.153

[type ? for help] AX>

Authorization You can configure authorization based on the following: • Management interface used by the admin (CLI, GUI, or aXAPI) • GUI page requested by the admin • CLI command entered by the admin • Role-Based Administration (RBA) partition

Authorization Based on Management Interface You can deny an admin from accessing the AX device through one or more of the following management interfaces: • CLI • GUI • aXAPI

By default, admins are allowed to use any of the management interfaces. RADIUS Configuration for Management Interface Access To configure authorization based on management interface, use the following A10-Admin-Access-Type values:

348 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access • cli • web • axapi

To authorize access to more than one management interface, use a comma between each value. For example: cli,web If you do not specify an A10-Admin-Access-Type value, access through all three interfaces is permitted. TACACS+ Configuration for Management Interface Access To configure authorization based on management interface, use the following AVP: a10-access-type=mgmt-int The mgmt-int can be one or more of the following: • cli • web • axapi

To authorize access to more than one management interface, use a comma between each value. For example: a10-access-type=cli,web If you do not specify an A10-Admin-Access-Type value, access through all three interfaces is permitted.

Authorization for GUI Access Each admin account configured on the AX device includes a GUI access role. The GUI access role specifies the GUI pages to which the admin has write privileges, the pages to which the admin has read-only privileges, and if applicable, the pages that are hidden from the admin. For each GUI page, the admin role specifies whether the admin is allowed to access (view) the page. If the admin is allowed to access the page, the role specifies whether the admin has read-only or read-write privileges for the page. You can assign an admin to a preconfigured role or a custom role that you configure. You also can customize the preconfigured roles. Table 15 on page 325 lists the preconfigured roles and the types of GUI page access allowed by each one.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

349 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access Note:

The GUI access roles do not apply to admins who log in through the CLI. (See “Authorization for CLI Access” on page 351.)

Note:

Also see “RADIUS Authorization Based on Service-Type” on page 355. RADIUS Configuration for GUI Access Roles To configure role-based authorization for access to the GUI, use the A10-Admin-Privilege option. For example, to authorize access to the GUI pages associated with the PartitionReadWrite role, use the following statement in the admin definition: A10-Admin-Role = "PartitionReadWrite"

Note:

In the current release, the A10-Admin-Privilege option applies only to GUI access. It does not restrict CLI or aXAPI access. TACACS+ Configuration for GUI Access Roles To configure role-based authorization for access to the GUI, use the following Attribute Value Pair (AVP): a10-admin-role=role-name

Note:

In the current release, this AVP applies only to GUI access. It does not restrict CLI or aXAPI access. Compatibility with Privilege Levels Assigned by RADIUS or TACACS+ It is not required to assign a privilege level to an AX admin on the RADIUS or TACACS+ server used to authenticate the admin. The AX device uses the GUI access role assigned to the admin in the admin’s account on the AX device. However, if a privilege level is assigned to the admin on the RADIUS or TACACS+ server, that privilege level must match the role assigned to the admin in the AX configuration. Otherwise, the admin will be denied access. Table 19 lists the RADIUS and TACACS+ privilege levels that match the GUI access roles.

TABLE 19 RADIUS / TACACS+ Privilege Levels and Matching GUI Access Roles Privilege Level GUI Access Role ReadWriteAdmin SystemAdmin NetworkAdmin

350 of 486

RADIUS 2 3 4

TACACS+ 15 14 13

Partition Role N N N

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access TABLE 19 RADIUS / TACACS+ Privilege Levels and Matching GUI Access Roles (Continued) Privilege Level GUI Access Role NetworkOperator SlbServiceAdmin SlbServiceOperator ReadOnlyAdmin PartitionReadWrite PartitionNetworkOperator PartitionSlbServiceAdmin PartitionSlbServiceOperator PartitionReadOnly

RADIUS 5 6 7 1 8 9 10 11 12

TACACS+ 12 11 10 0 9 8 7 6 5

Partition Role N N N N Y Y Y Y Y

The Partition Role column indicates whether the GUI access role is for a partition admin and requires specification of a private partition name. If the privilege level for a partition role is specified on the RADIUS or TACACS+ server, the partition name also must be specified on the server. If the privilege level is for a non-partition role, it is invalid to specify a partition name on the server.

Authorization for CLI Access You can configure the AX device to use external RADIUS or TACACS+ servers to authorize commands entered by admins who log in using the CLI. Following successful Authentication, the authenticated party is granted access to specific system resources by Authorization. For an AX admin, authorization specifies the CLI levels they can access. Operational Commands Disabled for Read-Only Admins Admins who are authenticated by RADIUS or TACACS+, and authorized for read-only access directly to the Privileged EXEC level of the CLI, are not allowed to run certain operational commands. For these admins, the following operational commands at the Privileged EXEC level of the CLI are disabled: • backup • config • import • locale • reboot

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

351 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access • reload • shutdown

This includes admins with the ReadOnlyAdmin or PartitionReadOnly role. RADIUS CLI Authorization To configure RADIUS CLI Authorization, use the following settings on the RADIUS server: VALUE A10-Admin-Privilege Read-only-Admin 1 VALUE A10-Admin-Privilege Read-write-Admin 2 The first line grants access to the User EXEC level and Privileged EXEC level. The admin’s CLI session begins at the User EXEC level. The admin can access the Privileged EXEC level, without entering an enable password. Access to the configuration level is not allowed. login as: admin3 Using keyboard-interactive authentication. Password: ******** Last login: Fri Mar 26 20:03:39 2010 from 192.168.1.140 [type ? for help] AX>enable AX#

The second line grants access to all levels. The admin’s CLI session begins at the Privileged EXEC level. login as: admin4 Using keyboard-interactive authentication. Password: ******** Last login: Fri Mar 26 20:03:39 2010 from 192.168.1.140 [type ? for help] AX#

Note:

352 of 486

Also see “RADIUS Authorization Based on Service-Type” on page 355.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access TACACS+ CLI Authorization To configure TACACS+ CLI Authorization: • Configure the TACACS+ server to authorize or deny execution of spe-

cific commands or command groups. • Configure the AX device to send commands to the TACACS+ server for

authorization before executing those commands. Note:

This authorization process does not apply to admins who log in through the GUI. (See “Authorization for GUI Access” on page 349.) CLI Access Levels You can use TACACS+ to authorize an admin to execute commands at one of the following CLI access levels: • 15(admin) – This is the most extensive level of authorization. Com-

mands at all CLI levels, including those used to configure admin accounts, are sent to TACACS+ for authorization. • 14(config) – Commands at all CLI levels except those used to configure

admin accounts are sent to TACACS+ for authorization. Commands for configuring admin accounts are automatically allowed. • 1(priv EXEC) – Commands at the Privileged EXEC and User EXEC

levels are sent to TACACS+ for authorization. Commands at other levels are automatically allowed. • 0 (user EXEC) – Commands at the User EXEC level are sent to

TACACS+ for authorization. Commands at other levels are automatically allowed. Access levels 1-15 grant access to the Privileged EXEC level or higher, without challenging the admin for the enable password. Access level 0 grants access to the User EXEC level only. Note:

Command levels 2-13 are equivalent to command level 1.

Caution:

The most secure option is 15(admin). If you select a lower option, for example, 1(priv EXEC), make sure to configure the TACACS+ server to deny any unmatched commands (commands that are not explicitly allowed by the server). Otherwise, unmatched commands, including commands at higher levels, will automatically be authorized to execute.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

353 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access TACACS+ Authorization Debug Options You can enable the following TACACS+ debug levels for troubleshooting: • 0x1 – Common system events such as “trying to connect with

TACACS+ servers” and “getting response from TACACS+ servers”. These events are recorded in the syslog. • 0x2 – Packet fields sent out and received by the AX Series device, not

including the length fields. These events are written to the terminal. • 0x4 – Length fields of the TACACS+ packets will also be displayed on

the terminal. • 0x8 – Information about TACACS+ MD5 encryption will be sent to the

syslog.

Authorization Based on Private Partition If the AX device is configured with Role-Based Administration (RBA) partitions, you can specify the private partitions a remotely authenticated admin is authorized to access. You can authorize an admin for up to 8 partitions. The partition name specified on the RADIUS or TACACS+ server must match the partition name specified in the admin’s account configuration on the AX device. Note:

For admins with global access (access to the shared partition), do not specify a partition name. RADIUS Configuration for Partition Access To authorize an admin to access only the resources in a specific RBA partition, use the A10-Admin-Partition option. For example, to authorize an admin to access only the resources in partition “aa”, use the following statement in the admin definition: A10-Admin-Partition = "partition-name"

To authorize an admin to access more than one partition, use the following syntax: A10-Admin-Partition A10-Admin-Partition A10-Admin-Partition A10-Admin-Partition A10-Admin-Partition A10-Admin-Partition A10-Admin-Partition A10-Admin-Partition

354 of 486

= "partition-name1” += " partition-name2” += " partition-name3” += " partition-name4” += " partition-name5” += " partition-name6” += " partition-name7” += " partition-name8”

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access TACACS+ Configuration for Partition Access To authorize an admin to access only the resources in a specific RBA partition, use the following AVP: a10-partition=partition-name To authorize an admin to access more than one partition, use the following syntax: a10-partition = partition-name1,partition-name2, partition-name3,partition-name4,partition-name5, partition-name6,partition-name7,partition-name8

RADIUS Authorization Based on Service-Type The AX device supports the RADIUS Service-Type attribute. The following attribute values are supported: • Service-Type=Login – Allows access to the EXEC level of the

CLI (AX>), and read-only access to the GUI • Service-Type=NAS Prompt – Allows access to the Privileged

EXEC level of the CLI (AX#), and read-only access to the GUI • Service-Type=Administrative – Allows access to the con-

figuration level of the CLI [AX(config)#], and read-write access to the GUI By default, if the Service-Type attribute is not used, or the A10 vendor attribute is not used, successfully authenticated admins are authorized for readonly access. You can change the default privilege authorized by RADIUS from read-only to read-write. To change the default access level authorized by RADIUS, use the following command at the global configuration level of the CLI: [no] radius-server default-privilege-read-write

Accounting You can configure the AX device to use external RADIUS or TACACS+ servers for Accounting. Accounting keeps track of user activities while the user is logged on. For AX admins, you can configure Accounting for the following: • Login/logoff activity (start/stop accounting) • Commands

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

355 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access

Command Accounting (TACACS+ only) You can use TACACS+ servers to track attempts to execute commands at one of the following CLI access levels: • 15(admin) – This is the most extensive level of accounting. Commands

at all CLI levels, including those used to configure admin accounts, are tracked. • 14(config) – Commands at all CLI levels except those used to configure

admin accounts are tracked. Commands for configuring admin accounts are not tracked. • 1(priv EXEC) – Commands at the Privileged EXEC and User EXEC

levels are tracked. Commands at other levels are not tracked. • 0 (user EXEC) – Commands at the User EXEC level are tracked. Com-

mands at other levels are not tracked. Note:

Command levels 2-13 are equivalent to command level 1.

TACACS+ Accounting Debug Options The same debug levels that are available for TACACS+ Authorization are also available for TACACS+ Accounting. (See “TACACS+ Authorization Debug Options” on page 354.)

Configuring AAA for Admin Access To configure AAA for admin access: 1. Prepare the AAA servers: • Add admin accounts (usernames and passwords). • Add the AX device as a client. For the client IP address, specify the AX IP address. • For authorization, configure the following settings for the admin accounts: • Specify the management interfaces the admin is allowed to access (CLI, GUI, or aXAPI). • If using TACACS+, specify the CLI commands or command groups that are to be allowed or denied execution. • If using RADIUS, specify the access role for the GUI. • For private partition admins, specify the partition name.

356 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 2. To use RADIUS or TACACS+ for Authentication: a. Add the RADIUS or TACACS+ server(s) to the AX device. b. Add RADIUS or TACACS+ as an authentication method to use along with the local database. 3. Configure Authorization: a. Add the TACACS+ or RADIUS servers, if not already added for authentication. b. Specify the access level: • If using TACACS+, specify the CLI command levels to be authorized. • If using RADIUS, specify the GUI access to be authorized. 4. Configure Accounting: a. Add the TACACS+ or RADIUS servers, if not already added for Authorization. b. Specify whether to track logon/logoff activity. You can track both logons and logoffs, logoffs only, or neither. c. Optionally, is using TACACS+, specify the command levels to track.

Configuring Authentication To configure remote authentication, use either of the following methods.

USING THE GUI 1. Select Config > System > Admin > External Authentication > General. 2. Select the authentication methods an d the order in which to use them. You can select one of the following: • Local Only – The local admin database on the AX device is used.

No external authentication servers are used. • Local/RADIUS – The local admin database is consulted first. If the local database does not contain an account for the username entered by the admin, the RADIUS server is consulted. • Local/TACACS+ – The local admin database is consulted first. If the local database does not contain an account for the username entered by the admin, the TACACS+ server is consulted. • RADIUS/Local – The RADIUS server is consulted first. If the RADIUS server does not respond, the local admin database is consulted. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

357 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access • TACACS+/Local – The TACACS+ server is consulted first. If the

TACACS+ server does not respond, the local admin database is consulted. 3. Click OK. 4. Select one of the following options: • Config > System > Admin > External Authentication > RADIUS • Config > System > Admin > External Authentication > TACACS+

5. To add the primary server, click Server 1 to display the configuration fields for the server. 6. Enter the hostname or IP address of the server in the Hostname field. 7. In the Secret and Confirm Secret fields, enter the shared secret (password) expected by the server when it receives requests. 8. To add a backup server to use if the primary server can not be reached, click Server 2 and enter the configuration information for the server. 9. Click OK.

USING THE CLI Note:

The command syntax shown in this section is simplified to show the required or more frequently used options. For complete syntax information, see the AX Series CLI Reference. 1. Use one of the following commands at the global configuration level of the CLI to add the primary server: [no] radius-server host {hostname | ipaddr} secret secret-string [no] tacacs-server host {hostname | ipaddr} secret secret-string The secret-string is the shared secret (password) expected by the server when it receives requests. 2. To add a backup server to use if the primary server can not be reached, repeat the command, using the backup server’s information.

358 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 3. Use one of the following commands to specify the order in which to use the authentication methods: [no] authentication [console] type { local [radius | tacplus] | [radius | tacplus] local } The console option applies the authentication settings only to access through the console (serial) port. Without this option, the settings apply to all types of admin access. (For more information, see “Authentication Process” on page 344.) Local Authentication Disable for “admin” You can disable automatic local authentication for the “admin” account. By default, the AX device always locally authenticates “admin” even if RADIUS or TACACS+ is used as the primary authentication method. Automatic local authentication of “admin:” is still the default behavior. To disable this behavior, use either of the following methods. Note:

If the RADIUS or TACACS+ server can not be reached, the AX device then uses local authentication for “admin”. This is the same behavior as is used for other admin accounts when the remote AAA server can not be reached.

USING THE GUI 1. Select Config > System > Admin > External Authentication > General. 2. Select “Disable the local authentication when the external authentication is available”. 3. Click OK.

USING THE CLI To disable automatic local authentication of the “admin” account: 1. Log in using the “admin” account. 2. Use the following command at the global configuration level of the CLI: [no] authentication disable-local

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

359 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access

Configuring Authorization Note:

The command syntax shown in this section is simplified to show the required or more frequently used options. For complete syntax information, see the AX Series CLI Reference.

Note:

The configuration options described in this section are available only in the CLI. 1. Add the RADIUS or TACACS+ server(s), if not already added. [no] tacacs-server host {hostname | ipaddr} secret secret-string [no] radius-server host {hostname | ipaddr} secret secret-string 2. Optionally, if using TACACS+, specify the command levels the TACACS+ server will be used to authorize: authorization commands cmd-level method tacplus [none] The cmd-level can be one of the following: 15, 14, 1, or 0. The none option allows a command to execute if Authorization cannot be performed (for example, if all TACACS+ servers are down). (For descriptions, see “Authorization for CLI Access” on page 351.)

Note:

If using RADIUS, you can set the GUI access levels on the RADIUS server itself. See “Authorization for GUI Access” on page 349. 3. Optionally, if using TACACS+, enable Authorization debugging: authorization debug debug-level The debug-level can be one of the following: 0x1, 0x2, 0x4, or 0x8. (See “TACACS+ Authorization Debug Options” on page 354.)

Configuring Accounting

360 of 486

Note:

The command syntax shown in this section is simplified to show the required or more frequently used options. For complete syntax information, see the AX Series CLI Reference.

Note:

The configuration options described in this section are available only in the CLI.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 1. Add the RADIUS or TACACS+ server(s), if not already added. [no] tacacs-server host {hostname | ipaddr} secret secret-string [no] radius-server host {hostname | ipaddr} secret secret-string 2. To configure Accounting for logon/logoff activity, use the following command: [no] accounting exec {start-stop | stop-only} {radius | tacplus} 3. Optionally, if using TACACS+, configure accounting for command execution: accounting commands cmd-level stop-only tacplus 4. Optionally, if using TACACS+, enable Accounting debugging: accounting debug debug-level

CLI EXAMPLES RADIUS Authentication The following commands configure a pair of RADIUS servers and configure the AX device to use them first, before using the local database. Since 10.10.10.12 is added first, this server will be used as the primary server. Server 10.10.10.13 will be used only if the primary server is unavailable. AX(config)#radius-server host 10.10.10.12 secret radp1 AX(config)#radius-server host 10.10.10.13 secret radp2 AX(config)#authentication type radius local

TACACS+ Authorization The following commands configure the AX device to use TACACS+ server 10.10.10.13 to authorize commands at all CLI levels. In this example, the none option is not used. As a result, if TACACS+ authorization cannot be performed (for example, due to server unavailability), the command is denied. AX(config)#tacacs-server host 10.10.10.13 secret SharedSecret AX(config)#authorization commands 15 method tacplus

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

361 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access TACACS+ Accounting The following commands configure the AX device to use the same TACACS+ server for accounting of logon/logoff activity and of all command activity: AX(config)#accounting exec start-stop tacplus AX(config)#accounting commands 15 stop-only tacplus

EXAMPLE INCLUDING RADIUS SERVER SETUP This example shows the AX commands to configure an AX device to use a RADIUS server, and also shows the changes to make on the RADIUS server itself. The RADIUS server in this example is freeRADIUS. The IP address is 192.168.1.157, and the shared secret is “a10rad”. To implement the solution, the following steps are required: 1. On the AX device: a. Add the RADIUS server. b. Enable RADIUS authentication. 2. On the freeRADIUS server: a. In the clients.conf file, add the AX device as a client. b. Add a dictionary file for vendor “a10networks”, and add the file to the dictionary. c. In the users file, add each AX admin as a user. Configuration on the AX Device Enter the following commands at the global configuration level of the CLI: AX(config)#radius-server host 192.168.1.157 secret a10rad AX(config)#authentication type local radius

362 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access Configuration on the freeRADIUS Server Changes in clients.conf File The AX device is added to the clients.conf file as a RADIUS client: vi /usr/local/etc/raddb/clients.conf client 192.168.1.0/24 { secret

= a10rad

shortname

= private-network-1

}

In this example, the AX device’s subnet is added as the client.

Note:

Creation of dictionary.a10networks File In the dictionary file, specify the following: • Vendor name – “A10-Networks” • Vendor code – 22610

After authenticating an admin, the RADIUS server must return the A10-Admin-Privilege attribute, with one of the values shown in the following example. vi /usr/local/share/freeradius/dictionary.a10networks # A10-Networks dictionary # Created by Software Tools of A10 Networks. # VENDOR A10-Networks 22610 BEGIN-VENDOR A10-Networks ATTRIBUTE A10-App-Name

1

string

ATTRIBUTE A10-Admin-Privilege

2

integer

ATTRIBUTE A10-Admin-Partition

3

string

ATTRIBUTE A10-Admin-Access-Type ATTRIBUTE A10-Admin-Role

4 5

string string

VALUE

A10-Admin-Privilege

Read-only-Admin

VALUE

A10-Admin-Privilege

Read-write-Admin

1

VALUE

A10-Admin-Privilege

System-Admin

VALUE

A10-Admin-Privilege

Network-Admin

VALUE

A10-Admin-Privilege

Network-Operator

VALUE

A10-Admin-Privilege

Slb-Service-Admin

2 3 4

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

5 6

363 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access VALUE

A10-Admin-Privilege

Slb-Service-Operator

7

VALUE

A10-Admin-Privilege

Partition-Read_write

8

VALUE

A10-Admin-Privilege

Partition-Network-Operator

9

VALUE

A10-Admin-Privilege

Partition-SlbService-Admin

10

VALUE

A10-Admin-Privilege

Partition-SlbService-Operator

VALUE

A10-Admin-Privilege

Partition-Read-Only

11

12

END-VENDOR A10-Networks vi /usr/local/share/freeradius/dictionary add $INCLUDE dictionary.a10networks

#new added for a10networks

Changes in users File vi /usr/local/etc/raddb/users

Here are some examples of AX admin definitions in a RADIUS users file on the RADIUS server. ################################### #this is a read-write user rw Cleartext-Password := A10-Admin-Privilege = #this is a read-only user ro Cleartext-Password := A10-Admin-Privilege =

"111111" Read-write-Admin, "111111" Read-only-Admin,

#this is a partition read-write prw Cleartext-Password := "111111" A10-Admin-Privilege = Partition-SlbService-Admin, A10-Admin-Partition = "aa" #this is a partition read-only pro Cleartext-Password := "111111" A10-Admin-Privilege = Partition-Read-Only, A10-Admin-Partition = "aa" #this is a partition enable-disable ped Cleartext-Password := "111111" A10-Admin-Privilege = Partition-SlbService-Operator, A10-Admin-Partition = "aa" #this is partition read-write, has role PartitionReadWrite, only login from web. prw_r_w Cleartext-Password := "111111"

364 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access A10-Admin-Privilege = Partition-SlbService-Admin, A10-Admin-Partition = "aa", A10-Admin-Role = "PartitionReadWrite", A10-admin-Access-type = "web"

#this is partition read-write, has a user-defined role name role1, only login from cli prw_r_c Cleartext-Password := "111111" A10-Admin-Privilege = Partition-SlbService-Admin, A10-Admin-Partition = "aa", A10-Admin-Role = "role1", A10-admin-Access-type = "cli"

Configuring Windows IAS for AX RADIUS Authentication This section describes how to configure Windows Server 2003 Internet Authentication Service (IAS) for use with AX RADIUS authentication. These steps assume that IAS and Active Directory (AD) are already installed on the Windows 2003 server.

Procedure Overview To configure Windows IAS for AX RADIUS authentication: 1. On the IAS server, create the following access groups: • AX-Admin-Read-Only • AX-Admin-Read-Write 2. On the IAS server, configure a RADIUS client for the AX device. 3. On the IAS server, configure the following remote access policies: • AX-Admin-Read-Only-Policy • AX-Admin-Read-Write-Policy).

4. On the IAS server, add AD users to appropriate AX device access groups, either AX-Admin-Read-Only or AX-Admin-Read-Write. 5. Register the IAS server in AD. 6. On the AX device, configure RADIUS. 7. Test the configuration by attempting to log onto the AX device with AD users added in step 4. The following sections provide detailed steps for each of these tasks. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

365 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access

Configure Access Groups 1. Select Start > All programs > Administrator tools > Active directory user and computers. If Active Directory Is Not Installed If AD is not installed on the IAS server, you can use the following steps to add the users and groups. However, the rest of this section assumes that AD will be used. 1. Open the Computer Management tool by selecting Start > Programs > Administrative Tools > Computer Management. 2. Open the System Tools and Local Users and Groups items, if they are not already open. 3. Right click on Group and select New Group. 4. Enter the following information for the first group: • Group Name – AX-Admin-Read-Only • Group Description – Read-Only Access to AX devices • Members – Add the members using the Add button.

366 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 5. Click Create. 6. Enter the following information for the second group: • Group Name – AX-Admin-Read-Write • Group Description – Read-Write to AX devices • Members – Add members as desired using the Add button

7. Click Create. 8. Click Close.

Configure RADIUS Client for AX Device 1. Open Internet Authentication Service, by selecting Start > Programs > Administrative Tools > Internet Authentication Service. 2. Right-click on Client and select New Client. 3. Enter the following information in the Add Client dialog box: • Friendly name – Useful name for the AX device; for example,

ax2000_slb1 • Protocol – RADIUS

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

367 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access Note:

192.168.1.238 is the IP address of the AX device that will use the IAS server for external RADIUS authentication. 4. Click Next. 5. Enter the following information in the Add RADIUS Client dialog box: • Client address – IP address or domain name for the client (AX

device) • Client-Vendor – RADIUS Standard • Shared secret – Secret to be shared between IAS and AX. You also will need to enter this in the RADIUS configuration on the AX device. • Confirm shared secret – Same as above Note:

Do not select “Request must contain the Message Authenticator attribute”. AX RADIUS authentication does not support this option.

6. Click Next.

368 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access

Configure Remote Access Policies 1. Open the Internet Authentication Service, if not already open. 2. To create the first remote access policy, right-click on Remote Access Policies, select New Remote Access Policy, and enter the following information: Policy Friendly name – AX-Admin-Read-Only-Policy

3. Click Next. 4. In the Add Remote Access Policy dialog box, click Add. 5. In the Select Attribute dialog box, double-click Client Friendly Name. 6. In the Client-Friendly-Name dialog box, enter the friendly name used to define the AX device (for example, AX-Admin-Read-Only-Policy) and click OK. 7. In the same Add Remote Access Policy dialog box as before, click Add again.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

369 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 8. In the Select Attribute dialog box, double-click Windows-Groups.

370 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 9. In the Groups dialog box, click Add, then double-click AX-AdminRead-Only group, Click OK to add the group, then click OK once more to confirm the groups.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

371 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 10. In the same Add Remote Access Policy dialog box as before, click Next. 11. Select Grant remote access permission, and click Next.

372 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 12. Click Edit Profile.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

373 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 13. In the Edit Dial-in Profile dialog box, select the Authentication tab. Select the type of authentication you are using: CHAP and PAP.

374 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 14. Select the Advanced tab, and click Add. 15. In the RADIUS attributes list, find and double-click the line beginning with Vendor-Specific.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

375 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 16. In the Multivalued Attribute Information dialog box, click Add and enter the following: • Enter vendor code – 22610 (for A10 Networks) • Conforms to RADIUS RFC – Yes

376 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 17. Click Configure Attribute, and enter the following information: • Vendor-assigned attribute number – 2 • Attribute format – Decimal • Attribute value – 1

Note:

Attribute value 1 is read-only. Attribute value 2 is read-write.

18. Click OK for the Configure VSA, Vendor-Specific Attribute Information, and Multivalued Attribute Information dialog boxes. 19. Click Close in the Add Attributes dialog box. 20. Click OK in the Edit Dial-In Profile dialog box. Optionally, read the suggested help by clicking OK. 21. Click Finish in the Add Remote Access Policy dialog box. 22. To create the second Remote Access Policy, repeat the above steps with the following changes: • Policy Friendly name – AX-Admin-Read-Write-Policy • Group to add – AX-Admin-Read-Write • Attribute value – 2

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

377 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access

Add AD Users to AX Access Groups 1. In the Active Directory management console, add the AX access group to the user, tester1:

378 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access 2. Make sure Remote Access Permission is enabled:

Register the IAS Server in Active Directory The IAS RADIUS server must be registered with AD. Otherwise, RADIUS will use compatibility mode instead of AD to authenticate users. 1. Open the IAS main window. 2. Click Action on the menu bar, and click “register server on active directory”.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

379 of 486

AX Series - System Configuration and Administration Guide Configuring AAA for Admin Access

Configure RADIUS in the AX Device Add the RADIUS server (IAS server) to the AX device. Make sure the shared secret is the same as the one specified for the RADIUS client configured for the AX server on the IAS server. AX(config)#radius server 192.168.230.10 secret shared-secret AX(config)#authentication type local radius

Note:

192.168.230.10 is the IP address of w2003-10.com, and shared-secret is the secret entered in the step 5 in “Configure RADIUS Client for AX Device” on page 367.

Test the Configuration 1. Access the AX CLI command prompt. 2. Enter the login name, in the following format: user-name@AD-domain-name In this example, use “[email protected]”. 3. Enter the password. 4. Press Enter.

380 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide DDoS Protection

Traffic Security Features AX Series devices support the following advanced security features, which are described in this chapter: • “DDoS Protection” on page 381 • “SYN Cookies” on page 385 • “ICMP Rate Limiting” on page 391 • “Access Control Lists (ACLs)” on page 394 • “Source-IP Based Connection Rate Limiting” on page 412

Also see the following chapters: • “Policy-Based SLB (PBSLB)” on page 419 • “Geo-location-based Access Control for VIPs” chapter in the AX Series

Application Delivery and Server Load Balancing Guide • “IP Limiting” chapter in the AX Series Application Delivery and Server

Load Balancing Guide • “DNS Optimization and Security” chapter in the AX Series Application

Delivery and Server Load Balancing Guide

DDoS Protection AX Series devices provide enhanced protection against distributed denialof-service (DDoS) attacks, with IP anomaly filters. The IP anomaly filters drop packets that contain common signatures of DDoS attacks. Note:

On 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, DDoS protection is hardware-based. On other models, DDoS protection is softwarebased. DDoS detection applies only to Layer 3, Layer 4, and Layer 7 traffic. Layer 2 traffic is not affected by the feature. Layer 4 and Layer 7 DDoS applies only to software releases in which Server Load Balancing (SLB) is supported. All IP anomaly filters except “IP-option” apply to IPv4 and IPv6. The “IP-option” filter applies only to IPv4.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

381 of 486

AX Series - System Configuration and Administration Guide DDoS Protection You can enable the following DDoS filters. All filters are supported for IPv4. All filters except IP-option are supported for IPv6. • Frag – Drops all IP fragments, which can be used to attack hosts running

IP stacks that have known vulnerabilities in their fragment reassembly code • IP-option – Drops all packets that contain any IP options • Land-attack – Drops spoofed SYN packets containing the same IP

address as the source and destination, which can be used to launch an “IP land attack” • Ping-of-death – Drops all jumbo IP packets, known as “ping of death”

packets Note:

On models AX 1000, AX 1030, AX 2000, AX 2100, AX 2500, AX 2600, AX 3000, and AX 3030, the ping-of-death option drops all IP packets longer than 32000 bytes. On 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, the option drops IP packets longer than 65535 bytes. • TCP-no-flag – Drops all TCP packets that do not have any TCP flags set • TCP-SYN-FIN – Drops all TCP packets in which both the SYN and FIN

flags are set • TCP-SYN-frag – Drops incomplete (fragmented) TCP Syn packets,

which can be used to launch TCP Syn flood attacks IP Anomaly Filters for System-Wide PBSLB The following IP anomaly filters are supported specifically for system-wide PBSLB: • Invalid HTTP or SSL payload • Zero-length TCP window • Out-of-sequence packet

When these filters are enabled, the AX device checks for these anomalies in new HTTP or HTTPS connection requests from clients. Filtering for these anomalies is disabled by default. However, if you configure a system-wide PBSLB policy, the filters are automatically enabled. You also can configure the filters on an individual basis. Note:

382 of 486

In the current release, these filters are supported only for HTTP and HTTPS traffic.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide DDoS Protection (For information about system-wide PBSLB, see “Configuring SystemWide PBSLB” on page 422.)

Enabling DDoS Protection To enable DDoS protection, use either of the following methods.

USING THE GUI 1. Select Config > Service > SLB. 2. On the menu bar, select Global > DDoS Protection. 3. Select each type of DDoS protection filter to enable. To enable all of them, select Drop All. 4. Click OK.

USING THE CLI Use the following command at the global configuration level of the CLI: ip anomaly-drop {drop-all | frag | ip-option | land-attack | ping-of-death | tcp-no-flag | tcpsyn-fin | tcp-syn-frag} You can enable the following options individually or specify drop-all to enable all the options: As an example, the following command enables DDoS protection against ping-of-death attacks: AX(config)#ip anomaly-drop ping-of-death

Configuring IP Anomaly Filters for System-Wide PBSLB To configure the IP anomaly filters for system-wide PBSLB, use the following commands at the global configuration level of the CLI: [no] ip anomaly-drop out-of-sequence [threshold] [no] ip anomaly-drop zero-window [threshold] [no] ip anomaly-drop bad-content [threshold] Note:

The threshold option is valid only for the new anomaly filters described in this section. The option does not apply to other IP anomaly filters.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

383 of 486

AX Series - System Configuration and Administration Guide DDoS Protection Threshold Each of these IP anomaly filters has a configurable threshold. The threshold specifies the number of times the anomaly is allowed to occur in a client’s connection requests. If a client exceeds the threshold, the AX device applies the system-wide PBSLB policy’s over-limit action to the client. The threshold can be set to 1-127 occurrences of the anomaly. The default is 10. Note:

The thresholds are not tracked by PBSLB policies bound to individual virtual ports. SOCKSTRESS_CHECK Session State While the AX device is checking a data packet against the new IP anomaly filters, the client’s session is in the SOCKSTRESS_CHECK state. You might see this state if you are viewing debug output for the client’s session.

Displaying and Clearing IP Anomaly Statistics USING THE CLI\ Select Monitor > Service > Application > Switch.

USING THE CLI To display IP anomaly statistics, use the following command: show slb l4 For system-wide PBSLB, you also can use the following command: show pbslb client [ipaddr] In the output of this command, the counters for a dynamic client are reset to 0 when a client’s dynamic entry ages out. To clear all Layer 4 SLB statistics, including the IP anomaly counters, use the following command: clear slb l4

384 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide SYN Cookies

SYN Cookies AX Series devices provide enhanced protection against TCP SYN flood attacks, with SYN cookies. SYN cookies enable the AX to continue to serve legitimate clients during a TCP SYN flood attack, without allowing illegitimate traffic to consume system resources. The AX device supports SYN cookies for Layer 4-7 SLB traffic and for Layer 2/3 traffic. • Layer 4-7 SYN cookies protect against TCP SYN flood attacks directed

at SLB service ports. (Applies only to software releases that support SLB.) • Layer 2/3 SYN cookies protect against TCP SYN flood attacks

attempted in traffic passing through the AX device.

The Service Provided By SYN Cookies SYN cookies enable the AX device to continue to serve legitimate clients during a TCP SYN flood attack, without allowing illegitimate traffic to consume system resources. During a TCP SYN flood attack, an attacker sends a large series of TCP SYN Requests but does not acknowledge the SYN ACKs that the AX sends in reply. Normally, these half-completed connections can eventually cause the AX device's TCP connection queue to become full, which prevents the AX from establishing new connections for legitimate clients. When SYN cookies are enabled, the feature prevents the AX device’s TCP connection queue from filling up during TCP SYN flood attacks. Instead of leaving a half-completed TCP connection in the queue, the AX replies to each SYN Request with a SYN cookie, which is a special type of SYN ACK, and does not leave a connection in the queue. If the SYN Request is from a legitimate client, the client sends an ACK in response to the SYN cookie. The AX reconstructs the client’s connection information based on information in the SYN ACK, and establishes a connection for the client. However, if the SYN Request is part of an attack, the attacker does not send an ACK, and the AX therefore does not establish a connection. Dynamic SYN Cookies You can configure the on and off thresholds for SYN cookie use by the AX device. The benefit of this feature is that when there is no TCP SYN attack, TCP options are preserved.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

385 of 486

AX Series - System Configuration and Administration Guide SYN Cookies You can configure the following dynamic SYN cookie options: • On-threshold – specifies the maximum number of concurrent half-

open TCP connections allowed on the AX device, before SYN cookies are enabled. If the number of half-open TCP connections exceeds the on-threshold, the AX device enables SYN cookies. You can specify 0-2147483647 half-open connections. • Off-threshold – option specifies the minimum number of concurrent half-open TCP connections for which to keep SYN cookies enabled. If the number of half-open TCP connections falls below this level, SYN cookies are disabled. You can specify 0-2147483647 halfopen connections. Hardware-based SYN cookies are disabled by default. When the feature is enabled, there are no default settings for the on and off thresholds. If you omit the on-threshold and off-threshold options, SYN cookies are enabled and are always on regardless of the number of half-open TCP connections present on the AX device. Note:

It may take up to 10 milliseconds for the AX device to detect and respond to crossover of either threshold. Hardware-Based or Software-Based Depending on the AX model, you can use hardware-based SYN cookies or software-based SYN cookies: • Hardware-based SYN cookies can be globally enabled and apply to all

virtual server ports configured on the device. Hardware-based SYN cookies are available on the 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. • Software-based SYN cookies can be enabled on individual virtual ports.

This version of the feature is available on all AX models. (Applies only to software releases that support SLB.) Note:

Hardware-based SYN cookies are a faster, easier-to-configure alternative to the software-based SYN cookie feature available on all AX platforms. If your AX model supports hardware-based SYN cookies, A10 Networks recommends that you use the hardware-based version of the feature instead of the software-based version of the feature. If both hardware-based and software-based SYN cookies are enabled, only hardware-based SYN cookies are used. You can leave softwarebased SYN cookies enabled but they are not used.

386 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide SYN Cookies If Role-Based Administration (RBA) partitions are configured, hardwarebased SYN cookies apply to all partitions. The feature is not partitionaware. Note:

If the target VIP is in a different subnet from the client-side router, use of hardware-based SYN cookies requires some additional configuration. See “Configuration when Target VIP and Client-side Router Are in Different Subnets” on page 388.

Enabling Hardware-Based SYN Cookies To enable hardware-based SYN cookies, use following CLI method.

USING THE GUI 1. Select Config > Service > SLB. 2. On the menu bar, select Global > Settings. 3. Select Enabled next to SYN Cookie. 4. In the On Threshold field, enter the maximum number of concurrent half-open TCP connections allowed on the AX device, before SYN cookies are enabled. 5. In the Off Threshold field, enter the minimum number of concurrent half-open TCP connections for which to keep SYN cookies enabled. 6. Click OK.

USING THE CLI To enable hardware-based SYN cookies, use the following command at the global Config level of the CLI: [no] syn-cookie [on-threshold num off-threshold num] The command in the following example enables dynamic-based SYN cookies when the number of concurrent half-open TCP connections exceeds 50000, and disables SYN cookies when the number falls below 30000: AX(config)#syn-cookie on-threshold 50000 off-threshold 30000

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

387 of 486

AX Series - System Configuration and Administration Guide SYN Cookies

Configuration when Target VIP and Client-side Router Are in Different Subnets Usually, the target VIP in an SLB configuration is in the same subnet as the client-side router. However, if the target VIP is in a different subnet from the client-side router, use of hardware-based SYN cookies requires some additional configuration: • On the AX device, configure a “dummy” VIP that is in the same subnet

as the client-side router. • On the client-side router, configure a static route to the VIP, using the

dummy VIP as the next hop. Figure 83 shows an example. FIGURE 83 Hardware-based SYN Cookies – Target VIP and Client-side Router in Different Subnets

The following commands configure hardware-based SYN cookies on the AX device in this example: AX(config)#slb virtual-server dummyvip 10.10.10.154 AX(config-slb virtual server)#exit AX(config)#syn-cookie

Note:

388 of 486

If HA is configured, add both the target VIP and the dummy VIP to the same HA group, so they will fail over to the HA peer as a unit. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide SYN Cookies

Enabling Software-Based SYN Cookies If you are using an AX model that does not support hardware-based SYN cookies, you can still enable the software-based version of the feature, for individual virtual ports. Note:

Software-based SYN cookies are supported only in software releases that support SLB.

SACK and MSS with Software-based SYN-cookies Software-based SYN cookies are an optional feature available at the configuration level for virtual ports, on certain AX models. The AX device bases Selective Acknowledgment (SACK) support, and the maximum segment size (MSS) setting, in software-based SYN cookies on server replies to TCP health checks sent to the servers. SACK The AX device includes the Sack-Permitted option in TCP SYN health check packets sent to servers. • If all up servers in the service group reply with a TCP SYN-ACK that

contains a SACK option, the AX device uses SACK with the softwarebased SYN-cookie feature, for all servers in the service group. • If any of the up servers in the service group does not send a SACK

option, the AX device does not use SACK with the software-based SYN-cookie feature, for any servers in the service group. MSS The lowest MSS value supported by any of the servers in the service group is the MSS value used by the AX device for software-based SYN-cookies.

USING THE GUI 1. Select Config> Service > Server. 2. Select Virtual Server on the menu bar. 3. Click on an existing virtual server name or click Add. 4. Enter or edit the information in the General section. 5. In the Port section, select the TCP port and click Edit, or click Add.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

389 of 486

AX Series - System Configuration and Administration Guide SYN Cookies 6. If you are configuring a new port, select TCP in the Type drop-down list. 7. Select Enabled next to SYN Cookie. 8. Enter or edit other values as needed for your configuration. 9. Click OK. 10. Click OK again to save the new or changed virtual server.

USING THE CLI To enable software-based SYN cookies, use the following command at the configuration level for the virtual port on the virtual server: syn-cookie

Configuring Layer 2/3 SYN Cookie Support To configure Layer 2/3 SYN cookie support: 1. Enable Layer 2/3 SYN cookies on individual interfaces. 2. Optionally, modify the threshold for TCP handshake completion.

USING THE CLI 1. To enable Layer 2/3 SYN cookies on an interface, use the following command at the configuration level for the interface: [no] ip tcp syn-cookie The feature is disabled by default. 2. Optionally, to modify the threshold for TCP handshake completion, use the following command at the global configuration level of the CLI: [no] ip tcp syn-cookie threshold seconds You can specify 1-100 seconds. The default is 4 seconds.

390 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide ICMP Rate Limiting CLI Example The following commands globally enable SYN cookie support, then enable Layer 2/3 SYN cookies on Ethernet interfaces 4 and 5: AX(config)#syn-cookie on-threshold 50000 off-threshold 30000 AX(config)#interface ethernet 4 AX(config-if: ethernet4)#ip tcp syn-cookie AX(config-if: ethernet4)#interface ethernet 5 AX(config-if: ethernet5)#ip tcp syn-cookie

ICMP Rate Limiting ICMP rate limiting protects the AX device against denial-of-service (DoS) attacks such as Smurf attacks, which consist of floods of spoofed broadcast ping messages. ICMP rate limiting monitors the rate of ICMP traffic and drops ICMP packets when the configured thresholds are exceeded. You can configure ICMP rate limiting filters globally, on individual Ethernet interfaces, and in virtual server templates. If you configure ICMP rate limiting filters at more than one of these levels, all filters are applicable. ICMP Rate Limiting Parameters ICMP rate limiting filters consist of the following parameters: • Normal rate – The ICMP normal rate is the maximum number of ICMP

packets allowed per second. If the AX device receives more than the normal rate of ICMP packets, the excess packets are dropped until the next one-second interval begins. The normal rate can be 1-65535 packets per second. • Maximum rate – The ICMP maximum rate is the maximum number of

ICMP packets allowed per second before the AX device locks up ICMP traffic. When ICMP traffic is locked up, all ICMP packets are dropped until the lockup expires. The maximum rate can be 1-65535 packets per second. • Lockup time – The lockup time is the number of seconds for which the

AX device drops all ICMP traffic, after the maximum rate is exceeded. The lockup time can be 1-16383 seconds. Note:

Specifying a maximum rate (lockup rate) and lockup time is optional. If you do not specify them, lockup does not occur.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

391 of 486

AX Series - System Configuration and Administration Guide ICMP Rate Limiting Log messages are generated only if the lockup option is used and lockup occurs. Otherwise, the ICMP rate-limiting counters are still incremented but log messages are not generated. Note:

The maximum rate must be larger than the normal rate.

USING THE GUI To globally configure ICMP rate limiting: 1. Select Config > Network > ICMP Rate Limiting. 2. Select the ICMP Rate Limiting checkbox to activate the configuration fields. 3. Enter the normal rate in the Normal Rate field. 4. Enter the maximum rate in the Lockup Rate field. 5. Enter the lockup time in the Lockup Period field. 6. Click OK. To configure ICMP rate limiting on an individual Ethernet interface: 1. Select Config > Network > Interface. 2. Click on the interface name to display the configuration sections for it. 3. Select the ICMP Rate Limiting checkbox to activate the configuration fields. 4. Enter the normal rate in the Normal Rate field. 5. Enter the maximum rate in the Lockup Rate field. 6. Enter the lockup time in the Lockup Period field. 7. Click OK.

392 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide ICMP Rate Limiting To configure ICMP rate limiting in a virtual server template: Note:

This option is applicable only in software releases that support SLB. 1. Select Config > Service > SLB. 2. On the menu bar, select Template > Virtual Server. 3. To edit an existing template, click on the template name. To create a new template, click Add. The Virtual Server section appears. 4. Select the ICMP Rate Limit Status checkbox to enable the configuration fields. 5. Enter the normal rate in the Normal Rate field. 6. To configure the lockup time, click Lockup Status. 7. Enter the maximum rate in the Lockup Rate field. 8. Enter the lockup time in the Lockup Period field. 9. Click OK.

USING THE CLI To configure an ICMP rate-limiting filter, use the following command. You can enter this command at the global configuration level, the configuration level for a physical or virtual Ethernet interface, or the configuration level for a virtual server template. [no] icmp-rate-limit normal-rate lockup max-rate lockup-time For descriptions of the parameters, see “ICMP Rate Limiting Parameters” on page 391. To display ICMP rate limiting information, use the following commands: show icmp show interfaces show slb virtual-server server-name detail CLI Example The following commands configure a virtual server template that sets ICMP rate limiting: AX(config)#slb template virtual-server vip-tmplt AX(config-vserver)#icmp-rate-limit 25000 lock 30000 60

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

393 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs)

Access Control Lists (ACLs) You can use Access Control Lists (ACLs) to permit or deny packets based on address and protocol information in the packets. AX devices support the following types of ACLs: • Standard IPv4 ACL – Standard IPv4 ACLs filter based on source IPv4

address. • Extended IPv4 ACL – Extended IPv4 ACLs filter based on source and

destination IPv4 addresses, IP protocol, and TCP/UDP port numbers. • Extended IPv6 ACL – Extended IPv6 ACLs filter based on source and

destination IPv6 addresses, IP protocol, and TCP/UDP port numbers.

How ACLs Are Used You can use ACLs for the following tasks: • Permit or block through traffic. • Permit or block management access. • Specify the internal host or subnet addresses to which to provide Net-

work Address Translation (NAT). An ACL can contain multiple rules. Each rule contains a single permit or deny statement. Rules are added to the ACL in the order you configure them. The first rule you add appears at the top of the ACL. Rules are applied to the traffic in the order they appear in the ACL (from the top, which is the first rule, downward). The first rule that matches traffic is used to permit or deny that traffic. After the first rule match, no additional rules are compared against the traffic. Access lists do not take effect until you apply them. • To permit or block through traffic on an interface, apply the ACL to the

interface. (See “Applying an ACL to an Interface” on page 407.) • To permit or block management access, use the ACL with the enable-

management command. (See “Securing Admin Access by Ethernet” on page 333.) • To specify the internal host or subnet addresses to which to provide

NAT, use the ACL when configuring the pool. (See “Network Address Translation” on page 293.)

394 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) • To permit or block through traffic on a virtual server port, apply the

ACL to the virtual port. (See “Applying an ACL to a Virtual Server Port” on page 408.) Note:

ACL use on virtual ports is supported only in software releases that support SLB.

Configuring Standard IPv4 ACLs To configure a standard IPv4 ACL, use either of the following methods.

USING THE GUI 1. Select Config > Network > ACL. 2. Select Standard on the menu bar. 3. Click Add. 4. Enter or select the values to filter. (For descriptions, see the CLI syntax below.) 5. Click OK. The new ACL appears in the Standard ACL table. 6. Click OK to commit the change.

USING THE CLI To configure a standard ACL, use the following command: access-list acl-num [seq-num] {permit | deny | remark string} source-ipaddr {filter-mask | /mask-length} [log [transparent-session-only]] The acl-num specifies the ACL number, from 1-99. The seq-num option specifies the sequence number of this rule in the ACL. (See “Resequencing ACL Rules” on page 410.) The deny | permit option specifies the action to perform on traffic that matches the ACL: • deny – Drops the traffic. • permit – Allows the traffic.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

395 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) The remark option adds a remark to the ACL. (For more information, see “Adding a Remark to an ACL” on page 405.) The source address to match on is specified by one of the following: • any – The ACL matches on all source IP addresses. • host host-src-ipaddr – The ACL matches only on the specified host IP

address. • net-src-ipaddr {filter-mask | /mask-length} – The ACL matches on any

host in the specified subnet. The filter-mask specifies the portion of the address to filter: • Use 0 to match. • Use 255 to ignore. For example, the following filter-mask filters on a 24-bit subnet: 0.0.0.255 Alternatively, you can use mask-length to specify the portion of the address to filter. For example, you can specify “/24” instead “0.0.0.255” to filter on a 24-bit subnet. The log option configures the AX device to generate log messages when traffic matches the ACL. This option is disabled by default. The transparent-session-only option limits logging for an ACL rule to creation and deletion of transparent sessions for traffic that matches the ACL rule. (See “Transparent Session Logging” on page 405.) When ACL logging is enabled, the AX device writes the log messages to the local logging buffer. If you configure an external log server, the AX device also sends the messages to the server. For more information, see “Log Rate Limiting” on page 50. Note:

If you plan to use an external log server, the server must be attached to an AX data port in order for ACL logging messages to reach the server. They will not reach the server if the server is attached to the AX management port.

CLI EXAMPLE The following commands configure a standard ACL to deny traffic sent from subnet 10.10.10.x, and apply the ACL to inbound traffic received on Ethernet interface 4: AX(config)#access-list 1 deny 10.10.10.0 0.0.0.255 AX(config)#interface ethernet 4 AX(config-if:ethernet4)#access-list 1 in

396 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs)

Configuring Extended IPv4 ACLs To configure an extended IPv4 ACL, use either of the following methods.

USING THE GUI 1. Select Config > Network > ACL. 2. Select Extended on the menu bar. 3. Click Add. 4. Enter or select the values to filter. (For descriptions, see the CLI syntax below.) 5. Click OK. The new ACL appears in the Extended ACL table. 6. Click OK to commit the change.

USING THE CLI To configure an extended ACL, use the following commands. Syntax for Filtering on Source and Destination IP Addresses [no] access-list acl-num [seq-num] {permit | deny | l3-vlan-fwd-disable | remark string} ip {any | host host-src-ipaddr | net-src-ipaddr {filter-mask | /mask-length}} {any | host host-dst-ipaddr | net-dst-ipaddr {filter-mask | /mask-length}} [fragments] [vlan vlan-id] [dscp num] [log [transparent-session-only]] The acl-num specifies the ACL number, from 100-199. The seq-num option specifies the sequence number of this rule in the ACL. (See “Resequencing ACL Rules” on page 410.)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

397 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) The deny | permit option specifies the action to perform on traffic that matches the ACL: • deny – Drops the traffic. • permit – Allows the traffic.

The remark option adds a remark to the ACL. (For more information, see “Adding a Remark to an ACL” on page 405.) The source address to match on is specified by one of the following: • any – The ACL matches on all source IP addresses. • host host-src-ipaddr – The ACL matches only on the specified host IP

address. • net-src-ipaddr {filter-mask | /mask-length} – The ACL matches on any

host in the specified subnet. The filter-mask specifies the portion of the address to filter: • Use 0 to match. • Use 255 to ignore. For example, the following filter-mask filters on a 24-bit subnet: 0.0.0.255 Alternatively, you can use mask-length to specify the portion of the address to filter. For example, you can specify “/24” instead “0.0.0.255” to filter on a 24-bit subnet. The options for specifying the destination address are the same as those for specifying the source address. The fragments option matches on packets in which the More bit in the header is set (1) or has a non-zero offset. The vlan option matches on the specified VLAN. VLAN matching occurs for incoming traffic only. The dscp option matches on the 6-bit Diffserv value in the IP header, 1-63. The established option matches on TCP packets in which the ACK or RST bit is not set. This option is useful for protecting against attacks from outside. Since a TCP connection from the outside does not have the ACK bit set (SYN only), the connection is dropped. Similarly, a connection established from the inside always has the ACK bit set. (The first packet to the network from outside is a SYN/ACK.) The log option configures the AX device to generate log messages when traffic matches the ACL. This option is disabled by default. The transpar-

398 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) ent-session-only option limits logging for an ACL rule to creation and deletion of transparent sessions for traffic that matches the ACL rule. (See “Transparent Session Logging” on page 405.) When ACL logging is enabled, the AX device writes the log messages to the local logging buffer. If you configure an external log server, the AX device also sends the messages to the server. For more information, see “Log Rate Limiting” on page 50. Note:

If you plan to use an external log server, the server must be attached to an AX data port in order for ACL logging messages to reach the server. They will not reach the server if the server is attached to the AX management port. Syntax for Filtering on ICMP Traffic [no] access-list acl-num [seq-num] {permit | deny | l3-vlan-fwd-disable | remark string} icmp [type icmp-type [code icmp-code]] {any | host host-src-ipaddr | net-src-ipaddr {filter-mask | /mask-length}} {any | host host-dst-ipaddr | net-dst-ipaddr {filter-mask | /mask-length}} [fragments] [vlan vlan-id] [dscp num] [log [transparent-session-only]] The type and code options enable you to filter on ICMP traffic. The type type-option option matches based on the specified ICMP type. You can specify one of the following. Enter the type name or the type number (for example, dest-unreachable or 3). The type-option can be one of the following: • any-type – Matches on any ICMP type. • dest-unreachable | 3 – Type 3, destination unreachable • echo-reply | 0 – Type 0, echo reply • echo-request | 8 – Type 8, echo request • info-reply | 16 – Type 16, information reply • info-request | 15 – Type 15, information request

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

399 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) • mask-reply | 18 – Type 18, address mask reply • mask-request | 17 – Type 17, address mask request • parameter-problem | 12 – Type 12, parameter problem • redirect | 5 – Type 5, redirect message • source-quench | 4 – Type 4, source quench • time-exceeded | 11 – Type 11, time exceeded • timestamp | 13 – Type 13, timestamp • timestamp-reply | 14 – Type 14, timestamp reply • type-num – ICMP type number, 0-254

The code code-num option matches based on the specified ICMP code. To match on any ICMP code, specify any-code. To match on a specific ICMP code, specify the code, 0-254. Syntax for Filtering on Source and Destination IP Addresses and on TCP or UDP Protocol Port Numbers [no] access-list acl-num [seq-num] {permit | deny | l3-vlan-fwd-disable | remark string} {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] [fragments] [vlan vlan-id] [dscp num] [established] [log [transparent-session-only]]

400 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) The tcp and udp options enable you to filter on protocol port numbers. Use one of the following options to specify the source port(s) on which to filter: • eq src-port – The ACL matches on traffic from the specified source

port. • gt src-port – The ACL matches on traffic from any source port with a

higher number than the specified port. • lt src-port – The ACL matches on traffic from any source port with a

lower number than the specified port. • range start-src-port end-src-port – The ACL matches on traffic from

any source port within the specified range. The same options can be used to specify the destination port(s) on which to filter.

CLI EXAMPLE The following commands configure an extended IPv4 ACL to deny traffic sent from subnet 10.10.10.x to 10.10.20.5:80, and apply the ACL to inbound traffic received on Ethernet interface 7: AX(config)#access-list 100 deny tcp 10.10.10.0 0.0.0.255 10.10.20.5 /32 eq 80 AX(config)#interface ethernet 7 AX(config-if:ethernet7)#access-list 100 in

Configuring Extended IPv6 ACLs To configure an extended IPv4 ACL, use either of the following methods.

USING THE GUI 1. Select Config > Network > ACL. 2. Select IPv6 on the menu bar. 3. Click Add. 4. Enter or select the values to filter. (For descriptions, see the CLI syntax below.) 5. Click OK. The new ACL appears in the IPv6 ACL table. 6. Click OK to commit the change.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

401 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs)

USING THE CLI To configure an IPv6 ACL, use the following commands: [no] ipv6 access-list name Enter this command at the global configuration level of the CLI. The name can be a string up to 16 characters long. This command changes the CLI to the configuration level for the ACL, where the following ACL-related commands are available. The permit | deny Command This command specifies the action to take for traffic that matches the ACL, specifies the source and destination addresses upon which to perform the action, and optionally, enables logging. [no] [seq-num] {permit | deny} {ipv6 | icmp} {any | host host-src-ipv6addr | net-src-ipv6addr /mask-length} {any | host host-dst-ipv6addr | net-dst-ipv6addr /mask-length} [fragments] [vlan vlan-id] [dscp num] [log [transparent-session-only]] or [no] {permit | deny} {tcp | udp} {any | host host-src-ipv6addr | net-src-ipv6addr /mask-length} [eq src-port | gt src-port | lt src-port | range start-src-port end-src-port] {any | host host-dst-ipv6addr | net-dst-ipv6addr /mask-length} [eq dst-port | gt dst-port | lt dst-port | range start-dst-port end-dst-port] [fragments] [vlan vlan-id] [dscp num] [established] [log [transparent-session-only]]

402 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) Parameter

Description

seq-num

Sequence number of this rule in the ACL. You can use this option to resequence the rules in the ACL.

deny | permit

Action to take for traffic that matches the ACL. deny – Drops the traffic. permit – Allows the traffic.

ipv6 | icmp

Filters on IPv6 or ICMP packets.

tcp | udp

Filters on TCP or UDP packets. The tcp and udp options enable you to filter on protocol port numbers.

any | host host-srcipv6addr | net-srcipv6addr /masklength Source IP address(es) to filter. any – The ACL matches on all source IP addresses. host host-src-ipv6addr – The ACL matches only on the specified host IPv6 address. net-src-ipv6addr /mask-length – The ACL matches on any host in the specified subnet. The mask-length specifies the portion of the address to filter. eq src-port | gt src-port | lt src-port | range startsrc-port end-src-port

For tcp or udp, the source protocol ports to filter. eq src-port – The ACL matches on traffic from the specified source port. gt src-port – The ACL matches on traffic from any source port with a higher number than the specified port. lt src-port – The ACL matches on traffic from any source port with a lower number than the specified port.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

403 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) range start-src-port end-src-port – The ACL matches on traffic from any source port within the specified range. any | host host-dstipv6addr | net-dstipv6addr /masklength Destination IP address(es) to filter. eq dst-port | gt dst-port | lt dst-port | range startdst-port end-dst-port

For tcp or udp, the destination protocol ports to filter.

fragments

Matches on packets in which the More bit in the header is set (1) or has a non-zero offset.

vlan vlan-id

Matches on the specified VLAN. VLAN matching occurs for incoming traffic only.

dscp num

Matches on the 6-bit Diffserv value in the IP header, 1-63.

established

Matches on TCP packets in which the ACK or RST bit is not set. This option is useful for protecting against attacks from outside. Since a TCP connection from the outside does not have the ACK bit set (SYN only), the connection is dropped. Similarly, a connection established from the inside always has the ACK bit set. (The first packet to the network from outside is a SYN/ACK.)

log [transparentsession-only]

Configures the AX device to generate log messages when traffic matches the ACL. The transparent-session-only option limits logging for an ACL rule to creation and deletion of transparent sessions for traffic that matches the ACL rule. (See “Transparent Session Logging” on page 405.)

404 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) The remark Command The remark command adds a remark to the ACL. The remark appears at the top of the ACL when you display it in the CLI. Here is the syntax: [no] remark string The string can be 1-63 characters. To use blank spaces in the remark, enclose the entire remark string in double quotes.

Adding a Remark to an ACL You can add a remark to an ACL. The remark appears at the top of the ACL when you display it in the CLI, or next to the ACL in the ACL tables displayed in the GUI. Here is a CLI example: AX(config)#access-list 42 permit host 192.168.1.42 AX(config)#access-list 42 deny 192.168.1.0 /24 AX(config)#access-list 42 remark "The meaning of life" AX(config)#show access-list ipv4 42 Access List 42 "The meaning of life" access-list 42 10 permit host 192.168.1.42 access-list 42 20 deny 192.168.1.0 0.0.0.255

Hits: 0 Hits: 0

As shown in this example, the remark appears at the top of the ACL, above the first rule. To use blank spaces in the remark, enclose the entire remark string in double quotes, as shown in the example. The ACL must already exist before you can configure a remark for it.

Transparent Session Logging The transparent-session-only option limits logging for an ACL rule to creation and deletion of transparent sessions for traffic that matches the ACL rule. A transparent session is a non-SLB Layer 2 or Layer 3 session that the AX device sets up for traffic that is transiting through the AX device, but is not initiated or terminated on the device.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

405 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs)

Sample Log Messages for Transparent Sessions The following sections show examples of the log messages generated for transparent sessions. IPv4 Sessions The following example shows the log messages for creation and deletion of an IPv4 transparent session: Oct 29 2009 12:00:55 Notice [AX]:[eth 1] TCP 200.200.200.100:32548 > 1.1.1.100:80 ACL rule transparent session expired (ACL 150) Oct 29 2009 12:00:55 Notice [AX]:[eth 1] TCP 200.200.200.100:32548 > 1.1.1.100:80 ACL rule transparent session created (ACL 150)

The interface on which the ACL matched traffic is indicated in brackets (in this example, “eth 1”). The addresses are shown as src-ip:port > dst-ip:port. The ACL number or ACL name is shown at the end of the message. IPv6 Sessions For successfully created TCP or UDP sessions, a separate message is generated when the session is created and when it expires: Feb 24 2010 02:18:27 Notice [AX]:[ve 21] UDP 2001:10::100:50213 > 2001:7::40:53 ACL rule transparent session expired (IPV6_LIST) Feb 24 2010 02:18:12 Notice [AX]:[ve 21] UDP 2001:10::100:50213 > 2001:7::40:53 ACL rule transparent session created (IPV6_LIST) Feb 24 2010 02:15:12 Notice [AX]:[ve 21] TCP 2001:10::100:4401 > 2001:7::40:22 ACL rule transparent session expired (IPV6_LIST) Feb 24 2010 02:15:08 Notice [AX]:[ve 21] TCP 2001:10::100:4401 > 2001:7::40:22 ACL rule transparent session created (IPV6_LIST)

For all other types of transparent IPv6 sessions, a message is generated if the packet is forwarded: Feb 24 2010 02:18:07 Notice [AX]:[ve 21] IP 2001:10::100 > 2001:7::40 rule permitted this packet (IPV6_LIST)

ACL

If a TCP or UDP packet is denied, a message such as the following is generated: Feb 24 2010 02:18:07 Notice [AX]:[ve 21] TCP 2001:10::100:57373 > 2001:7::40:80 ACL rule transparent session denied (IPV6_LIST)

For all other types of transparent IPv6 sessions, a message such as the following is generated: Feb 24 2010 02:18:07 Notice [AX]:[ve 21] IP 2001:10::100 > 2001:7::40 rule denied this packet (IPV6_LIST)

406 of 486

ACL

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs)

Configuration To configure session filtering for transparent IPv6 sessions on an interface: 1. Configure an IPv6 ACL that uses the log transparent-session-only option. 2. Apply the ACL to the interface that receives incoming traffic for the sessions. 3. For the following AX models only, enable the cpu-process option on the interface that receives incoming traffic for the sessions: 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. CLI Example The following commands configure an IPv6 ACL for transparent session logging, and apply it to an IPv6 interface: AX(config)#ipv6 access-list tran_sess_log1 AX(config-access-list:trans_sess_log1)#permit tcp any any log transparent-session-only AX(config-access-list:trans_sess_log1)#exit AX(config)#interface ve 21 AX(config-if:ve21)#ipv6 access-list tran_sess_log1 in

Applying an ACL to an Interface To apply a configured ACL to an interface, use either of the following methods.

USING THE GUI To apply an ACL to an Ethernet port: 1. Select Config > Network > Interface. 2. Select LAN on the menu bar. 3. Click on the port number. 4. In the IPv4 section, select the ACL from the Access List field. 5. Click OK.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

407 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) To apply an ACL to a Virtual Ethernet (VE) interface: 1. Select Config > Network > Interface. 2. Select Virtual on the menu bar. 3. Click on the VE name. 4. Select IPv4. 5. Select the ACL from the Access List field. 6. Click OK.

USING THE CLI Access the configuration level for the interface and use one of the following commands: [no] access-list acl-num in [no] ipv6 access-list name in The following commands configure a standard IPv4 ACL to deny traffic from subnet 10.10.10.x, and apply the ACL to the inbound traffic direction on Ethernet interface 4: AX(config)#access-list 1 deny 10.10.10.0 0.0.0.255 AX(config)#interface ethernet 4 AX(config-if:ethernet4)#access-list 1 in

Applying an ACL to a Virtual Server Port You can apply an ACL to a virtual server port. An ACL applied to a virtual server port permits or denies traffic just as an ACL applied to a physical port or Virtual Ethernet (VE) interface does. Note:

ACL use on virtual ports is supported only in software releases that support SLB. To apply a configured ACL to a virtual server port, use either of the following methods.

USING THE GUI 1. Select Config > Service > SLB. 2. Select Virtual Server on the menu bar.

408 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) 3. Click Add or click on the name of a configured virtual server. 4. Enter or change information in the General section, if you are configuring a new virtual server. 5. In the Port section, click Add or select a port and click Edit. 6. In the Virtual Server Port section, select the ACL from the Access List drop-down list. 7. Click OK. 8. Click OK again to return to the virtual server table.

USING THE CLI To apply an ACL to a virtual port in the CLI, use the following command at the configuration level for the virtual port: [no] access-list {acl-num | name acl-name} The acl-num option specifies an IPv4 ACL. The name acl-name option specifies the name of an IPv6 ACL.

Using an ACL to Control Management Access To use an ACL to control management access, see “Securing Admin Access by Ethernet” on page 333.

Using an ACL for NAT To use an ACL for NAT, configure the ACL, then use either of the following methods to bind the ACL to a NAT pool.

USING THE GUI To bind an ACL to an IP source NAT pool: 1. Select Config > Service > IP Source NAT. 2. Select Binding on the menu bar. 3. Select the ACL number from the ACL drop-down list.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

409 of 486

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) 4. Select the pool ID from the NAT Pool drop-down list. 5. Click Add. The new binding appears in the ACL section. 6. Click OK.

USING THE CLI To use a configured ACL in an IPv4 NAT pool, use the following command: [no] ip nat inside source {list acl-name {pool pool-name | pool-group pool-group-name} static local-ipaddr global-ipaddr} The list acl-name option specifies the ACL.

Resequencing ACL Rules An ACL can contain multiple rules. Each access-list command configures one rule. Rules are added to the ACL in the order you configure them. The first rule you add appears at the top of the ACL. Rules are applied to the traffic in the order they appear in the ACL (from the top rule, which is the first, downward). The first rule that matches traffic is used to permit or deny that traffic. After the first rule match, no additional rules are compared against the traffic. Each ACL has an implicit deny any rule at the end of the ACL. This rule is applied to any traffic that does not match any of the configured rules in the ACL. The deny any rule at the end of the ACL is not displayed and cannot be removed. You can resequence the rules in an ACL. When you create an ACL rule, the AX device assigns a sequence number to the rule and places the rule at the bottom of the ACL. Here is an example: AX(config)#access-list 86 permit host 10.10.10.12 AX(config)#access-list 86 deny 10.10.10.0 /24 AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0

In this example, two rules are configured for ACL 86. The default sequence numbers are used. The first rule has sequence number 10, and each rule after that has a sequence number that is higher by 10.

410 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Access Control Lists (ACLs) The intent of this ACL is to deny all access from the 10.10.10.x subnet, except for access from specific host addresses. In this example, the permit rule for the host appears before the deny rule for the subnet the host is in, so the host will be permitted. However, suppose another permit rule is added for another host in the same subnet. AX(config)#access-list 86 permit host 10.10.10.13 AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0 access-list 86 30 permit host 10.10.10.13 log Hits: 0

By default, since no sequence number was specified when the rule was configured, the rule is placed at the end of the ACL. Because the deny rule comes before the permit rule, host 10.10.10.13 will never be permitted. To resequence the ACL to work as intended, the deny rule can be deleted, then re-added. Alternatively, either the deny rule or the second permit rule can be resequenced to appear in the right place. To change the sequence number of an ACL rule, delete the rule, then re-add it with the sequence number. AX(config)#no access-list 86 30 AX(config)#access-list 86 11 permit host 10.10.10.13 log AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 11 permit host 10.10.10.13 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0

In this example, rule 30 is deleted, then re-added with sequence number 11. The ACL will now work as intended, and permit hosts 10.10.10.12 and 10.10.10.13 while denying all other hosts in the 10.10.10.x subnet. To permit another host, another rule can be added, sequenced to come before the deny rule. AX(config)#access-list 86 12 permit host 10.10.10.14 log AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 11 permit host 10.10.10.13 log Hits: 0 access-list 86 12 permit host 10.10.10.14 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

411 of 486

AX Series - System Configuration and Administration Guide Source-IP Based Connection Rate Limiting

USING THE GUI Each row in the Standard ACL and Extended ACL tables is a separate ACL rule. You can configure multiple rules in the same ACL. In this case, they still appear as separate rows, with the same ACL number. The AX device applies the ACL rules in the order they are listed, starting at the top of the table. The first rule that matches traffic is used to permit or deny that traffic. After the first rule match, no additional rules are compared against the traffic. If you need to re-order the ACL rules, you can do so by clicking the up or down arrows at the ends of the rows containing the ACL rules. Click OK to commit the changes.

USING THE CLI See the description above.

Source-IP Based Connection Rate Limiting Source-IP based connection rate limiting protects the system from excessive connection requests from individual clients. This feature can be enabled on a global basis. The feature applies only to SLB virtual ports. Note:

IP limiting provides a more robust version of the source-IP based connection rate limiting feature. For information, see the “IP Limiting” chapter in the AX Series Application Delivery and Server Load Balancing Guide.

Parameters Source-IP based connection rate limiting is configured using the following parameters: • TCP or UDP – Layer 4 protocol for the connections. • Connection limit – Maximum number of connection requests allowed

from a client, within the limit period. The connection limit can be 1-1000000. • Limit period – Interval to which the connection limit is applied. A client

is conforming to the rate limit if the number of new connection requests within the limit period does not exceed the connection limit.

412 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Source-IP Based Connection Rate Limiting The limit period can be one of the following: • 100 milliseconds (one tenth of a second) • 1000 milliseconds (one second) • Scope – Specifies whether the connection limit applies separately to

each virtual port, or is applied as an aggregate to all virtual ports. By default, the connection limit applies separately to each individual virtual port. (See “Deployment Considerations” on page 414 for more information.) • Exceed actions – Actions to take when the connection limit is exceeded.

All connection requests in excess of the connection limit that are received from a client within the limit period are dropped. This action is enabled by default when you enable the feature, and can not be disabled. You can enable one or both of the following additional exceed actions: • Logging – Generates a log message when a client exceeds the connection limit. • Lockout – Locks out the client for a specified number of seconds. During the lockout period, all connection requests from the client are dropped. The lockout period can be 1-3600 seconds (1 hour). There is no default. By default, logging and lockout are both disabled.

Log Messages The AX device generates two log messages per offending client, per client activity. The first message is generated the first time a client exceeds the connection limit. The message indicates the source (client) address and the destination address of the session. If lockout is configured, the message also indicates that the client is locked out. The second message is generated after the client activity for that period. This message indicates the number of times the client exceeded the connection limit. If lockout is enabled, the message also indicates the number of requests that were dropped during lockout. Message Examples – No Lockout Configured Here is an example of the pair of log messages generated by this feature for an offending client, if lockout is not configured. Mar 05 2009 14:55:59 Notice [AX]: UDP 53.12.3.82 > 51.1.1.2:53 nection rate limit dropped this packet Mar 05 2009 14:37:00 Notice [AX]: UDP 51.2.1.81 > 51.1.1.2:53 exceeded Connection rate limit in all (8654 times)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

Source IP ConSource IP

413 of 486

AX Series - System Configuration and Administration Guide Source-IP Based Connection Rate Limiting In this example, the session is between client 53.12.3.82 and destination 51.1.1.2:53. During this period of activity, 8654 of the requests from the client were sent after a connection limit had been exceeded, and were dropped. Message Examples – With Lockout Configured Here is an example of how the messages look if lockout is configured. Mar 05 2009 14:34:57 Notice [AX]: UDP 53.12.3.82 > 51.1.1.2:53 nection rate limit dropped this packet (locked out)

Source IP Con-

Mar 05 2009 14:37:00 Notice [AX]: UDP 51.2.1.81 > 51.1.1.2:53 Source IP exceeded Connection rate limit in all (897 times, 2342 times in lockout)

In this example, the session is between the same client and destination as the previous example. During this period of activity, 897 of the requests from the client were sent after a connection limit had been exceeded, and were dropped. An additional 2342 requests were dropped because they were received during the lockout.

Deployment Considerations The AX device internally uses a session to keep track of user activity. Currently, the AX device has a capacity of up to 16 million sessions. Up to 8 million of these sessions are available for tracking user activity. Depending on client profile and activity, as well as the number of virtual ports configured on the device, you might need to use the shared option to apply the connection limit to all virtual ports, instead of each individual port. The default is to apply the connection limit to each individual virtual port, which uses proportionally more sessions than the shared option. Recommendation for Logging If you plan to enable logging for this feature, A10 Networks recommends using an external log server. Log traffic can be heavy during an attack. Recommendations for DNS Load Balancing If you plan to use this feature with DNS load balancing, A10 Networks recommends the following: • Increase the maximum number of Layer 4 sessions. To increase the

maximum number of Layer 4 sessions the system can have, use the following CLI command at the global configuration level of the CLI: system resource-usage l4-session-count num The num option specifies the number of Layer 4 sessions.

414 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Source-IP Based Connection Rate Limiting • Use a short UDP aging time. To set a short UDP aging time, use the fol-

lowing command at the configuration level for the UDP template to which you plan to bind the DNS virtual port(s): aging short [seconds] The seconds option specifies the number of seconds to wait before terminating UDP sessions. If you omit the seconds option, sessions are terminated after the SLB maximum session life (MSL) time expires, after a request is received and sent out to the server. (The MSL timer is a globally configurable SLB option. For more information, see the AX Series CLI Reference or AX Series GUI Reference.)

Configuration Note:

The current release does not support configuration or monitoring of this feature using the GUI. To configure source-IP based connection rate limiting, use the following command at the global configuration level of the CLI: slb conn-rate-limit src-ip {tcp | udp} conn-limit per {100 | 1000} [shared] [exceed-action [log] [lock-out lockout-period]] The tcp | udp option specifies the Layer 4 protocol. The conn-limit option specifies the connection limit and can be 1-1000000. The per {100 | 1000} option specifies the limit period, either 100 milliseconds or 1000 milliseconds. The shared option specifies that the connection limit applies in aggregate to all virtual ports. If you omit this option, the limit applies separately to each virtual port. The exceed-action options enable optional exceed actions: • The log option enables logging. • The lock-out lockout-period option enables lockout. The lockout period

can be 1-3600 seconds (1 hour). To display statistics for this feature, use the following command: show slb conn-rate-limit src-ip statistics

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

415 of 486

AX Series - System Configuration and Administration Guide Source-IP Based Connection Rate Limiting To clear statistics for this feature, use the following command: clear slb conn-rate-limit src-ip statistics

Configuration Examples CLI Example 1 The following command allows up to 1000 TCP connection requests per one-second interval from any individual client. If a client sends more than 1000 requests within a given limit period, the client is locked out for 3 seconds. The limit applies separately to each individual virtual port. Logging is not enabled. AX(config)#slb conn-rate-limit src-ip tcp 1000 per 1000 exceed-action lock-out 3

CLI Example 2 The following command allows up to 2000 UDP connection requests per 100-millisecond interval. The limit applies to all virtual ports together. Logging is enabled but lockout is not enabled. AX(config)#slb conn-rate-limit src-ip udp 2000 per 100 shared exceed-action log

CLI Example 3 The following command allows up to 2000 UDP connection requests per 100-millisecond interval. The limit applies to all virtual ports together. Logging is enabled and lockout is enabled. If a client sends a total of more than 2000 requests within a given limit period, to one or more virtual ports, the client is locked out for 3 seconds. AX(config)#slb conn-rate-limit src-ip udp 2000 per 100 shared exceed-action log lock-out 3

Statistics The following commands display statistics for this feature, then reset the counters to 0 and verify that they have been reset: AX(config)#show slb conn-rate-limit src-ip statistics Threshold check count 1022000 Honor threshold

count 20532

Threshold exceeded count 1001408 Lockout drops 60 Log messages sent 20532 DNS requests re-transmitted

1000

No DNS response for request 1021000 AX(config)#clear slb conn-rate-limit src-ip statistics

416 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Source-IP Based Connection Rate Limiting AX(config)#show slb conn-rate-limit src-ip statistics Threshold check count 0 Honor threshold

count 0

Threshold exceeded count 0 Lockout drops 0 Log messages sent 0 DNS requests re-transmitted

0

No DNS response for request

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

417 of 486

AX Series - System Configuration and Administration Guide Source-IP Based Connection Rate Limiting

418 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring a Black/White List

Policy-Based SLB (PBSLB) AX Series devices allow you to “black list” or “white list” individual clients or client subnets. Based on actions you specify on the AX device, the AX will allow (white list) or drop (black list) traffic from specific client hosts or subnets in the list. For traffic that is allowed, you can specify the service group to use. You also can specify the action to perform (drop or reset) on new connections that exceed the configured connection threshold for the client address. For example, you can configure the AX to respond to DDoS attacks from a client by dropping excessive connection attempts from the client. You can apply PBSLB on a system-wide basis. In software releases that support Server Load Balancing (SLB), you also can apply PBSLB on individual virtual ports. Note:

If a connection limit is specified in a black/white list, the AX device does not support using the list for both system-wide PBSLB and for PBSLB on an individual virtual port. In this case, the AX device may increase the current connection counter more than once, resulting in a much lower connection limit than the configured value. To work around this issue, use separate black/white lists.

Configuring a Black/White List Client IP lists (black/white lists) can be configured on an external device and imported onto the AX device, or can be entered directly into the GUI. The actions to take on the addresses in the list are specified on the AX device. A black/white list can contain up to 8 million individual host addresses and up to 32,000 subnet addresses. For each IP address (host or subnet) in a black/white list, add a row using the following syntax: ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string] • The ipaddr is the host or subnet address of the client. • The network-mask is optional. The default is 32, which means the

address is a host address.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

419 of 486

AX Series - System Configuration and Administration Guide Configuring a Black/White List • The group-id is a number from 1 to 31 in a black/white list that identi-

fies a group of IP host or subnet addresses contained in the list. In a PBSLB policy template on the AX device, you can map the group to one of the following actions: • Drop the traffic • Reset the connection • Send the traffic to a specific service group The default group ID is 0, which means no group is assigned. • The #conn-limit specifies the maximum number of concurrent connec-

tions allowed from the client. By default, there is no connection limit. If you set it, the valid range is from 1 to 32767. On the AX, you can specify whether to reset or drop new connections that exceed this limit. The # is required only if you do not specify a group-id. Note:

The conn-limit is a coarse limit. The larger the number you specify, the coarser the limit will be. For example, if you specify 100, the AX device limits the total connections to exactly 100; however, if you specify 1000, the device limits the connections to not exceed 992. If the number in the file is larger than the supported maximum (32767), the parser will use the longest set of digits in the number you enter that makes a valid value. For example, if the file contains 32768, the parser will use 3276 as the value. As another example, if the file contains 111111, the parser will use 11111 as the value. • The ;comment-string is a comment. Everything to the right of the ; is

ignored by the AX device when it parses the file.

Example Black/White List Here is an example black/white list: 10.10.1.3 4; blocking a single host. 4 is the drop group 10.10.2.0/24 4; blocking the entire 10.10.2.x subnet 192.168.1.1/32 #20 ; 20 concurrent connections max, any group ok 192.168.4.69 2 20 ; assign to group 2, and allow 20 max

The first row assigns a specific host to group 4. On the AX device, the drop action will be assigned to this group, thus black listing the client. The second row black lists an entire subnet, by assigning it to the same group (4). The third row sets the maximum number of concurrent connections for a specific host to 20. The fourth row assigns a specific host to group 2 and specifies a maximum of 20 concurrent connections.

420 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring a Black/White List The AX device allows up to three parser errors when reading the file. However, after the third parser error, the device stops reading the file.

Note:

Dynamic Black/White-list Client Entries The AX device supports dynamic client entries. To configure this feature, add client address 0.0.0.0/0 (wildcard address) to the black/white list used by the system-wide PBSLB policy. When a client sends an HTTP or HTTPS connection request, the AX device checks the system-wide PBSLB policy’s black/white list for the client’s IP address. • If the list does not already have an entry for the client, the AX device

creates a dynamic entry for the client’s host address. • If the list already has a dynamic entry for the client, the AX device

resets the timeout value for the entry. (Dynamic entry aging is described below.) • If the list contains a static entry for the client’s host or subnet address,

the static entry is used instead. Here is an example of a wildcard address in a black/white list: 0.0.0.0/0 1 #20 In this example, all clients who do not match a static entry in the list will be assigned to group 1, and will be limited to 20 concurrent connections. The AX device supports up to 8 million dynamic client entries for systemwide PBSLB. Once this limit is reached, the AX device does not track connections or anomaly counters for additional clients.

Connection Limit for Dynamic Entries For dynamic entries in a system-wide PBSLB policy’s black/white list, the connection limit in the list applies to each individual client. In the example above, each client that has a dynamic entry in the black/white list will be allowed to have a maximum of 20 concurrent connections.

Aging of Dynamic Entries When the AX device creates a dynamic black/white list entry for a client, the device also sets the timeout for the entry. The timeout value for the

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

421 of 486

AX Series - System Configuration and Administration Guide Configuring System-Wide PBSLB dynamic entry decrements until the timeout reaches 0 or the client sends a new HTTP or HTTPS connection request. • If the client sends a new HTTP or HTTPS connection request, the time-

out is reset to its full value. • If the timeout reaches 0 and the client does not have any active connec-

tions, the dynamic entry is removed. However, if the client has an active connection, the dynamic entry is not removed until the client’s connection ends. You can set the timeout to 1-127 minutes. The default is 5 minutes. If client-lockup is enabled, the timeout for a locked up client does not begin decrementing until the lockup expires. (See “Client Lockup” on page 423.)

Wildcard Address Support in PBSLB Policies Bound to Virtual Ports Dynamic client entries are supported only for system-wide PBSLB policies. You can add a wildcard address (0.0.0.0/0) to a black/white list that is used by a virtual port’s PBSLB policy. The group ID and connection limit specified for the wildcard address will be applied to clients that do not match a static entry in the list. However, there are a few limitations: • The AX device does not create any dynamic entries in the list. • The connection limit applies collectively to all clients that do not have a

static entry in the list.

Configuring System-Wide PBSLB System-wide PBSLB policies provide options that are not available in policies applied to individual virtual ports: • Dynamic black/white-list client entries • Client lockup • IP anomaly checking and tracking, using IP anomaly filters

To configure a system-wide PBLSB policy, use the following commands at the global configuration level of the CLI: [no] system pbslb bw-list name This command specifies the name of the black/white list to use for the policy.

422 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring System-Wide PBSLB [no] system pbslb id id {drop | reset} [logging minutes] This command specifies the action to take for clients in a given group configured in the black/white list. • drop – Drops the connections. • reset – Resets the connections.

The logging option enables logging. The minutes option specifies how often messages can be generated. [no] system pbslb over-limit [reset] [lockup minutes] [logging minutes] This command specifies the action to take for clients who either exceed the connection limit specified in the black/white list, or exceed the threshold of any of the new IP anomaly filters. You can use one or both of the following options: • reset – Resets all new connection attempts from the client. If you omit

this option, new connection attempts are dropped instead. • lockup – Continues to apply the over-limit action to all new connection

attempts from the client, for the specified number of minutes. The logging option enables logging. The minutes option specifies how often messages can be generated. [no] system pbslb timeout minutes This command sets the timeout for dynamic black/white-list entries. You can specify 1-127 minutes. The default is 5 minutes. Note:

If the lockup option is used with the system pbslb over-limit command, aging of the dynamic entry for a locked up client begins only after the lockup expires. Client Lockup The over-limit rule in a system-wide PBSLB policy includes an optional lockup period. If the lockup period is configured, the AX device continues to enforce the over-limit action for the duration of the lockup. For example, if the over-limit action is drop and a client exceeds the connection limit specified in the black/white list, the AX device continues to drop all connection attempts from the client until the lockup expires.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

423 of 486

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports The lockup option is disabled by default. You can enable it by specifying a lockup period of 1-127 minutes. The dynamic black/white-list entry for a client does not age while the client is locked up. After the lockup ends, the timeout for the entry is reset to its full value and begins decrementing normally as described in “Aging of Dynamic Entries” on page 421.

Displaying and Clearing System-Wide PBSLB Information To display information for system-wide PBSLB, use the following commands: show pbslb system show pbslb client [ipaddr] To clear PBSLB information, use the following commands: clear pbslb system clear pbslb client [entry] If you omit the entry option, the statistics counters are cleared but the client entries themselves are not cleared. To also clear the client entries, use the entry option.

Configuring PBSLB for Individual Virtual Ports You can configure PBSLB parameters for virtual ports by configuring the settings directly on individual ports, or by configuring a PBSLB policy template and binding the template to individual virtual ports. Note:

This feature is supported only in software releases that support Server Load Balancing (SLB). To configure PBSLB: 1. Configure a black/white list, either remotely or on the AX device itself. 2. If you configure the list remotely, import the list onto the AX device. 3. Optionally, modify the sync interval for the list. The AX regularly synchronizes with the list to make sure the AX version is current.

424 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports 4. Configure PBSLB settings. You can configure the following settings directly on individual virtual ports, or configure a policy template and bind the template to virtual ports. • Specify the black/white list. • Optionally, map each group ID used in the list to one of the follow-

ing actions: • Send the traffic to a specific service group. • Reset the traffic. • Drop the traffic. • Optionally, change the action (drop or reset) the AX will perform on connections that exceed the limit specified in the list. • Optionally, if needed for your configuration, change client address matching from source IP matching to destination IP matching. Note:

These steps assume that the real servers, service groups, and virtual servers have already been configured.

USING THE GUI To Configure PBSLB Settings Using a Policy Template: 1. Select Config > Service > Template. 2. On the menu bar, select Application > PBSLB Policy. 3. Click Add. 4. In the Name field, enter a name for the template. 5. From the drop-down list below the Name field, select the black/white list or click “create” to create or import one. 6. If you clicked “create”, the PBSLB section appears. a. Enter or select the following information in the fields of the PBSLB section: • Name that will be used for the imported black/white list. • Location of the black/white list (Local or Remote). b. To create the list using a text entry field in the GUI, click Local. The Definition field appears. Copy-and-paste or type the black/white list.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

425 of 486

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports c. To import a list from a remote server, select Remote. Enter values for the following parameters: • Interval at which the AX device re-imports the list. This option ensures that changes to the list are automatically replicated on the AX device. • File transfer protocol to use. • IP address or hostname of the device where the list is located. • Path and filename of the list on the remote device. d. Click OK. The Policy section reappears. 7. To configure group options: a. Select the group from the Group ID drop-down list. b. Select one of the following from the Action drop-down list. • Drop – Drops new connections until the number of concurrent connections on the virtual port falls below the port’s connection limit. (The connection limit is set in the black/white list.) • Reset – Resets new connections until the number of concurrent connections on the virtual port falls below the connection limit. • service group name – Each of the service groups configured on the AX device is listed. • create – This option displays the configuration sections for creating a new service group. c. Optionally, enable logging. To change the logging interval, edit the number in the Period field. Logging generates messages to indicate that traffic matched the group ID. To generate log messages only when there is a failed attempt to reach a service group, select Log Failures only. Note:

If the Use default server selection when preferred method fails option is enabled on the virtual port, log messages will never be generated for server-selection failures. To ensure that messages are generated to log server-selection failures, disable the Use default server selection when preferred method fails option on the virtual port. This limitation does not affect failures that occur because a client is over their PBSLB connection limit. These failures are still logged. d. Click Add. The group settings appear in the PBSLB list. e. Repeat the steps above for each group. 8. Select the action to take when traffic exceeds the limit: Drop or Reset. 9. Optionally, to match destination traffic against the black/white list, instead of source traffic, select Use Destination IP.

426 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports 10. Click OK. The new policy appears in the PBSLB policy list. 11. To bind the PBSLB policy template to a virtual port: a. Select Config > Service > SLB. b. On the menu bar, select Virtual Server. c. Click on the virtual server name or click Add to create a new one. d. In the Port section, click Add, or select a virtual port and click Edit. e. In the Virtual Server Port section, select the PBSLB template from the Policy Template drop-down list. f. Click OK. g. Click OK again.

FIGURE 84

PBSLB Policy section

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

427 of 486

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports FIGURE 85 page

Config > Service > SLB > Virtual Server - Virtual Server Port

USING THE CLI To Import a Black/White List: Use the following command at the global configuration level of the CLI: bw-list name url [period seconds] [load] The name can be up to 31 alphanumeric characters long. The url specifies the file transfer protocol, directory path, and filename. The following URL format is supported: tftp://host/file

428 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports The period seconds option specifies how often the AX device re-imports the list to ensure that changes to the list are automatically replicated on the AX. You can specify 60 – 86400 seconds. The default is 300 seconds. The load option immediately re-imports the list to get the latest changes. Use this option if you change the list and want to immediately replicate the changes on the AX device, without waiting for the update period. Note:

A TFTP server is required on the PC and the TFTP server must be running when you enter the bw-list command.

Note:

If you use the load option, the CLI cannot accept any new commands until the load is completely finished. For large black/white lists, loading can take a while. Do not abort the load process; doing so can also interrupt periodic black/white-list updates. If you do accidentally abort the load process, repeat the command with the load option and allow the load to complete. To Configure PBSLB Settings Using a Policy Template: To configure a PBSLB template, use the following commands: [no] slb template policy template-name Enter this command at the global configuration level of the CLI. The command creates the template and changes the CLI to the configuration for the template, where the following PBSLB-related commands are available. [no] bw-list name file-name This command binds a black/white list to the virtual ports that use this template. [no] bw-list id id service {service-group-name | drop | reset} [logging [minutes] [fail]] This command specifies the action to take for clients in the black/white list: • id – Group ID in the black/white list. • service-group-name – Sends clients to the SLB service group

associated with this group ID on the AX device. • drop – Drops connections for IP addresses that are in the specified

group. • reset – Resets connections for IP addresses that are in the specified

group. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

429 of 486

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports • logging [minutes] [fail] – Enables logging. The minutes

option specifies how often messages can be generated. This option reduces overhead caused by frequent recurring messages. For example, if the logging interval is set to 5 minutes, and the PBSLB rule is used 100 times within a five-minute period, the AX device generates only a single message. The message indicates the number of times the rule was applied since the last message. You can specify a logging interval from 0 to 60 minutes. To send a separate message for each event, set the interval to 0. PBSLB rules that use the service service-group-name option also have a fail option for logging. The fail option configures the AX device to generate log messages only when there is a failed attempt to reach a service group. Messages are not generated for successful connections to the service group. The fail option is disabled by default. The option is available only for PBSLB rules that use the service service-group-name option, not for rules with the drop or reset option, since any time a drop or reset rule affects traffic, this indicates a failure condition. Logging is disabled by default. If you enable it, the default for minutes is 3. The AX device uses the same log rate limiting and load balancing features for PBSLB logging as those used for ACL logging. See “Log Rate Limiting” on page 50. Note:

If the def-selection-if-pref-failed option is enabled on the virtual port, log messages will never be generated for server-selection failures. To ensure that messages are generated to log server-selection failures, disable the def-selection-if-pref-failed option on the virtual port. This limitation does not affect failures that occur because a client is over their PBSLB connection limit. These failures are still logged. [no] bw-list over-limit {lockup min | logging min | reset} This command specifies the action to take for traffic that is over the limit. You can specify one or more of the following options: • lockup min – Continues to apply the over-limit action to all new con-

nection attempts from the client, for the specified number of minutes (1-127). • logging min – Generates a log message when traffic goes over the

limit. The min option specifies the log interval and can be 1-255 minutes. • reset – Resets new connections until the number of concurrent con-

nections on the virtual port falls below the connection limit.

430 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports [no] bw-list use-destination-ip This command matches black/white list entries based on the client’s destination IP address. By default, matching is based on the client’s source IP address. This option is applicable if you are using a wildcard VIP. (See the “Wildcard VIPs” chapter in the AX Series Application Delivery and Server Load Balancing Guide.) To bind the template to a virtual port, use the following command at the configuration level for the port: [no] template policy template-name To Configure PBSLB Settings Directly on a Virtual Port: To bind a black/white list to a virtual port, use the following command at the configuration level for the virtual port: pbslb bw-list name The name is the name you assign to the list when you import it. To map client IP addresses in a black/white list to specific service groups, use the following command at the configuration level for the virtual port: pbslb id id {service service-group-name | drop | reset} [logging [minutes] [fail]]] The id is a group ID in the black/white list and can be from 1 to 31. The service-group-name is the name of an SLB service group on the AX. The drop option immediately drops all connections between the clients in the list and any servers in the service group. The reset option resets the connections between the clients in the list and any servers in the service group. The logging option enables logging. The minutes option specifies how often messages can be generated. This option reduces overhead caused by frequent recurring messages. For example, if the logging interval is set to 5 minutes, and the PBSLB rule is used 100 times within a five-minute period, the AX device generates only a single message. The message indicates the number of times the rule was applied since the last message. You can specify a logging interval from 0 to 60 minutes. To send a separate message for each event, set the interval to 0. The default is 3 minutes. PBSLB rules that use the service service-group-name option also have a fail option for logging. The fail option configures the AX device to generate Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

431 of 486

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports log messages only when there is a failed attempt to reach a service group. Messages are not generated for successful connections to the service group. The fail option is disabled by default. The option is available only for PBSLB rules that use the service service-group-name option, not for rules with the drop or reset option, since any time a drop or reset rule affects traffic, this indicates a failure condition. The AX device uses the same log rate limiting and load balancing features for PBSLB logging as those used for ACL logging. See “Log Rate Limiting” on page 50. Note:

If the def-selection-if-pref-failed option is enabled on the virtual port, log messages will never be generated for server-selection failures. To ensure that messages are generated to log server-selection failures, disable the def-selection-if-pref-failed option on the virtual port. This limitation does not affect failures that occur because a client is over their PBSLB connection limit. These failures are still logged. To specify the action to take if the virtual port’s connection threshold is exceeded, use the following command at the configuration level for the virtual port: [no] bw-list over-limit {drop | reset} This command specifies the action to take for traffic that is over the limit. • drop – Drops new connections until the number of concurrent connec-

tions on the virtual port falls below the port’s connection limit. (The connection limit is set in the black/white list.) • reset – Resets new connections until the number of concurrent connec-

tions on the virtual port falls below the connection limit.The connection threshold is set in the black/white list.

Displaying PBSLB Information To show the configuration of a PBSLB policy template, use the following command: show slb template policy template-name To show client IP addresses contained in a black/white list, use the following command: show bw-list [name [detail | ipaddr]]

432 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuring PBSLB for Individual Virtual Ports The name is the name you assign to the list when you import it. The ipaddr is the client IP address. To show policy-based SLB statistics, use the following command: show pbslb [name] The name option specifies a virtual server name. If you use this option, statistics are displayed only for that virtual server. Otherwise, statistics are shown for all virtual servers.

CLI Configuration Examples The following commands import black/white list “sample-bwlist.txt” onto the AX device: AX(config)#bw-list sample-bwlist tftp://myhost/TFTP-Root/AX_bwlists/samplebwlist.txt AX(config)#show bw-list Name

Url

Size(Byte)

Date

-----------------------------------------------------------------------------sample-bwlist

tftp://myhost/TFTP-Root/AX_

N/A

N/A

bwlists/sample-bwlist.txt Total: 1

The following commands configure a PBSLB template and bind it to a virtual port: AX(config)#slb template policy bw1 AX(config-policy)#bw-list name bw1 AX(config-policy)#bw-list id 2 service srvcgroup2 AX(config-policy)#bw-list id 4 drop AX(config-policy)#exit AX(config)#slb virtual-server PBSLB_VS1 10.10.10.69 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#template policy bw1

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

433 of 486

AX Series - System Configuration and Administration Guide Configuration Example—Sockstress Attack Protection The following commands configure the same PBSLB settings directly on a virtual port: AX(config)#slb virtual-server PBSLB_VS2 10.10.10.70 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#pbslb bw-list sample-bwlist AX(config-slb virtual server-slb virtua...)#pbslb id 4 drop AX(config-slb virtual server-slb virtua...)#pbslb id 2 service srvcgroup2

The following commands shows PBSLB information: AX(config-slb virtual server-slb virtua...)#show pbslb Total number of PBSLB configured: 1 Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop) -----------------------------------------------------------------------------PBSLB_VS1

80

sample-bwlist

PBSLB_VS2

80

sample-bwlist

2

0

0

0

4

0

0

0

2

0

0

0

4

0

0

0

Configuration Example—Sockstress Attack Protection You can use system-wide PBSLB in combination with IP anomaly filters to protect against Sockstress attacks, a type of DDoS attack. In this example, the AX device drops all new connection attempts from a client if either of the following occurs: • The client already has 20 active connections and attempts to open a new

HTTP or HTTPS connection. • The client exceeds any of the IP anomaly thresholds.

The lockup period is set to 5 minutes, to continue enforcing the over-limit action for 5 minutes after the over-limit action is triggered. The timeout for dynamic black/white list entries is set to 2 minutes. This example uses the following black/white list: 0.0.0.0/0 1 #20

434 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration Example—Sockstress Attack Protection

System-wide PBSLB Policy Configuration The following commands configure the system-wide PBSLB policy: AX(config)#system pbslb bw-list bwlist-wc AX(config)#system pbslb over-limit lockup 5 AX(config)#system pbslb timeout 2

Configuring the system-wide PBSLB policy also automatically enables the new IP anomaly filters.

Statistics Display The following command shows system-wide statistics for the new IP anomaly filters: AX(config)#show slb l4 Total -----------------------------------------------------------------IP out noroute

20061

TCP out RST

0

TCP out RST no SYN

0

... Anomaly out of sequence 225408 Anomaly zero window

225361

Anomaly bad content

224639

The following command shows statistics for the system-wide PBSLB policy: AX(config)#show pbslb system System B/W list: bwlist-wc Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop) -------------------------------------------------------------------------------System bwlist-wc 1 12 0 0 2 0 0 0

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

435 of 486

AX Series - System Configuration and Administration Guide Configuration Example—Sockstress Attack Protection The following command shows summary statistics for individual black/ white-list clients: AX#show pbslb client GID = Group ID, S/D = Static or dynamic entry Out-s = Out of sequence, Zero-w = Zero window, Bad-c = Bad content IP

S/D GID Conn-limit Curr-conn Age

Lockup Out-s Zero-w Bad-c

------------------+---+---+----------+---------+-----+------+-----+------+---40.40.40.168

/32

D

1

20

5

120

0

0

5

5

40.40.40.169

/32

D

1

20

6

0

5

0

6

6

40.40.40.170

/32

D

1

20

6

0

5

0

6

6

40.40.40.171

/32

D

1

20

6

0

5

0

6

6

40.40.40.172

/32

D

1

20

6

0

5

0

6

6

40.40.40.173

/32

D

1

20

2

120

0

0

2

2

40.40.40.174

/32

D

1

20

5

120

0

0

5

5

40.40.40.175

/32

D

1

20

5

120

0

0

5

5

40.40.40.160

/32

D

1

20

5

120

0

0

5

5

40.40.40.161

/32

D

1

20

6

120

0

0

6

6

40.40.40.162

/32

D

1

20

6

0

5

0

6

6

40.40.40.163

/32

D

1

20

6

0

5

0

6

6

40.40.40.164

/32

D

1

20

6

0

5

0

6

6

40.40.40.165

/32

D

1

20

5

120

0

0

5

5

The Age column indicates how many seconds are left before a dynamic entry ages out. For clients who are currently locked out of the system, the value in the Lockup column indicates how many minutes the lockup will continue. For locked up clients, the age value is 0 until the lockup expires. After the lockup expires, the age is set to its full value (120 seconds in this example). The following command shows detailed statistics for a specific black/whitelist client: AX#show pbslb client 40.40.40.168 IP address:

40.40.40.168

Netmask length:

32

Type:

Dynamic

Group ID:

1

Connection limit (0 = no limit):

1984

Current connection:

6

Age:

0 second

Lockup time:

5 minute

Out of sequence:

0

Zero window:

6

Bad content:

6

436 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic

Specifying the Source Interface for Management Traffic By default, the AX 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

Using the Management Interface as the Source for Management Traffic By default, the AX device attempts to use a route from the main route table for management connections originated on the AX device. You can enable the AX device to use the management route table to initiate management connections instead. This section describes the AX 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 AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

437 of 486

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic You can configure the AX device to use the management interface as the source interface for automated management traffic. In addition, on a caseby-case basis, you can enable use of the management interface and management route table for various types of management connections to remote devices: The AX device automatically will use the management route table for reply traffic on connections initiated by a remote host that reaches the AX device on the management port. For example, this occurs for SSH or HTTP connections from remote hosts to the AX device. Note:

Static routes whose next hop is the management interface are duplicated in the management route table. Recommendation: Keep the Management and Data Interfaces in Separate Networks It is recommended to keep the management interface and the data interfaces in separate networks. If both tables have routes to the same destination 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 man-

agement route table. • show ip route or show ip fib – These commands display data plane

routes.

Management Routing Options You can configure the AX 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

438 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic sent through the management interface. Likewise, the management route table is used to find a route to the log server. The AX 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 AX 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 AX device after you downgrade. This can occur if you configure an external AAA server (TACACS+ server) to authorize CLI commands entered on the AX device, and the TACACS+ server is connected to the AX device through the management default gateway. If this is the case, before you downgrade, remove the TACACS+ configuration from the AX 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.

Enabling Use of the Management Interface as the 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 following command at the configuration level for the management interface: [no] ip control-apps-use-mgmt-port

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

439 of 486

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic Here is an example: AX(config-if:management)#ip control-apps-use-mgmt-port

Using the Management Interface as the Source Interface for Manually Generated Management Traffic To use the management interface as the source interface for manually generated management traffic, use the use-mgmt-port option. In the GUI, this option is provided as a Use Management Port checkbox on the applicable pages. In the CLI, this option is supported with the following commands.

Commands at the User EXEC Level ssh [use-mgmt-port] {host-name | ipaddr) login-name [protocol-port] telnet [use-mgmt-port] {host-name | ipaddr) [protocol-port]

Commands at the Privileged EXEC Level export {aflex | ssl-cert | ssl-key | axdebug} file-name [use-mgmt-port] url ssh [use-mgmt-port] {host-name | ipaddr) login-name [protocol-port] telnet [use-mgmt-port] {host-name | ipaddr) [protocol-port]

Commands at the Global Configuration Level backup {config | log} [use-mgmt-port] url [no] bw-list name [use-mgmt-port] url [period seconds] [load] copy {running-config | startup-config | from-profile-name} [use-mgmt-port] {url | to-profile-name [cf]} health external {delete program-name | import [use-mgmt-port] [description] url | export [use-mgmt-port] program-name url}

440 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic [no] restore [use-mgmt-port] url [no] slb ssl-load {certificate file-name | private-key file-name} [use-mgmt-port] url upgrade {cf | hd} {pri | sec} [use-mgmt-port] url

Show Commands show techsupport [[use-mgmt-port] export url] [page]

Using a Loopback Interface as the Source for Management Traffic You can configure the AX device to use a loopback interface IP address to be used as the source interface for management traffic originated by the device. You can enable use of a specific loopback interface as the source for one or more of the following management traffic types: • FTP • NTP • RCP • SNMP • SSH • SYSLOG • Telnet • TFTP • Web

FTP, RCP, and TFTP apply to file export and import, such as image upgrades and system backups. Telnet and SSH apply to remote login from the AX device to another device. They also apply to RADIUS and TACACS+ traffic. SSH also applies to file import and export using SCP. Web applies to GUI login.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

441 of 486

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic Notes • Loopback interface IP address – The loopback interface you specify

when configuring this feature must have an IP address configured on it. Otherwise, this feature does not take effect. • Management interface – If use of the management interface as the

source for management traffic is also enabled, the loopback interface takes precedence over the management interface. The loopback 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 management traffic does not apply to ping traffic. By default, ping packets are sourced from the best interface based on the AX route table. You can override the default interface selection by specifying a loopback or other type of interface as part of the ping command. (See the AX Series CLI Reference for syntax information.) • Layer 2/3 Virtualization – This feature is supported only for loopback

interfaces that belong to the shared partition. When this feature is 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 AX device to use a loopback interface as the source interface for management traffic, use the following command at the global configuration level of the CLI:

442 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic [no] ip mgmt-traffic {all | ftp | ntp | rcp | snmp | ssh | syslog | telnet | tftp | web} source-interface loopback num To apply the command only to a specific type of traffic (SNMP, NTP, and so on), use the option for that traffic type. To apply the command to all management traffic types, use the all option. CLI Example The following commands configure an IP address on loopback interface 2: AX(config)#interface loopback 2 AX(config-if:loopback2)#ip address 10.10.10.66 /24 AX(config-if:loopback2)#exit

The following command configures the AX device to use loopback interface 2 as the source interface for management traffic of all types listed above: AX(config)#ip mgmt-traffic all loopback 2

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

443 of 486

AX Series - System Configuration and Administration Guide Using the Management Interface as the Source for Management Traffic

444 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Storage Areas

Boot Options This chapter describes how to display or change the storage area from which the AX device boots. Note:

This chapter does not describe how to upgrade the system image. For upgrade instructions, see the release notes for the release to which you plan to upgrade.

Storage Areas The AX 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 86. FIGURE 86

Software Image Locations on the AX Device

The SSD or disk storage areas are used for normal operation. The compact flash storage areas are used only for system recovery. Normally, each time the AX 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 Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

445 of 486

AX Series - System Configuration and Administration Guide Storage Areas 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 AX device always uses the same storage area each time the device is rebooted. Note:

The AX 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 AX 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. This page lists the software image versions installed in each of the storage areas. FIGURE 87

Monitor > Overview > Summary

System Images

446 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Storage Areas Above the highlighted fields, the Startup Mode field lists the storage area used for the most recent reboot. The Software Version field lists the currently running software version.

USING THE CLI The show version command shows storage area information. The command also lists other information, including the currently running software version. AX#show version AX Series Advanced Traffic Manager AX3200 Copyright 2007-2011 by A10 Networks, Inc.

All A10 Networks products are

protected by one or more of the following US patents and patents pending: 7716378, 7675854, 7647635, 7552126, 20090049537, 20080229418, 20080040789, 20070283429, 20070271598, 20070180101 Advanced Core OS (ACOS) version 2.6.1-GR1, build 107 (Feb-27-2012,17:58) Booted from Hard Disk primary image Serial Number: AX32031107320021 Firmware version 7.11 aFleX version: 2.0.0 Hard Disk primary image (default) version 2.6.1-GR1, build 107 Hard Disk secondary image version 2.4.3, build 107 Compact Flash primary image (default) version 2.4.3, build 45 Compact Flash secondary image version 1.2.1, build 368 Last configuration saved at Jul-6-2002, 00:36 Hardware: 4 CPUs(Stepping 6), Dual 153G Hard disks Memory 4154 Mbyte, Free Memory 2685 Mbyte Current time is Jul-6-2002, 19:10 The system has been up 1 day, 22 hours, 43 minutes

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

447 of 486

AX Series - System Configuration and Administration Guide Storage Areas

Displaying the Storage Location for Future Reboots To display the storage area that will be used for the future reboots, use either of the following methods. The AX 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.

Note:

USING THE GUI Select Config > System > Settings > Boot.

USING THE CLI Use the following command: show bootimage In the following example, the AX device is configured to boot from the primary storage area on the SSD or disk: AX(config)#show bootimage (* = Default) Version ----------------------------------------------Hard Disk primary

2.6.1-GR1.107 (*)

Hard Disk secondary

2.4.3.107

Compact Flash primary

2.4.3.45 (*)

Compact Flash secondary

1.2.1.368

448 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Booting from a Different Storage Area

Booting from a Different Storage Area To reboot from a different storage area, do one of the following: • Interrupt the boot sequence and use the bootloader menu to temporarily

select the other storage area. • Configure the AX device to use the other storage area for all future

reboots, then reboot.

Temporarily Changing the Storage Location for the Next Reboot To temporarily change the storage location to use for a reboot, interrupt the boot sequence to access the bootloader menu. To access the bootloader menu, reboot the AX device, then press Esc within 3 seconds when prompted. When the bootloader menu appears, use the Up and Down arrow keys to select the image area from which to boot, and press Enter. The menu does not automatically time out. You must press Enter to reboot using the selected image. Caution:

Each storage area has its own version of the startup-config. When you save configuration changes, they are saved only to the startupconfig in the storage area from which the AX device was booted. If you plan to reboot from a different storage area, but you want to use the same configuration, first save the configuration to the other storage area. (The procedures in “Permanently Changing the Storage Location for Future Reboots” on page 450 include steps for this.)

Note:

The bootloader menu is available on new AX 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 AX Series CLI Reference for 2.6.1 or later.

AX#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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

449 of 486

AX Series - System Configuration and Administration Guide Booting from a Different Storage Area

# # ### # # ## # # # # # # # # # # # # # ####### # # # # # # # # # # ##### ###

# # ## # # # # # # # # # # # ## # #

###### ##### # # # # # # ##### # # # # # # ## # # # ## ## ###### # # #

#### # # # # # # # # ####

##### # # # # ##### # # # #

# # #### # # # #### #### # # # # # # # # # ####

Copyright 2005-2011 by A10 Networks, Inc. All A10 Networks products are protected by one or more of the following US patents and patents pending: 7716378, 7675854, 7647635, 7552126, 20090049537, 20080229418, 20080040789, 20070283429, 20070271598, 20070180101 ------------------------------------------------------------------0: AX ACOS (Primary Image) 1: AX 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 'AX ACOS (Secondary Image)' Please wait while the system boots... Booting........................[OK] AX 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:

450 of 486

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 Storage Location for the Next Reboot” on page 449. Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Booting from a Different Storage Area Caution:

Each storage area has its own version of the startup-config. When you save configuration changes, they are saved only to the startupconfig in the storage area from which the AX device was booted. If you plan to reboot from a different storage area, but you want to use the same configuration, first save the configuration to the other storage area. The procedures in this section include a step for this.

USING THE GUI 1. Save the configuration, by clicking the Save icon at the top of the GUI window. This step copies any unsaved configuration changes from the runningconfig to the startup-config. FIGURE 88

Save the Configuration

2. Copy the startup-config to the storage area you plan to use for the next reboot: a. Select Config > System > Config. b. Click one of the following: • Primary Startup – This option selects the startup-config in the primary storage area of the SSD or hard drive. Click this link if you plan to use the primary storage area for the next reboot. • Secondary Startup – This option selects the startup-config in the secondary storage area of the SSD or hard drive. Click this link if you plan to use the secondary storage area for the next reboot. The selected startup-config is displayed, in the Content field. c. Use the Copy From drop-down list to select the startup-config file that was used for the most recent reboot. This is the startup-config to which you saved configuration changes in step 1. The commands in the selected startup-config replace the commands that were 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

451 of 486

AX Series - System Configuration and Administration Guide Booting from a Different Storage Area 3. Change the storage area to use for booting: a. Select Config > System > Settings > Boot. b. Select Primary or Secondary. c. Click OK. Note:

You can select the storage area for the SSD or disk and for the compact flash. However, the AX 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.

USING THE CLI 1. Save the configuration, by entering the following command: write memory This step copies any unsaved configuration changes from the runningconfig 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 AX 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 AX 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 AX 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

452 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Booting from a Different Storage Area CLI Example In this example, the AX 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: AX(config)#show bootimage (* = Default) Version ----------------------------------------------Hard Disk primary

2.6.1-GR1.107 (*)

Hard Disk secondary

2.4.3.107

Compact Flash primary

2.4.3.45 (*)

Compact Flash secondary

1.2.1.368

The following commands save the configuration and copy it to the other storage area: AX(config)#write memory Building configuration... [OK] AX(config)#write memory secondary Building configuration... [OK]

The following commands configure the AX device to use the secondary storage area on the SSD or hard drive for future reboots, and verify the setting: AX(config)#bootimage hd sec Secondary image will be used if AX is booted from hard disk AX(config)#show bootimage (* = Default) Version ----------------------------------------------Hard Disk primary

2.6.1-GR1.107

Hard Disk secondary

2.4.3.107 (*)

Compact Flash primary

2.4.3.45 (*)

Compact Flash secondary

1.2.1.368

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

453 of 486

AX Series - System Configuration and Administration Guide Booting from a Different Storage Area

454 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Backing Up System Information

Configuration Management By default, when you click the Save button in the GUI or enter the write memory command in the CLI, all unsaved configuration changes are saved to the startup-config. The next time the AX device is rebooted, the configuration is reloaded from this file. In addition to these simple configuration management options, the AX 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 AX device itself. Note:

For information about managing configurations for separate partitions on an AX device configured for Role-Based Administration (RBA), see “Role-Based Administration with Layer 2/3 Virtualization” on page 155.

Note:

For information about synchronizing configuration information between AX 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) – “Configuration

Synchronization” on page 191 • Older implementation of HA – “Manually Synchronizing Configuration Information” on page 280 Note:

For upgrade instructions, see the release notes for the AX release to which you plan to upgrade.

Backing Up System Information The AX 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)

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

455 of 486

AX Series - System Configuration and Administration Guide Backing Up System Information

USING THE GUI 1. Select Config > 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 > Config – This option backs up only the specified configuration file. • Backup > Syslog – This option backs up the log entries in the AX 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 AX 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. In the Protocol drop-down list, select the file transfer protocol: FTP, TFTP, RCP, or SCP. b. If using FTP and the remote device does not use the default FTP port, change the port. c. In the Host field, enter the hostname or IP address of the remote device. d. In the Location field, enter the pathname. To change the system backup file from the default name (“backup_system.tar”), specify the new name at the end of the path. e. In the User and Password fields, enter the username and password required for write access to the remote device. f. Click OK.

456 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally

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 AX device’s syslog buffer. The url option specifies the file transfer protocol, username, and directory path. You can enter the entire URL on the command line or press Enter to display a prompt for each part of the URL. If you enter the entire URL and a password is required, you will still be prompted for the password. To enter the entire URL: • tftp://host/file • ftp://[user@]host[:port]/file • scp://[user@]host/file • rcp://[user@]host/file

Saving Multiple Configuration Files Locally The AX device has CLI commands that enable you to store and manage multiple configurations on the AX 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 AX 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 AX device. The configuration management commands described in this section enable you to do the following:

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

457 of 486

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally • 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 configuration, they are not saved in the configuration profiles. Changes to the enable password or to the admin username or password take effect globally, regardless of the values that were in effect when a given configuration profile was saved.

USING THE GUI You can use the Config > 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 > System > Config File. 2. Click on the configuration file name. Adding a Configuration File 1. Select Config > System > Config 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.

458 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally 5. Edit the file if required. 6. Click OK. Modifying a Configuration File 1. Select Config > System > Config File. 2. Click on the configuration file name. 3. Edit the file. 4. Click OK. Deleting a Configuration File 1. Select Config > System > Config File. 2. Select the checkbox next to each configuration file to delete. 3. Click Delete. Comparing Configuration Files 1. Select Config > System > Config File. 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 highlighted: • 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

459 of 486

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally

USING THE CLI To manage multiple locally stored configurations, use the following commands. All commands are available at the global configuration level of the CLI. write memory [primary | secondary | profile-name] [cf] | terminal This command replaces the configuration commands in the specified configuration profile with the commands in the running-config. If you enter write memory without additional options, the command replaces the configuration profile that is currently linked to by startup-config with the commands in the running-config. If startup-config is set to its default (linked to the configuration profile stored in the image area that was used for the last reboot), then write memory replaces the configuration profile in the image area with the running-config. If you enter write memory primary, the command replaces the configuration profile stored in the primary image area with the running-config. Likewise, if you enter write memory secondary, the command replaces the configuration profile stored in the secondary image area with the runningconfig. If you enter write memory profile-name, where profile-name is the name of a configuration profile, the AX device replaces the commands in the specified profile with the running-config. The cf option replaces the configuration profile in the specified image area (primary or secondary) on the compact flash rather than the hard disk. If you omit this option, the configuration profile in the specified area on the hard disk is replaced. The terminal option displays the running-config on the management terminal. show startup-config [all | profile-name] [cf] When entered without the all or profile-name option, this command displays the contents of the configuration profile that is currently linked to "startup-config". To display the contents of a different configuration profile, use the profile-name option. To display a list of the locally stored configuration profiles, use the all option.

460 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally The cf option displays the configuration profile in the specified image area (primary or secondary) on the compact flash rather than the hard disk. If you omit this option, the configuration profile in the specified area on the hard disk is displayed. If the all option is also used, the cf option displays all the configuration profiles stored on the compact flash. copy {running-config | startup-config | from-profile-name} {url | to-profile-name [cf]} The copy startup-config to-profile-name command copies the configuration profile that is currently linked to “startup-config” and saves the copy under the specified profile name. The copy running-config to-profile-name command copies the runningconfig and saves the copy under the specified profile name. The cf option copies the profile to the compact flash instead of the hard disk. Note:

Copying a profile from the compact flash to the hard disk is not supported. (The url option backs up the configuration to a remote device. See “Backing Up System Information” on page 455.) diff {startup-config | profile-name} {running-config | profile-name} Displays a side-by-side comparison of the commands in a pair of configurations. The diff startup-config running-config command compares the configuration profile that is currently linked to “startup-config” with the running-config. Similarly, the diff startup-config profile-name command compares the configuration profile that is currently linked to “startup-config” with the specified configuration profile. To compare a configuration profile other than the startup-config to the running-config, enter the configuration profile name instead of startup-config. To compare any two configuration profiles, enter their profile names instead of startup-config or running-config. In the CLI output, the commands in the first profile name you specify are listed on the left side of the terminal screen. The commands in the other profile that differ from the commands in the first profile are listed on the right

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

461 of 486

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally side of the screen, across from the commands they differ from. The following flags indicate how the two profiles differ: • – This command has different settings in the two profiles. • – This command is in the second profile but not in the first one. • – This command is in the first profile but not in the second one.

link startup-config {default | profile-name} [primary | secondary] [cf] This command links the “startup-config” token to the specified configuration profile. By default, “startup-config” is linked to “default”, which means the configuration profile stored in the image area from which the AX device most recently rebooted. This command enables you to easily test new configurations without replacing the configuration stored in the image area. The primary | secondary option specifies the image area. If you omit this option, the image area last used to boot is selected. The cf option links the profile to the specified image area in compact flash instead of the hard disk. The profile you link to must be stored on the boot device you select. For example, if you use the default boot device selection (hard disk), the profile you link to must be stored on the hard disk. If you specify cf, the profile must be stored on the compact flash. (To display the profiles stored on the boot devices, use the show startup-config all and show startup-config all cf commands.) After you link “startup-config” to a different configuration profile, configuration management commands that affect “startup-config” affect the linked profile instead of affecting the configuration stored in the image area. For example, if you enter the write memory command without specifying a profile name, the command saves the running-config to the linked profile instead of saving it to the configuration stored in the image area. Likewise, the next time the AX device is rebooted, the linked configuration profile is loaded instead of the configuration that is in the image area. To relink “startup-config” to the configuration profile stored in the image area, use the default option (link startup-config default). delete startup-config profile-name [cf]

462 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally This command deletes the specified configuration profile. The cf option deletes the profile from compact flash instead of the hard disk. Note:

Although the command uses the startup-config option, the command only deletes the configuration profile linked to “startup-config” if you enter that profile’s name. The command deletes only the profile you 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 AX device most recently rebooted).

CLI EXAMPLES The following command saves the running-config to a configuration profile named “slbconfig2”: AX(config)#write memory slbconfig2

The following command shows a list of the configuration profiles locally saved on the AX 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 AX device most recently rebooted. AX(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”: AX(config)#copy startup-config slbconfig3

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

463 of 486

AX Series - System Configuration and Administration Guide Saving Multiple Configuration Files Locally 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. AX(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 AX

(

!

(

clock timezone America/Tijuana

(

!

(

ntp server 10.1.11.100 1440

(

!

(

... !

(

interface ve 30

(

ip address 30.30.31.1 255.255.255.0 10.10.20.1 255.255.255.0

|

ip address

ipv6 address 2001:144:121:3::5/64 fc00:300::5/64

|

ipv6 address

!

(

!

( > 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”: AX(config)#link startup-config slbconfig3

The following command deletes configuration profile “slbconfig2”: AX(config)#delete startup-config slbconfig2

464 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Overview

VLAN-to-VLAN Bridging This chapter describes VLAN-to-VLAN bridging and how to configure it.

Overview VLAN-to-VLAN bridging allows an AX device to selectively bridge traffic among multiple VLANs. The AX device selectively forwards packets from one VLAN to another based on the VLAN-to-VLAN bridging configuration on the AX device. This feature allows the traffic flow between VLANs to be tightly controlled through the AX 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 AX devices deployed in transparent mode (Layer 2) or in gateway mode (Layer 3). Each VLAN to be bridged must be configured on the AX device. The normal rules for tagging apply: • If an interface belongs to only one VLAN, the interface can be

untagged. • If the interface belongs to more than one VLAN, the interface must be

tagged. Each VLAN can belong to only a single bridge VLAN group.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

465 of 486

AX Series - System Configuration and Administration Guide Configuration 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 AX 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 AX device’s interfaces to the VLAN. 2. Configure a bridge VLAN group. Add the VLANs to the group. If the AX 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 AX device is deployed in gateway mode, configure an IP address on the VE to place the AX 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 AX 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.

466 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration [no] router-interface ve num On an AX device deployed in gateway mode, this command adds the VE to the group. forward-all-traffic This command configures the AX 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 AX device deployed in transparent mode to forward IP traffic between VLANs 2 and 3. The following commands configure the VLANs: AX(config)#vlan 2 AX(config-vlan:2)#tagged ethernet 2 AX(config-vlan:2)#exit AX(config)#vlan 3 AX(config-vlan:3)#tagged ethernet 3 AX(config-vlan:3)#exit

The following commands configure the bridge VLAN group: AX(config)#bridge-vlan-group 1 AX(config-bridge-vlan-group:1)#vlan 2 to 3 AX(config-bridge-vlan-group:1)#exit

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

467 of 486

AX Series - System Configuration and Administration Guide Configuration CLI Example – Gateway Mode The commands in this section configure an AX 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: AX(config)#vlan 2 AX(config-vlan:2)#tagged ethernet 2 AX(config-vlan:2)#exit AX(config)#vlan 3 AX(config-vlan:3)#tagged ethernet 3 AX(config-vlan:3)#exit

The following commands configure the bridge VLAN group, which includes a VE: AX(config)#bridge-vlan-group 1 AX(config-bridge-vlan-group:1)#vlan 2 to 3 AX(config-bridge-vlan-group:1)#router-interface ve 1 AX(config-bridge-vlan-group:1)#exit

The following commands assign an IP address to the VE: AX(config)#interface ve 1 AX(config-if:ve1)#ip address 192.168.1.100 /24 AX(config-if:ve1)#exit

468 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide FIPS-Compliant and FIPS-Certified AX Models

FIPS Support The AX Series supports for Federal Information Processing Standards (FIPS). The following sections describe the FIPS support added in this release. • “FIPS-Compliant and FIPS-Certified AX Models” on page 469 • “FIPS Compliance for Hardware” on page 470 • “FIPS Compliance for SSL” on page 472 • “FIPS Compliance for Software” on page 473 • “Web Support for FIPS Compliance” on page 474 • “CLI Support for FIPS Compliance” on page 474 • “FIPS-compliant Web Server” on page 475

FIPS-Compliant and FIPS-Certified AX Models The following AX models are both FIPS-compliant and FIPS-certified, meaning that the entire AX appliance has been certified by NIST. This is in contrast to some vendors, which only certify their cryptographic cards but do not submit the entire appliance for FIPS 140-2 certification. • AX 2500 • AX 2600-GCF • AX 3000-GCF • AX 5100 (with 2 SSL modules) • AX 5200 (with 2 SSL modules)

Note:

The FIPS models listed above must be ordered and shipped directly from A10 Networks. Converting or upgrading a standard AX unit to a FIPS unit (through the field upgrade process) is not supported.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

469 of 486

AX Series - System Configuration and Administration Guide FIPS Compliance for Hardware

FIPS Compliance for Hardware To enhance device security and achieve FIPS-compliance, the AX hardware has the following changes beginning in AX Release 2.6.1-P1.

SSL Modules FIPS-compliant AX devices do not offer the option to add SSL modules (“cards”) in the expansion slots, because this would require a chassis that could be opened at the customer premises (which would violate the FIPS requirements). While standard AX Series models allow installation of SSL modules, the FIPS-compliant AX devices come with a preset number of SSL modules. There will be no option to upgrade the device by adding SSL modules at a later time.

Tamper-Proof Seals To enhance security, one or more tamper-evident labels* with a serial number and company ID are affixed to the AX chassis. (See Figure 89, “A10 FIPS-approved Tamper-proof Labels,” on page 471.) Tamper-evident seals are delicate and clearly indicate when the packaging has been deliberately altered or adulterated. Seals are affixed to the AX 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.

*.

470 of 486

Novavision A1579 labels

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide FIPS Compliance for Hardware FIGURE 89

A10 FIPS-approved Tamper-proof Labels

As shown in Figure 90, “Position of Tamper-proof Labels on AX 2500/ 2600/3000,” on page 471 and Figure 91, “Position of Tamper-proof Labels on AX 5100/5200,” on page 472, tamper-evident seals are affixed to the AX in the following locations: • On the fan units • On the expansion slots • On the power supply

FIGURE 90

Position of Tamper-proof Labels on AX 2500/2600/3000

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

471 of 486

AX Series - System Configuration and Administration Guide FIPS Compliance for SSL FIGURE 91

Position of Tamper-proof Labels on AX 5100/5200

Changes to AX 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 To enhance device security and achieve FIPS-compliance, the following SSL changes are in effect beginning with AX Release 2.6.1-P1: • Transport Layer Security (TLS), which is FIPS-compliant, is allowed,

but SSLv2 and SSLv3, which are not FIPS-compliant, are not 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.

472 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide FIPS Compliance for Software • Inside OpenSSL-FIPS1.2 there is an implementation of ANSI X931

RNG (inside the directory /FIPS). • When a random number is generated, the value is compared with the last

number that was generated to ensure they are not the same. • In client/server-SSL situations, the certificate that the AX receives must

meet the requirement of having at least 1024 bits and SHA-1 authentication. • To meet FIPS-compliance, the AX supports encryption of keys with a

length equal to or greater than 1024-bits.

FIPS Compliance for Software To enhance device security and achieve FIPS-compliance, the following system-level changes are in effect beginning with AX Release 2.6.1-P1:

Software Upgrade Image FIPS-compliant software upgrade images have a signature using HMAC. Software upgrades are allowed only when it is determined that the upgrade image is correct, after having been verified using the signature.

Ports While the USB ports have not been physically removed from the hardware, they have been disabled at the software level to enhance security.

RMAs In the event that a customer must return the AX device to A10 Networks using the standard Return Merchandise Authorization (RMA) process, the customer first must use the security-reset system command to destroy all encryption keys. Per FIPS requirements, the AX 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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

473 of 486

AX Series - System Configuration and Administration Guide Web Support for FIPS Compliance 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 AX 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 AX 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 AX device to A10 Networks so a factory reset of the password can be done.

Web Support for FIPS Compliance To achieve FIPS compliance, the following changes to the management GUI are in effect beginning with AX Release 2.6.1-P1: • Local user passwords must be greater than 6 characters.

In prior releases, AX devices had a minimum requirement that passwords be at least 3 characters long. FIPS-compliance 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 AX devices. • File transfers between the AX and an external server (from/to the AX

and an external server) must use the “SCP” (Secure Copy command) communication method. The following alternate file transfer methods are disable on FIPS-compliant devices: TFTP, FTP, RCP.

CLI Support for FIPS Compliance To achieve FIPS compliance, the following changes to the CLI are in effect beginning with AX Release 2.6.1-P1: • Telnet services are no longer available under the enable-management

service telnet command. • SSH 2.0 is FIPS-compliant (and therefore allowed). The RSA, DSA,

and Diffie-Hellman key exchange key sizes must be at least 1024 bits. • User passwords must be greater than 6 characters.

FIPS-compliance requires that passwords must be at least 6 characters

474 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide FIPS-compliant Web Server long. The default AX password has been changed from “a10” to “a10$pass” for FIPS-compliant AX devices. • File transfers between the AX and an external server must use the

“SCP” (Secure Copy command) communication method. The following file transfer methods are disabled: TFTP, FTP, RCP. • “Back door access”, or entering the serial number via the console or

management ports to reset the AX, is not supported.

FIPS-compliant Web Server The AX Series’ web server is FIPS-compliant. As part of this compliance, the following Cryptographic Algorithms are approved: • AES for encryption/decryption • 3DES for encryption/decryption • SHA-1 for hashing and for authentication of hashed messages • RSA for signing and verification, as well as encryption/decryption • X9.31 for RNG (Random Number Generator) • Transport Layer Security (TLS) 1.0. is the only FIPS-compliant crypto-

graphic protocol. SSL v2.0 and v3.0 are not FIPS-compliant and will not be supported.

Additional FIPS 140-2 requirements are described in the National Institute of Standards and Technology document: http://csrc.nist.gov/groups/STM/cmvp/standards.html#02

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

475 of 486

AX Series - System Configuration and Administration Guide FIPS-compliant Web Server

476 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Error Types Monitored by Automatic Recovery

Fail-safe Automatic Recovery Fail-safe automatic recovery detects critical hardware and software error conditions. The feature also automatically takes action to recover the system if any of these errors occurs, so that the AX device can resume service to clients. Fail-safe automatic recovery is disabled by default, for both hardware and software errors. You can enable the feature for hardware errors, software errors, or both.

Error Types Monitored by Automatic Recovery Fail-safe automatic recovery monitors and recovers from the following types of system error conditions.

Hardware Errors When fail-safe monitoring is enabled for hardware errors, the following types of errors are detected: • SSL processor stops working – Fail-safe is triggered if an SSL processor

stops working. • Compression processor stops working – Fail-safe is triggered if an

HTTP compression processor stops. • FPGA stops working – Fail-safe is triggered if either of these internal

queues stops working. If any of these types of errors occurs, the AX device captures diagnostic information, then reboots. Note:

FPGA hardware errors apply only to models that use FPGAs in hardware: AX 3400, AX 3200-12, AX 5200-11, AX 5200, and AX 5100.

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.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

477 of 486

AX Series - System Configuration and Administration Guide Recovery Timeout

Software Errors When fail-safe monitoring is enabled for software errors, the following types of errors are detected: • FPGA I/O buffer shortage – The number of free (available) packet buf-

fers is below the configured threshold. By default, at least 512 packet buffers must be free for new data. (Monitoring for this type of FPGA error is applicable to all AX models.) On AX 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 configured threshold. By default, at least 30 percent of the AX 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 forceself-standby command is not added to the running-config. If neither HA nor VRRP-A is enabled, fail-safe reloads the AX device.

Recovery Timeout The recovery timeout is the number of minutes the AX device waits after detecting one of the hardware or software errors above before recovering the system. • Recovery timeout for hardware errors – By default, the AX device

reboots as soon as it has gathered diagnostic information. Typically, this occurs within 1 minute of detection of the error (no timeout). You can change the recovery timeout for hardware errors to 1-1440 minutes. • Recovery timeout for software errors – Fail-safe waits for the system to

recover through normal operation, before triggering a recovery. The default recovery timeout for software errors is 3 minutes. You can change it to 1-1440 minutes.

478 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration

Configuration This section describes how to configure the fail-safe feature.

USING THE GUI This feature is not supported in the GUI for this release.

USING THE CLI To configure fail-safe automatic recovery, use the following command at the global configuration level of the CLI: [no] fail-safe { fpga-buff-recovery-threshold 256-buffer-units | hw-error-monitor-enable | hw-error-recovery-timeout minutes | session-memory-recovery-threshold percentage | sw-error-monitor-enable | sw-error-recovery-timeout minutes } Parameter fpga-buffrecoverythreshold 256-bufferunits

Description

Minimum required number of free (available) FPGA buffers. If the number of free buffers remains below this value until the recovery timeout, fail-safe software recovery is triggered. You can specify 1-10 units. Each unit contains 256 buffers. The default is 2 units (512 buffers).

hw-errormonitor-enable hw-errorrecoverytimeout minutes

Enables fail-safe monitoring and recovery for hardware errors. This is disabled by default.

Number of minutes fail-safe waits after a hardware error occurs to reboot the AX device. You can specify 1-1440 minutes. The default is 0 (not set).

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

479 of 486

AX Series - System Configuration and Administration Guide Configuration session-memoryrecoverythreshold percentage Minimum required percentage of system memory that must be free. If the amount of free memory remains below this value long enough for the recovery timeout to occur, fail-safe software recovery is triggered. You can specify 1-100 percent. The default is 30 percent. sw-errormonitor-enable

Enables fail-safe monitoring and recovery for software errors. This is disabled by default.

sw-errorrecoverytimeout minutes Number of minutes the software error condition must remain in effect before fail-safe occurs. – If the system resource that is low becomes free again within the recovery timeout period, failsafe allows the AX device to continue normal operation. Fail-safe recovery is not triggered. – If the system resource does not become free, then fail-safe recovery is triggered. Displaying Fail-safe Information To display fail-safe information, use the following command: show fail-safe {config | information} The config option displays the fail-safe configuration entered by you or other admins. The information option displays fail-safe settings and statistics. The output differs between models that use FPGAs in hardware and models that do not. (See “CLI Example” on page 481.) Note:

480 of 486

The config option displays the CLI commands only the for settings you configure. A fail-safe command that is still set to its default value does not appear in the output.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration CLI Example The following commands configure some fail-safe settings and verify the changes. AX3400(config)#fail-safe session-memory-recovery-threshold 30 AX3400(config)#fail-safe fpga-buff-recovery-threshold 2 AX3400(config)#fail-safe sw-error-recovery-timeout 3 AX3400(config)#show fail-safe config fail-safe session-memory-recovery-threshold 30 fail-safe fpga-buff-recovery-threshold 2 fail-safe sw-error-recovery-timeout 3

The following command shows fail-safe settings and statistics on an AX model that uses FPGAs in hardware: AX3400(config)#show fail-safe information Total Session Memory (2M blocks):

1012

Free Session Memory (2M blocks):

1010

Session Memory Recovery Threshold (2M blocks):

809

Total Configured FPGA Buffers (# of buffers):

4194304

Free FPGA Buffers in Domain 1 (# of buffers):

507787

Free FPGA Buffers in Domain 2 (# of buffers):

508078

Total Free FPGA Buffers (# of buffers):

1015865

FPGA Buffer Recovery Threshold (# of buffers):

256

Total System Memory (Bytes):

2020413440

Table 20 describes the fields in the command output. TABLE 20 show fail-safe information fields (FPGA models) Field Total Session Memory Free Session Memory Session Memory Recovery Threshold Total Configured FPGA Buffers

Description Total amount of the AX device’s memory that is allocated for session processing. Amount of the AX device’s session memory that is free for new sessions. Minimum percentage of session memory that must be free before fail-safe occurs. Total number of configured FPGA buffers the AX device has. These buffers are allocated when the AX device is booted. This number does not change during system operation. The FPGA device is logically divided into 2 domains, which each have their own buffers. The next two counters are for these logical FPGA domains.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

481 of 486

AX Series - System Configuration and Administration Guide Configuration TABLE 20 show fail-safe information fields (FPGA models) (Continued) Field Free FPGA Buffers in Domain 1 Free FPGA Buffers in Domain 2 Total Free FPGA Buffers FPGA Buffer Recovery Threshold Total System Memory

Description Number of FPGA buffers in Domain 1 that are currently free for new data. Number of FPGA buffers in Domain 2 that are currently free for new data. Total number of free FPGA buffers in both FPGA domains. Minimum number of packet buffers that must be free before fail-safe occurs. Total size the AX device’s system memory.

The following command shows fail-safe settings and statistics on an AX model that does not use FPGAs in hardware. (The FPGA buffer is an I/O buffer instead.) AX2500(config)#show fail-safe information Total Session Memory (2M blocks):

1018

Free Session Memory (2M blocks):

1017

Session Memory Recovery Threshold (2M blocks):

305

Total Configured FPGA Buffers (# of buffers):

2097152

Free FPGA Buffers (# of buffers):

2008322

FPGA Buffer Recovery Threshold (# of buffers):

1280

Total System Memory (Bytes):

4205674496

Table 21 describes the fields in the command output. TABLE 21 show fail-safe information fields (non-FPGA models) Field Total Session Memory Free Session Memory Session Memory Recovery Threshold Total Configured FPGA Buffers

482 of 486

Description Total amount of the AX device’s memory that is allocated for session processing. Amount of the AX device’s session memory that is free for new sessions. Minimum percentage of session memory that must be free before fail-safe occurs. Total number of configured FPGA buffers the AX device has. These buffers are allocated when the AX device is booted. This number does not change during system operation.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide Configuration TABLE 21 show fail-safe information fields (non-FPGA models) (Continued) Field Free FPGA Buffers FPGA Buffer Recovery Threshold Total System Memory

Description Number of FPGA that are free for new data. Minimum number of packet buffers that must be free before fail-safe occurs. Total size the AX device’s system memory.

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

483 of 486

AX Series - System Configuration and Administration Guide Configuration

484 of 486

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

AX Series - System Configuration and Administration Guide

Performance by Design Document No.: D-030-01-00-0024 - Ver. 2.6.1-GR1 4/18/2012

485 of 486

Performance by Design

Corporate Headquarters A10 Networks, Inc. 3 West Plumeria Dr San Jose, CA 95134 USA Tel: +1-408-325-8668 (main) Tel: +1-888-822-7210 (support – toll-free in USA) Tel: +1-408-325-8676 (support – direct dial) Fax: +1-408-325-8666 www.a10networks.com

© 2012 A10 Networks Corporation. All rights reserved.

486

More Documents from "Min Min"

Mon History
November 2019 50
Final Rate
April 2020 31
Air Mandalay
April 2020 30
Manual.pdf
June 2020 21