AX Config Guide v2 0 2-20091111

P e r f o r m a n c e b y D e s i g n
AX Series™ Advanced Traffic Manager

Configuration Guide
Document No.: D-030-01-00-0006
Ver. 2.0.2 11/11/2009
Headquarters
A10 Networks, Inc.

2309 Bering Dr.
San Jose, CA 95131-1125 USA
Tel: +1-408-325-8668 (main)

Tel: +1-408-325-8676 (support)
Fax: +1-408-325-8666
www.a10networks.com
Tel: +1-408-325-8668 (main)

Tel: +1-408-325-8676 (support)
Fax: +1-408-325-8666
Notice:
A10 Networks, the A10 logo, ACOS, aFleX, aXAPI, IDaccess, IDsentrie, IP-to-ID,
and VirtualN are trademarks or registered trademarks of A10 Networks, Inc. All other
trademarks are property of their respective owners.
Information in this document is subject to change without notice.
Published by:
A10 Networks, Inc.
2309 Bering Dr.
San Jose, CA 95131-1125
USA
©
A10 Networks, Inc. 11/11/2009 - All Rights Reserved
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 de-
scribed 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 infor-
mation on specific component types, please contact the manufacturer of that compo-
nent. 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, Inc. location which can be found by vis-
iting www.a10networks.com.
AX Series - Configuration 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 Net-
works support site:
• AX Series Installation 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 deploy-
ment tasks described in the AX Series Installation Guide.
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
P e r f o r m a n c e b yD e s i g n 3 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
About This Document
reliability, and establishes a new industry-leading price/performance For
more detailed information, see “System Overview” on page 17.
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.
Representations of Layer 2 and Layer 3 Devices

This document uses the following commonly used icons in network topol-
ogy examples for vendor-agnostic representations of Layer 2 switches and
Layer 3 routers.
Icon Description
Layer 2 switch
Layer 3 router
4 of 702 P e r f o r m a n c e b y D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
About This Document 3
System Description – The AX Series .................................................................................................... 3
Audience.................................................................................................................................................. 4
Representations of Layer 2 and Layer 3 Devices ................................................................................ 4
System Overview 17
AX Series Features............................................................................................................................... 17
ACOS Architecture ............................................................................................................................... 18
AX Software Processes .................................................................................................................. 19
Hardware Interfaces ............................................................................................................................. 20
Software Interfaces............................................................................................................................... 21
Server Load Balancing......................................................................................................................... 21
Intelligent Server Selection ............................................................................................................. 22
Configuration Templates ................................................................................................................. 23
Global Server Load Balancing............................................................................................................. 25
Outbound Link Load Balancing .......................................................................................................... 25
Transparent Cache Switching ............................................................................................................. 25
Firewall Load Balancing....................................................................................................................... 25
Where Do I Start?.................................................................................................................................. 25
Basic Setup 27
Logging On............................................................................................................................................ 27
Logging Onto the CLI ...................................................................................................................... 28
Logging Onto the GUI ..................................................................................................................... 29
Configuring Basic System Parameters .............................................................................................. 32
Setting the Hostname and Other DNS Parameters ........................................................................ 32
Setting the CLI Banners .................................................................................................................. 33
Setting Time/Date Parameters ....................................................................................................... 34
Configuring Syslog Settings ............................................................................................................ 37
Enabling SNMP .............................................................................................................................. 41
SNMP Traps ................................................................................................................................ 42
SNMP Communities and Views .................................................................................................. 43
SNMP Configuration Steps ......................................................................................................... 44
Configuration Examples ...................................................................................................................... 47
P e r f o r m a n c e D e s i g n b y 5 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Network Setup 53
Overview ................................................................................................................................................53
IP Subnet Support .......................................................................................................................... 53
Transparent Mode .................................................................................................................................54
Configuration Example ................................................................................................................... 56
Transparent Mode in Multinetted Environment ..................................................................................62
Route Mode............................................................................................................................................68
Direct Server Return in Transparent Mode .........................................................................................74
Direct Server Return in Route Mode....................................................................................................79
Direct Server Return in Mixed Layer 2/Layer 3 Environment............................................................82
HTTP Load Balancing 89

Overview ................................................................................................................................................89
Configuring HTTP Load Balancing......................................................................................................93
HTTP Options for SLB 105

Overview ..............................................................................................................................................105
Summary of HTTP Options .......................................................................................................... 105
HTTP Template Configuration ...................................................................................................... 106
URL Hash Switching ...........................................................................................................................108
Configuring URL Hashing ............................................................................................................. 110
URL / Host Switching .......................................................................................................................... 111
Configuring URL / Host Switching ................................................................................................ 114
Using URL / Host Switching along with Cookie Persistence ........................................................ 115
Using URL / Host Switching along with Source IP Persistence ................................................... 119
URL Failover ........................................................................................................................................119
Configuring URL Failover ............................................................................................................. 120
5xx Retry and Reassignment .............................................................................................................121
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Content Compression ........................................................................................................................ 122
Hardware-Based Compression ..................................................................................................... 123
How the AX Device Determines Whether to Compress a File ...................................................... 125
Configuring Content Compression ................................................................................................ 126
Client IP Insertion / Replacement...................................................................................................... 129
Configuring Client IP Insertion / Replacement .............................................................................. 132
Header Insertion / Erasure ................................................................................................................. 133
Configuring Header Insertion / Replacement ................................................................................ 134
Configuring Header Erasure ......................................................................................................... 137
URL Redirect Rewrite......................................................................................................................... 138
Configuring URL Redirect Rewrite ................................................................................................ 138
Strict Transaction Switching ............................................................................................................. 140
Enabling Strict Transaction Switching .......................................................................................... 140
FTP Load Balancing 141

Overview.............................................................................................................................................. 141
Configuring FTP Load Balancing ...................................................................................................... 143
SIP Load Balancing 163

Overview.............................................................................................................................................. 163
Configuring SIP Load Balancing....................................................................................................... 164
Disabling Reverse NAT Based on Destination IP Address ........................................................... 174
SSL Offload and SSL Proxy 177

Overview.............................................................................................................................................. 177
Choosing an SSL Optimization Implementation ........................................................................... 177
Configuring Client SSL ...................................................................................................................... 178
Configuring HTTPS Offload ............................................................................................................... 182
Configuring the SSL Proxy Feature .................................................................................................. 188
STARTTLS for Secure SMTP 195

Overview.............................................................................................................................................. 195
Configuring STARTTLS...................................................................................................................... 197
P e r f o r m a n c e D e s i g nb y 7 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Streaming-Media Load Balancing 207

Overview ..............................................................................................................................................207
Configuring Streaming-Media SLB....................................................................................................209
Layer 4 TCP/UDP Load Balancing 213

Overview ..............................................................................................................................................213
Configuring Layer 4 Load Balancing.................................................................................................216
IP Protocol Load Balancing 221

Overview ..............................................................................................................................................221
Configuring IP Protocol Load Balancing ..........................................................................................224
Wildcard VIPs 229

Configuring a Wildcard VIP ................................................................................................................229
Configuration Examples ............................................................................................................ 233
Outbound Link Load Balancing 235

Configuring Link Load Balancing .................................................................................................. 237
Transparent Cache Switching 241

Configuring Layer 4 TCS .............................................................................................................. 244
Configuring Layer 7 TCS .............................................................................................................. 247
Service Type HTTP Without URL Switching Rules ................................................................... 249
Service Type HTTP with URL Switching Rules ......................................................................... 250
Optimizing TCS with Multiple Cache Servers ........................................................................... 252
Enabling Support for Cache Spoofing ....................................................................................... 254
Firewall Load Balancing 255

Overview ..............................................................................................................................................255
FWLB HA with Direct Connection of AX Devices to Firewalls ...................................................... 257
FWLB Parameters ...............................................................................................................................260
TCP and UDP Session Aging ....................................................................................................... 263
Configuring FWLB...............................................................................................................................264
Server and Port Templates 281

Overview ..............................................................................................................................................281
Parameters That Can Be Configured Using Server and Port Templates ..................................... 282
Default Server and Service Port Templates ................................................................................. 284
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Configuring Server and Service Port Templates ............................................................................. 285
Applying a Server or Service Port Template .................................................................................... 286
Binding a Server Template to a Real Server ................................................................................ 287
Binding a Server Port Template to a Real Server Port ................................................................. 288
Binding a Virtual Server Template to a Virtual Server .................................................................. 288
Binding a Virtual Server Port Template to a Virtual Service Port .................................................. 289
Binding a Server Port Template to a Service Group ..................................................................... 289
Connection Limiting ........................................................................................................................... 290
Setting a Connection Limit ........................................................................................................ 290
Connection Rate Limiting .................................................................................................................. 292
Slow-Start............................................................................................................................................ 294
Health Monitoring 297

Default Health Checks........................................................................................................................ 297
Health Method Timers ........................................................................................................................ 298
Health Method Types.......................................................................................................................... 298
Protocol Port Numbers Tested by Health Checks ........................................................................ 303
Configuring and Applying a Health Method..................................................................................... 303
Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments .............................. 308
Configuring POST Requests in HTTP/HTTPS Health Monitors ................................................... 310
Customizing DNS Health Monitors ............................................................................................... 312
Overriding the Target IP Address or Protocol Port Number ......................................................... 315
Service Group Health Checks ........................................................................................................... 318
In-Band Health Monitoring................................................................................................................. 322
Configuring In-Band Health Monitoring ......................................................................................... 324
Consecutive Health Checks Within a Health Check Period............................................................ 325
On-Demand Health Checks................................................................................................................ 326
Displaying Health Status.................................................................................................................... 327
External Health Method Examples .................................................................................................... 331
TCL Script Example ...................................................................................................................... 331
Perl Script Example ...................................................................................................................... 333
Shell Script Example ..................................................................................................................... 334
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Global Server Load Balancing 335

Overview ..............................................................................................................................................335
Advantages of GSLB .................................................................................................................... 337
Zones, Services, and Sites ........................................................................................................... 338
GSLB Policy ................................................................................................................................. 338
Health Checks ........................................................................................................................... 340
Geo-Location ............................................................................................................................ 341
DNS Options ............................................................................................................................. 342
Metrics That Require the GSLB Protocol on Site AX Devices .................................................. 344
Configuration Overview......................................................................................................................345
Configure Health Monitors ............................................................................................................ 346
Configure the DNS Proxy ............................................................................................................. 347
Configure a GSLB Policy .............................................................................................................. 349
Enabling / Disabling Metrics ...................................................................................................... 349
Changing the Metric Order ........................................................................................................ 351
Configuring RTT Settings .......................................................................................................... 352
Passive RTT .............................................................................................................................. 356
Configuring BW-Cost Settings .................................................................................................. 357
Loading or Configuring Geo-Location Mappings ....................................................................... 363
Configure Services ....................................................................................................................... 372
Configure Sites ............................................................................................................................. 374
Configure a Zone .......................................................................................................................... 375
Enable the GSLB Protocol ........................................................................................................... 376
GSLB Parameters................................................................................................................................378
Policy Parameters ........................................................................................................................ 387
Configuration Examples .....................................................................................................................397
CLI Example ................................................................................................................................. 397
Configuration on the GSLB AX Device (GSLB Controller) ........................................................ 397
Configuration on Site AX Device AX-A ..................................................................................... 399
Configuration on Site AX Device AX-B ..................................................................................... 399
GUI Example ................................................................................................................................ 400
Configuration on the GSLB AX Device (GSLB Controller) ........................................................ 400
Configuration on Site AX Devices ............................................................................................. 409
RAM Caching 411

Overview ..............................................................................................................................................411
RFC 2616 Support ....................................................................................................................... 411
Dynamic Caching ......................................................................................................................... 412
Host Verification ........................................................................................................................... 412
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Support for no-cache and max-age=0 Cache-Control Headers ................................................... 413
RAM Caching Notes ..................................................................................................................... 413
Configuring RAM Caching ................................................................................................................. 414
High Availability 423

Overview.............................................................................................................................................. 423
Layer 3 Active-Standby HA ........................................................................................................... 424
Layer 3 Active-Active HA .............................................................................................................. 426
Layer 2 Active-Standby HA (Inline Deployment) .......................................................................... 428
Preferred HA Port ...................................................................................................................... 431
Port Restart ............................................................................................................................... 432
Layer 3 Active-Standby HA (Inline Deployment) .......................................................................... 433
HA Messages ............................................................................................................................... 434
HA Heartbeat Messages ........................................................................................................... 435
Gratuitous ARPs ........................................................................................................................ 435
HA Interfaces ................................................................................................................................ 436
Session Synchronization .............................................................................................................. 437
Optional Failover Triggers ............................................................................................................ 438
VLAN-based Failover ................................................................................................................ 438
Gateway-based Failover ........................................................................................................... 438
VIP-based Failover .................................................................................................................... 439
How the Active AX Device Is Selected ......................................................................................... 440
HA Pre-Emption ............................................................................................................................ 443
HA Sets ......................................................................................................................................... 444
HA Configuration Parameters ....................................................................................................... 445
Configuring Layer 3 HA...................................................................................................................... 450
Configuring Layer 2 HA (Inline Mode) .............................................................................................. 459
Layer 2 Inline HA Configuration Example ..................................................................................... 459
Configuring Layer 3 HA (Inline Mode) .............................................................................................. 466
Layer 3 Inline HA Configuration Example ..................................................................................... 466
Configuring Optional Failover Triggers............................................................................................ 471
VLAN-Based Failover Example .................................................................................................... 471
Gateway-Based Failover Example ............................................................................................... 472
VIP-Based Failover Example ........................................................................................................ 474
Enabling Session Synchronization................................................................................................... 476
Synchronizing Configuration Information........................................................................................ 477
Configuration Items That Are Backed Up ..................................................................................... 478
Configuration Items That Are Not Backed Up ........................................................................... 479
Performing HA Synchronization .................................................................................................... 480
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Network Address Translation 483

SLB NAT ...............................................................................................................................................483
IP NAT Configuration Limits ......................................................................................................... 484
SLB Source NAT .......................................................................................................................... 484
Connection Reuse .................................................................................................................... 484
Source NAT for Servers in Other Subnets ................................................................................ 489
Direct Server Return ..................................................................................................................... 491
Using IP Pool Default Gateways To Forward Traffic from Real Servers ...................................... 493
IP Source NAT......................................................................................................................................493
Configuring Dynamic IP Source NAT ........................................................................................... 495
Configuring Static IP Source NAT ................................................................................................ 501
IP NAT Use in Transparent Mode in Multi-Netted Environment ................................................... 503
IP NAT in HA Configurations ........................................................................................................ 504
Management Security Features 507

Configuring Additional Admin Accounts..........................................................................................507
Configuring an Admin Account ..................................................................................................... 508
Deleting an Admin Account .......................................................................................................... 512
Configuring Admin Lockout...............................................................................................................513
Securing Admin Access by Ethernet ................................................................................................515
Displaying the Current Management Access Settings ................................................................. 518
Regaining Access if you Accidentally Block All Access ............................................................... 519
Changing Web Access Settings ........................................................................................................519
Configuring AAA for Admin Access..................................................................................................521
Authentication ............................................................................................................................... 522
Authorization ................................................................................................................................ 522
CLI Access Levels ..................................................................................................................... 523
TACACS+ Authorization Debug Options .................................................................................. 523
Accounting .................................................................................................................................... 524
Command Accounting ............................................................................................................... 524
TACACS+ Accounting Debug Options ...................................................................................... 524
Configuring AAA for Admin Access .............................................................................................. 525
Configuring RADIUS for Authentication .................................................................................... 525
Configuring TACACS+ for Authentication ................................................................................. 526
Configuring TACACS+ for Authorization and Accounting ......................................................... 527
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Traffic Security Features 533
DDoS Protection ................................................................................................................................. 533
Enabling DDoS Protection ............................................................................................................ 534
SYN Cookies ....................................................................................................................................... 535
The Service Provided By SYN Cookies ........................................................................................ 535
Enabling Hardware-Based SYN Cookies ..................................................................................... 537
Configuration when Target VIP and Client-side Router Are in Different Subnets ..................... 537
Enabling Software-Based SYN Cookies ....................................................................................... 538
Configuring Layer 2/3 SYN Cookie Support ................................................................................. 539
ICMP Rate Limiting ............................................................................................................................. 540
Source-IP Based Connection Rate Limiting..................................................................................... 543
Parameters ................................................................................................................................... 543
Log Messages .............................................................................................................................. 544
Deployment Considerations .......................................................................................................... 544
Configuration ............................................................................................................................. 545
Configuration Examples ................................................................................................................ 546
Access Control Lists (ACLs) ............................................................................................................. 547
How ACLs Are Used ..................................................................................................................... 548
Configuring Standard IPv4 ACLs .................................................................................................. 549
Configuring Extended IPv4 ACLs ................................................................................................. 551
Configuring Extended IPv6 ACLs ................................................................................................. 555
Adding a Remark to an ACL ......................................................................................................... 558
Applying an ACL to an Interface ................................................................................................... 558
Applying an ACL to a Virtual Server Port ...................................................................................... 559
Using an ACL to Control Management Access ............................................................................ 560
Using an ACL for NAT .................................................................................................................. 560
Resequencing ACL Rules ............................................................................................................. 561
Policy-Based SLB (PBSLB) ............................................................................................................... 563
Configuring a Black/White List ...................................................................................................... 564
Configuring Policy-Based SLB on the AX Device ......................................................................... 565
Displaying PBSLB Information .................................................................................................. 573
Role-Based Administration 577

Overview.............................................................................................................................................. 578
Resource Partitions ...................................................................................................................... 579
Administrator Roles ...................................................................................................................... 581
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Configuring Role-Based Administration...........................................................................................583
Configuring Private Partitions ....................................................................................................... 583
Changing the Maximum Number of aFleX Policies Allowed in a Partition ................................ 584
Migrating Resources Between Partitions .................................................................................. 585
Deleting a Partition .................................................................................................................... 585
Configuring Partition Admin Accounts .......................................................................................... 586
CLI Example ................................................................................................................................. 588
Viewing and Saving the Configuration..............................................................................................589
Viewing the Configuration ............................................................................................................ 589
Saving the Configuration .............................................................................................................. 590
Switching To Another Partition..........................................................................................................591
Synchronizing the Configuration.......................................................................................................592
Operator Management of Real Servers .............................................................................................594
SLB Parameters 599

Service Template Parameters ............................................................................................................599
Cache Template Parameters ....................................................................................................... 601
Client SSL Template Parameters ................................................................................................. 603
Connection Reuse Template Parameters .................................................................................... 605
Cookie Persistence Template Parameters ................................................................................... 606
Destination-IP Persistence Template Parameters ....................................................................... 608
HTTP Template Parameters ........................................................................................................ 610
Policy Template Parameters ........................................................................................................ 615
Source-IP Persistence Template Parameters .............................................................................. 617
Server SSL Template Parameters ............................................................................................... 619
SIP Template Parameters ............................................................................................................ 620
SMTP Template Parameters ........................................................................................................ 621
SSL Session-ID Persistence Template Parameters ..................................................................... 623
Streaming-Media Template Parameters ...................................................................................... 623
TCP Template Parameters ........................................................................................................... 624
TCP-Proxy Template Parameters ................................................................................................ 625
UDP Template Parameters .......................................................................................................... 626
Global SLB Parameters ......................................................................................................................628
Real Server Parameters ......................................................................................................................632
Real Service Port Parameters ............................................................................................................634
Service Group Parameters .................................................................................................................636
Virtual Server Parameters ..................................................................................................................638
Virtual Service Port Parameters.........................................................................................................640
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
SSL Certificate Management 647
Overview.............................................................................................................................................. 647
SSL Process ................................................................................................................................. 647
CA-Signed and Self-Signed Certificates ................................................................................... 650
SSL Templates .......................................................................................................................... 650
Certificate Installation Process ..................................................................................................... 653
Requesting and Installing a CA-Signed Certificate ................................................................... 653
Installing a Self-Signed Certificate ............................................................................................ 655
Generating a Key and CSR for a CA-Signed Certificate ................................................................. 655
Importing a Certificate and Key......................................................................................................... 658
Generating a Self-Signed Certificate ................................................................................................ 659
Importing a CRL.................................................................................................................................. 661
Exporting Certificates, Keys, and CRLs ........................................................................................... 662
Exporting a Certificate and Key .................................................................................................... 662
Exporting a CRL ........................................................................................................................... 663
Creating a Client-SSL or Server-SSL Template and Binding it to a VIP ........................................ 664
Creating an SSL Template ........................................................................................................... 664
Binding an SSL Template to a VIP ............................................................................................... 665
Converting Certificates and CRLs to PEM Format .......................................................................... 665
Converting SSL Certificates to PEM Format ................................................................................ 666
Converting CRLs from DER to PEM Format ................................................................................ 667
Using the Management Interface as the Source for Management Traffic 669
Route Tables ....................................................................................................................................... 669
Management Routing Options........................................................................................................... 670
Enabling Use of the Management Interface as the Source for Automated Management
Traffic ............................................................................................................................................ 671
Using the Management Interface as the Source Interface for Manually Generated
Management Traffic ...................................................................................................................... 672
Commands at the User EXEC Level ......................................................................................... 672
Commands at the Privileged EXEC Level ................................................................................. 672
Commands at the Global Configuration Level ........................................................................... 672
Show Commands ...................................................................................................................... 673
Auto-Port Translation 675

Overview.............................................................................................................................................. 675
Configuring an Auto-Port Translation Range .................................................................................. 676
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Contents
Routing Parameters 679

OSPF Parameters ................................................................................................................................679
OSPF Global Parameters ............................................................................................................. 680
OSPF Interface Parameters ......................................................................................................... 682
RIP Parameters....................................................................................................................................685
RIP Global Parameters ................................................................................................................ 685
RIP Interface Parameters ............................................................................................................. 686
Configuration Management 687

Backing Up System Information ........................................................................................................687
Saving Multiple Configuration Files Locally.....................................................................................689
Configuration Profiles ................................................................................................................... 690
Commands for Local Configuration Management ........................................................................ 690
Scan-All-Members Option in Persistence Templates 697
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
AX Series Features
System Overview
This chapter provides a brief overview of the AX Series system and fea-
tures. For more information, see the other chapters in this guide.
AX Series Features
Key features of the AX Series include:
• Rack-mountable 2U chassis
• High Availability (Layer 4 Active-Active and Active-Standby) to pro-

vide session-level synchronization
• Raid 1 Dual hard disk drive and compact flash to provide extremely reli-
able software images and configuration files redundancy
• Redundant power supply
• Removable fan tray
• Dual Core/Dual Processors
• Optimized embedded Linux for Control Thread
• Optimized embedded A10 Packet Processing Data Thread
• Multi-core, multi-CPU system with offload features give the CPU more
cycles for L4-L7 processing
• Wire-speed L2/L3 switching
• Operates in either Transparent mode or Gateway mode
• L4 packet classification assist technology
• Static routes, Dynamic Routing protocols RIP and OSPF
• A10 Networks Proprietary offloading technology provides – buffer

management, receive/transmit assist, DoS protection, multi-Giga TCP
SYN floor protection/acceleration and Client-Server packet dispatcher
• Scalable configuration with the use of templates
• Server Load Balancing (SLB)
• Global Server Load Balancing (GSLB)
• Link Load Balancing (LLB)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
ACOS Architecture
• Transparent Cache Switching (TCS)
• Firewall Load Balancing (FWLB)
• RAM caching, in which the AX device functions as a web cache server
• Configuration templates for easy configuration of large deployments
• Sophisticated health checking
• High performance IP Network Address Translation (IP NAT)
• Streaming-media server load balancing
• Session IP load balancing
• Policy-based SLB (PBSLB), to permit or deny clients and direct them to

service groups based on client black/white lists
• SSL offload, to free servers from SSL authentication and SSL encryp-
tion
• Layer 4 and Layer 7 fast forwarding support
• Layer 4 and Layer 7 proxy support
• Security and DoS attack prevention
• Comprehensive aFleX scripting based on the Tool Command Language

(Tcl) programming standard. This allows you to customize L4 applica-
tion load balancing.
• SNMP, Web Server, SSL, SSH
• Industry standard CLI support
• Web GUI localization
• Comprehensive built-in debugging
ACOS Architecture
The AX Series uses 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
ACOS Architecture
The AX Series inspects packets at Layers 2, 3, 4, and 7 and uses hardware-
assisted forwarding. Packets are processed and forwarded based on the
AX Series configuration.
You can deploy the AX Series 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. Open Short-
est Path First (OSPF) and Routing Information Protocol (RIP) are sup-
ported.
In either type of deployment, the AX Series performs Layer 4-7 switching

based on the SLB configuration settings.
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 is responsible for the
following:
• Responsible for bringing 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 AX2200 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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Hardware Interfaces
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 and RIP routing protocols, 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.
• 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.
Hardware Interfaces
• 1000BaseT (GOC) + SFP Mini GBIC Fiber Ports
• On models AX 3100 and AX 3200, 10G XFP-SR (short range) single-
mode fiber port or XFP-LR (long range) multi-mode fiber port, depend-
ing 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Software Interfaces
Software Interfaces
• Graphical User Interface (GUI)
• Command Line Interface (CLI) accessible using console, Telnet, or
Secure Shell (v1 and v2)
• Simple Network Management Protocol (SNMP) v1, v2c, and v3
• XML Application Programming Interface (aXAPI)
The configuration examples in this manual show how to configure the

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

Server Load Balancing (SLB) is a suite of resource management features
that make server farms more reliable and efficient.
You can easily grow server farms in response to changing traffic flow, while
protecting the servers behind a common virtual IP address. From the per-
spective of a client who accesses services, requests go to and arrive from a
single IP address. The client is unaware that the server is in fact multiple
servers managed by an 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 indi-
vidual 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. For
more information, see “Health Monitoring” on page 297.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration Templates
SLB configuration is simplified by the use of templates. Templates simplify
configuration by enabling you to configure common settings once and use
them in multiple service configurations. The AX device provides templates
to control server and port configuration parameters, connectivity parame-
ters, and application parameters.
The AX device provides the following types of server and port configura-
tion 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
The AX device provides the following types of connectivity templates:

• TCP-Proxy – Controls TCP/IP stack parameters
• TCP – Controls 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 the idle timeout for unused sessions and specifies how
quickly sessions are terminated after a server response is received
The following types of application templates are provided:

• 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
• Connection reuse – Reduces overhead from TCP connection setup by

establishing and reusing TCP connections with real servers for multiple
client requests
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• 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.
See the following chapters for examples of SLB configurations:

• “HTTP Load Balancing” on page 89
• “FTP Load Balancing” on page 141
• “SIP Load Balancing” on page 163
• “SSL Offload and SSL Proxy” on page 177
• “STARTTLS for Secure SMTP” on page 195
• “Streaming-Media Load Balancing” on page 207
• “Layer 4 TCP/UDP Load Balancing” on page 213
For descriptions of all the parameters you can control using templates, see
“Server and Port Templates” on page 281 and “Service Template Parame-
ters” on page 599.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
For more information, see “Global Server Load Balancing” on page 335.
Outbound Link Load Balancing

Outbound Link Load Balancing (LLB) balances client-server traffic across
a set of WAN links. In outbound LLB, the clients are located on the internal
side of the network. The servers are located on the external side of the net-
work. For more information, see “Outbound Link Load Balancing” on
page 235.
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. For more information, see “Transparent Cache
Switching” on page 241.
Firewall Load Balancing

Firewall Load Balancing (FWLB) maximizes throughput through firewall
bottlenecks by load balancing server-client sessions across the firewalls. For
more information, see “Firewall Load Balancing” on page 255.
Where Do I Start?
• To configure basic system settings, see “Basic Setup” on page 27.
• To configure network settings, see “Network Setup” on page 53 and

“Routing Parameters” on page 679.
• To configure traffic management features (SLB, GSLB, LLB, TCS, and
FWLB), see the remaining chapters in this guide.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Where Do I Start?
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 53.
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 out-of-band manage-
ment interface. For that information, see the AX Series Advanced Traffic
Manager Installation Guide.
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 1 or 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:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Logging On
• Secure protocol – Hypertext Transfer Protocol over Secure Socket
Layer (HTTPS)
• Unsecure protocol – Hypertext Transfer Protocol (HTTP)
Note: By default, Telnet access is disabled on all interfaces, including the man-
agement interface. SSH, HTTP, HTTPS, and SNMP access are enabled by
default on the management interface only, and disabled by default on all
data interfaces.
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 set-
tings are in place. (For more information about securing management
access, see “Management Security Features” on page 507.)
To log onto the CLI using SSH:

1. On a PC connected to a network that can access the AX device’s man-
agement 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.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Logging On
If the enable password is correct, the command prompt for the Privi-
leged 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)#
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 Windows Linux MAC
IE 7.0 Supported N/A N/A
IE 6.x Not Supported1 N/A N/A
Firefox 3.x2 Supported Supported N/A
Firefox 2.x Supported Supported N/A
Firefox 1.x Supported Supported N/A
Safari 3.0 Not Supported N/A Supported
Safari 2.0 Not Supported N/A Not Supported
Chrome Not Supported N/A N/A
1. Support for IE 6.x is discontinued in AX Release 2.0. A10 Networks recommends that you upgrade to IE 7.
2. Support for Firefox 3.x is new in AX Release 2.0.
A screen resolution of at least 1024x768 is required.

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

tinue to the server (the AX device).
A login dialog is displayed. The name and appearance of the dialog
depends on the browser you are using.
P e r f o r m a n c e b y
D e s i g n 29 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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”.
5. 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Logging On
FIGURE 4 Monitor > Overview > Summary
Note: For more information about the GUI, see the AX Series GUI Reference or
the GUI online help.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Basic System Parameters

This section describes the basic system parameters and provides CLI and
GUI steps for configuring them.
Setting the Hostname and Other DNS Parameters

The default hostname is “AX”. To change the hostname, use either of the
following methods.
USING THE GUI

1. Select Config > Network > DNS. The DNS tab 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.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Note: The “ > ” or “ # ” character and characters in parentheses before “ # ” indi-
cate the CLI level you are on and are not part of the hostname.
3. To set the default domain name (DNS suffix) for hostnames on the 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 7 13:44:32 2008 from
192.168.1.144
[type ? for help]
You can format banner text as a single line or multiple lines.
If you configure a banner message that occupies multiple lines, you must
specify the end marker that indicates the end of the last line. The end marker
is a simple string up to 2-characters long, each of the which must be an
ASCII character from the following range: 0x21-0x7e.
The multi-line banner text starts from the first line and ends at the marker. If
the end marker is on a new line by itself, the last line of the banner text will
be empty. If you do not want the last line to be empty, put the end marker at
the end of the last non-empty line.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 mes-
sage. 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 mes-
sage.
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.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 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.
USING THE GUI

1. Select Config > System > Time. The Date/Time tab 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 min-
utes you want the AX device to wait between synchronizations with
the NTP server.
2. To select the timezone:

a. Click Time Zone to display the tab.
b. From the Time Zone Name pull-down list, select the time zone.
c. Click OK.
d. Click Date/Time to re-display the tab, 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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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} [minutes]
The minutes option sets the synchronization interval, which specifies
how often the AX polls the NTP server for updated time information.
You can specify 1-518400 minutes. The default is 1440 minutes.
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 ...
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]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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. Log-
ging to other places requires additional configuration. The standard Syslog
message severity levels are supported:
• Emergency – 0
• Alert – 1
• Critical – 2
• Error – 3
• Warning – 4
• Notification – 5
• Information – 6
• Debugging – 7
Table 2 lists the configurable Syslog parameters.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 2 Configurable System Log Settings

Parameter Description Supported Values
Disposition Output options for each message level. For each mes- The following message levels can be
(message target) sage level, you can select which of the following out- individually selected for each output
put options to enable: option:
• Console – Messages are displayed in Console ses- • Emergency (0)
sions. • Alert (1)
• Buffered – Messages are stored in the system log • Critical (2)
buffer.
• Error (3)
• Email – Messages are sent to the email addresses
• Warning (4)
in the Email To list. (See below.)
• Notification (5)
• SNMP – SNMP traps are generated and sent to the
SNMP receivers. • Information (6)
• Syslog – Messages are sent to the external log • Debug (7)
servers specified in the Log Server fields. (See Only Emergency, Alert, and Critical
below.) can be selected for SNMP.
• Monitor – Messages are displayed in Telnet and Only Emergency, Alert, Critical, and
SSH sessions. Notification can be selected for Email.
Facility Standard Syslog facility to use. Standard Syslog facilities listed in
RFC 3164.
Log Buffer Maximum number of log entries the log buffer can 10000 to 50000 entries
Entries store. Default: 30000
Log Server IP addresses or fully-qualified domain names of Any valid IP address or fully-quali-
external log servers. fied domain name.
Only the message levels for which Syslog is selected Default: None configured
in the Disposition list are sent to log servers.
Note: By default, the 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 “Using the Man-
agement Interface as the Source for Management
Traffic” on page 669.
Log Server Port Protocol port to which log messages sent to external Any valid protocol port number
log servers are addressed. Default: 514
Email To Email addresses to which to send log messages. Valid email address. Click the down
Only the message levels for which Email is selected arrow next to the input field to add
in the Disposition list are sent to log servers. another address (up to 10).
Each email address can be a maxi-
mum of 31 characters long.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 2 Configurable System Log Settings (Continued)
SMTP Server IP address or fully-qualified domain name of an Any valid IP address or fully-quali-
email server using Simple Message Transfer Proto- fied domain name.
col. Default: None configured
Note: By default, the 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 “Using the Management
Interface as the Source for Management Traffic” on
page 669.
SMTP Server Protocol port to which email messages sent to the Any valid protocol port number
Port SMTP server are addressed. Default: 25
Log Rate Limiting
The AX device uses a log rate limiting mechanism to ensure against over-
flow 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
external log server. In any case, all messages (up to 15,000 per second)
get sent to the external log servers.
Logging by Email (SMTP)

If you enable the AX device to send log messages by email, messages are
emailed as follows:
• Logs with severity level Emergency, Alert, or Critical are sent immedi-
ately.
• Other messages (messages with severity level Normal) are queued, and
sent only after either of the following occurs:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• 50 messages are queued.
• 10 minutes passes since the previous email.
Each email contains a maximum of 50 log messages.
USING THE GUI

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.
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 up to 4 server IP addresses 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
If you use the command to add some log servers, then need to add a new
log server later, you must enter all server IP addresses in the new com-
mand. Each time you enter the logging host command, it replaces any
set of servers and syslog port configured by the previous logging host
command.
4. To configure the AX device to send log messages by email, use the fol-
lowing 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 41.
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:

• SNMPv1/v2c (RFC 1157, RFC 1901)
• SNMP MIB-II (RFC 1213, RFC 1573)
• Ethernet Interface MIB (RFC 1643)
• SNMP View-based Access Control Model SNMP (RFC 2575)
• SNMPv3 Introduction to Framework (RFC 2570)
• SNMPv3 User-based Security Model (RFC 2574)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SNMP Traps
Table 3 lists the SNMP traps supported by the AX device. All traps are dis-
abled by default.
TABLE 3 AX SNMP Traps

Trap Category Trap Description
SNMP Link Up Indicates that an Ethernet interface has come up.
Link Down Indicates that an Ethernet interface has gone down.
System Start Indicates that the AX device has started.
Shutdown Indicates that the AX device has shut down.
Restart Indicates that the AX device is going to reboot or reload.
High Temperature Indicates that the temperature inside the AX chassis is too
high (68 C or higher).
If you see this trap, check for fan failure traps. Also check
the installation location to ensure that the chassis room tem-
perature is not too high (40 C or higher) and that the chassis
is receiving adequate air flow.
Fan 1 Indicates that system fan 1 has failed. Contact A10 Net-
works.
works.
works.
Lower Power Supply Indicates that the lower power supply has failed. The power
supply needs to be replaced.
Upper Power Supply Indicates that the upper power supply has failed. The power
supply needs to be replaced.
Primary Hard Disk Indicates that the primary Hard Disk has failed or the RAID
system has failed. Contact A10 Networks. The primary Hard
Disk is the one on the left, as you are facing the front of the
AX chassis.
Secondary Hard Disk Indicates that the secondary Hard Disk has failed or the
RAID system has failed. Contact A10 Networks. The sec-
ondary Hard Disk is the one on the right, as you are facing
the front of the AX chassis.
High Disk Usage Indicates that hard disk usage on the AX device is high
(85% or higher).
High Memory Usage Indicates that the memory usage on the AX device is high
(95% or higher).
High Availability (HA) Active Indicates that the AX device is going from HA Standby
mode to Active mode.
Standby Indicates that the AX device is going from HA Active mode
to Standby mode.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 3 AX SNMP Traps (Continued)
Trap Category Trap Description
Server Load Balancing Server Up Indicates that an SLB server has come up.
(SLB) Server Down Indicates that an SLB server has gone down.
Service Up Indicates that an SLB service has come up.
Service Down Indicates that an SLB service has gone down.
Server Connection Indicates that an SLB server has reached its configured con-
Limit nection limit.
Server Connection Indicates that an SLB server has reached its configured con-
Resume nection-resume value.
Service Connection Indicates that an SLB service has reached its configured
Limit connection limit.
Service Connection Indicates that an SLB service has reached its configured
Resume connection-resume value.
Virtual Port Up Indicates that an SLB virtual service port has come up. An
SLB virtual server’s service port is up when at least one
member (real server and real port) in the service group
bound to the virtual port is up.
Virtual Port Down Indicates that an SLB virtual service port has gone down.
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.
D e s i g n 43 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
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 manage-
ment port, see “Using the Management Interface as the Source for Management
Traffic” on page 669.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
Note: To configure support for SNMPv3 or to configure views, groups, and

users, use the CLI. The current release does not support configuration of
SNMPv3 using the GUI.
1. Select Config > System > SNMP.
2. On the General tab, 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. On the Community tab, configure community strings:

a. Click Community to display the tab.
b. In the SNMP Community field, enter a community name.
c. To restrict SNMP access to a specific host or subnet, enter a host-
name or an IP address and network mask in the Hostname (IP/
Mask) field.
By default, any host can access the SNMP agent on the AX device.
d. In the Object Identifier field, enter the OID at which SNMP man-
agement 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.
4. On the Trap tab, specify external trap receivers:

a. Click Trap to display the tab.
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
f. Click Add to add the receiver.
g. Repeat step b through step f for each trap receiver.
5. On the Trap List tab, enable traps:

a. Click Trap List to display the tab.
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 configura-
tion level of the CLI.
1. To configure location and contact information, use the following com-
mands:
snmp-server location location
snmp-server contact contact-name
2. To configure external SNMP trap receivers, use the following com-

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

command:
snmp-server community read ro-community-string
[oid oid-value]
[remote {hostname | ipaddr mask-length |
ipv6-addr/prefix-length}]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration Examples
4. To configure views, groups, and users, use the following commands:
snmp-server view view-name oid [oid-mask]
{included | excluded}
snmp-server group group-name
{v1 | v2c | v3 {auth | noauth | priv}}
read view-name
snmp-server user username group groupname
{v1 | v2 | v3 [auth {md5 | sha} password
[encrypted]]}
5. To enable the SNMP agent and SNMP traps, use the following com-
mand:
snmp-server enable
[
traps [
snmp [trap-name]
system [trap-name]
ha [trap-name]
slb [trap-name]
]
]
6. To save the configuration changes, use the following command at the

Privileged EXEC level or any configuration level of the CLI:
write memory
The 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 5 Config > Network > DNS > DNS tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 6 Config > System > Time > Date/Time tab
FIGURE 7 Config > System > Settings > Log tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 8 Config > System > SNMP
FIGURE 9 Config > System > SNMP > Trap List tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 10 Save Button
CLI EXAMPLE
The following commands log onto the CLI, access the global configuration
level, and set the hostname and configure the other DNS settings:
login as: admin
Welcome to AX
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(config)#ip dns suffix ourcorp
AX(config)#ip dns primary 10.10.20.25
AX(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(config)#banner login “welcome to login mode”
AX(config)#banner exec “welcome to exec mode”
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands set the timezone and NTP parameters:
AX(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(config)#clock timezone America/Los_Angeles

AX(config)#ntp server 10.1.4.20
AX(config)#ntp server enable
The following commands configure the AX device to 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 message levels
are sent to the management terminal in CLI sessions. The message level
emailed to admins is set to Emergency (0) messages only.
AX(config)#logging host 192.168.10.10
AX(config)#smtp ourmailsrvr
AX(config)#logging email-address admin1@example.com admin2@example.com
AX(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(config)#snmp-server location ourcorp-HQ
AX(config)#snmp-server contact Me_admin1
AX(config)#snmp-server enable trap
AX(config)#snmp-server community read ourcorpsnmp
AX(config)#snmp-server host 192.168.10.11 ourcorpsnmp
The following command saves the configuration changes to the startup-con-

fig. This is the file from which the AX device loads the configuration fol-
lowing a reboot.
AX(config)#write memory
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Network Setup
This chapter describes how to insert the AX device into your network.
After you complete the setup tasks in this chapter that are applicable to your
network, the AX device will be ready to configure for its primary function:
load balancing.
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 or a Layer 3 router.
The same Layer 4-7 features are available with either deployment option.
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 “High Availability” on
page 423.
Examples are provided in this chapter for the following types of network
deployment:
• Transparent mode
• Transparent mode in multinetted environment
• Route mode (also called gateway mode)
• Direct Server Return (DSR) in transparent mode
• DSR in route mode
IP Subnet Support
Each AX device has a management interface and data interfaces. The man-
agement 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 IP address.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
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.
Transparent Mode
Figure 11 shows an example of an AX Series device deployed in transparent
mode.
FIGURE 11 AX Deployment Example – Transparent Mode
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
The blue arrows show the traffic flow for client-server traffic; in this exam-
ple, between clients and server 10.10.10.3.
In this example, the AX device is inserted directly between the gateway

router and the real servers. The AX device and real servers are all in the
same subnet and all use the router as their default gateway.
Note: For simplicity, this example and the other examples in this chapter show
the physical links on single Ethernet ports. Everywhere a single Ethernet
connection is shown, you can use a trunk, which is a set of multiple ports
configured as a single logical link.
Similarly, where a single gateway router is shown, a pair of routers in a
Virtual Router Redundancy Protocol (VRRP) configuration could be
used. In this case, the gateway address used by hosts and Layer 2 switches
is the virtual IP address of the pair of routers.
This example does not use Layer 3 Network Address Translation (NAT) but
does use the default SLB NAT settings. (For a description, see “SLB Source
NAT” on page 484.)
HTTP requests from clients for virtual server 10.10.10.99 are routed by the
Layer 3 router to the AX device. SLB on the AX device selects a real server
and sends the request to the server. The server reply passes back through the
AX device to clients.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
Configuration Example
This section shows the GUI screens and CLI commands needed to imple-
ment the configuration shown in Figure 11.
USING THE GUI
The following figures show the GUI screens used to implement the configu-
ration shown in Figure 11. Here and elsewhere in this guide, the command
paths used to access a GUI screen are listed in the figure caption.
Interface Configuration
FIGURE 12 Config > Network > Interface > Transparent
Note: For reference, Figure 12 shows the entire interface. Subsequent figures
show only the relevant configuration page.
FIGURE 13 Config > Network > Interface > LAN
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
Real server configuration

The following screen examples show the GUI pages for basic SLB configu-
ration.
To implement changes entered on a GUI configuration page, click OK at the
bottom of the page.
FIGURE 14 Config > Service > SLB > Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
Service group configuration
FIGURE 15 Config > Service > SLB > Service Group
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
Virtual server configuration
FIGURE 16 Config > Service > SLB > Virtual Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
FIGURE 17 Config > Service > SLB > Virtual Server - Virtual Server Port
tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode
USING THE CLI
The following commands configure the global IP address and default gate-
way:
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 exam-
ple:
AX(config)#interface ethernet 1
AX(config-if:ethernet1)#enable
AX(config-if:ethernet1)#interface ethernet 2
AX(config-if:ethernet3)#exit
The following commands add the SLB configuration. (For more informa-
tion about SLB commands, see the SLB configuration chapters in this
guide. Also see the AX Series CLI Reference.)
Commands to configure the real servers

AX(config)#slb server rs1 10.10.10.3
AX(config-real server)#port 80 tcp
AX(config-real server-node port)#exit
AX(config-real server)#exit
Commands to configure the service group

AX(config)#slb service-group sg-web tcp
AX(config-slb service group)#member rs1:80
AX(config-slb service group)#exit
Commands to configure the virtual server

AX(config)#slb virtual-server vip1 10.10.10.99
AX(config-slb virtual server)#port 80 fast-http
AX(config-slb virtual server-slb virtua...)#service-group sg-web
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Mode in Multinetted Environment

Figure 18 shows an example of an AX device deployed in transparent
mode, in a multinetted environment.
FIGURE 18 AX Deployment Example – Transparent Mode in Multinetted

Environment
This example is similar to the example in Figure 11, except the real servers
are in separate subnets. Each server uses the router as its default gateway,
but at a different subnet address.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
ple, between clients and server 10.10.10.4.
To enable the AX device to pass traffic for multiple subnets, the device is
configured with multiple VLANs. The interfaces in subnet 10.10.10.x are in
VLAN 1. The interfaces in the 10.10.20.x subnet are in VLAN 2.
Note: In this example, each AX interface is in only one VLAN and can therefore
be untagged. The AX device could be connected to the router by a single
link, in which case the AX link with the router would be in two VLANs
and would need to tagged in at least one of the VLANs. (If an interface is
in multiple VLANs, the interface can be untagged in only one of the
VLANs.)
Layer 3 IP Source NAT
The default SLB NAT settings allow client traffic to reach the server in the
10.10.20.x subnet, even though this is not the subnet that contains the AX
device’s IP address.
However, in a multinetted environment where the AX device is deployed in

transparent mode, source NAT is required, to allow health checking of
server 10.10.20.4 and its application port.
In this example, an address pool containing a range of addresses in the

10.10.20.x subnet is configured. The pool configuration includes the default
gateway for the 10.10.20.x subnet (10.10.20.1). Without a gateway speci-
fied for the NAT pool, the AX device would attempt to send reply traffic
using its own gateway (10.10.10.x), which is in a different subnet. The NAT
configuration also includes enabling source NAT on the service port (in this
example, 80) on the virtual server.
Note: The AX device initiates health checks using the last (highest numbered)
IP address in the pool as the source IP address. In addition, the AX device
will only respond to control traffic (for example, management and ICMP
traffic) from the NATted subnet if the control traffic is sent to the last IP
address in the pool.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Note: GUI examples are shown here only for the configuration elements that are
new in this section (VLAN and Source NAT pool). For examples of the
GUI screens for the rest of the configuration, see “Transparent Mode” on
page 54.
USING THE GUI
FIGURE 19 Config > Network > VLAN
FIGURE 20 Config > Service > IP Source NAT > IPv4 Pool
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
way:
ple:
The following commands configure the VLANs. By default, all AX Ether-

net data ports are in VLAN 1 by default, so the only configuration required
in this example is to create a second VLAN and add ports to it. The ports
you add to other VLANs are automatically removed from VLAN 1.
AX(config)#vlan 2
AX(config-vlan:2)#untagged ethernet 2 ethernet 4
AX(config-vlan:2)#exit
The following command configures a pool of IP addresses for use by source

NAT. The pool is in the same subnet as real server 10.10.20.4.
AX(config)#ip nat pool pool1 10.10.20.100 10.10.20.101 netmask /24 gateway
10.10.20.1
The following commands add the SLB configuration. The source-nat com-
mand enables the IP address pool configured above to be used for NATting
health check traffic between the AX device and the real server. (For more
information about SLB commands, see the SLB configuration chapters in
this guide. Also see the AX Series CLI Reference.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009


AX(config-slb virtual server-slb virtua...)#source-nat pool pool1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Route Mode
Route Mode
Figure 22 shows an example of an AX device deployed in route mode.
FIGURE 22 AX Deployment Example – Route Mode
ple, between clients and server 192.168.4.101. This example shows a data-
base server that is not part of the SLB configuration but that is used by the
real servers when fulfilling client requests. Real servers can reach the data-
base server through the AX device just as they would through any other
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Route Mode
router. Replies to clients still travel from the real servers through the AX
device back to the client.
In this example, the AX device has separate IP interfaces in different sub-

nets 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 RIP and OSPF.
In this example, the device is enabled to run RIP. A static route is config-
ured 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. The database server would use
192.168.3.100 as its default gateway, the router connected to port 3 would
use 192.168.1.111 as its default gateway, and the Layer 2 switch connected
to 192.168.2.100 would use that address as its default gateway.
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
AX devices as their default gateway. (For more on HA, see “High Availabil-
ity” on page 423.)
Source NAT is not required for this configuration. The AX can send health
checks to the real servers and receive the replies without NAT.
Note: GUI examples are shown here only for the configuration elements that are
new in this section (configuration of routing parameters). For examples of
the GUI screens for the SLB configuration, see “Transparent Mode” on
page 54.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Route Mode
USING THE GUI
FIGURE 23 Config > Network > Interface > LAN > IPv4
FIGURE 24 Config > Network > Route > IPv4 Static
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Route Mode
FIGURE 25 Config > Network > Route > RIP > Route > General
FIGURE 26 Config > Network > Route > RIP > Interface
FIGURE 27 Config > Network > Route > RIP > Route > Network
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Route Mode
USING THE CLI
ple and configure IP addresses on them:
AX(config-if:ethernet1)#ip address 10.10.10.2 /24
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
The following commands configure the AX device as a RIP router. In this

example, a simple text string (“myrip”) is used to authenticate route updates
exchanged between the AX device and its neighboring RIP routers.
AX(config-if:ethernet1)#ip rip authentication string myrip
AX(config)#router rip
AX(config-router-rip)#network 10.10.10.0 /24
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Route Mode
AX(config-router-rip)#exit



AX(config-slb virtual server)#port 80 http
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Direct Server Return in Transparent Mode

Figure 28 shows an example of an AX device deployed in transparent
mode, in a Direct Server Return (DSR) configuration. In a DSR configura-
tion, replies from real servers do not necessarily pass through the AX
device.
FIGURE 28 AX Deployment Example – DSR in Transparent Mode
In this example, the AX device is attached to the network in a “one-armed”

configuration. A single link connects the AX device to the network. The
link can be on a single Ethernet port or a trunk. This example uses a single
Ethernet port.
ple, between clients and servers 10.10.10.3-4. Client request traffic for the
virtual server IP address, 10.10.10.99, is routed to the AX device. However,
server reply traffic does not pass back through the AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
DSR Health Checking
Layer 3 and Layer 4-7 health checks are supported in DSR configurations.
The target of the Layer 3 health checks can be the real IP addresses of the
servers, or the virtual IP address, depending on your preference.
• To send the Layer 3 health checks to the real server IP addresses, you
can use the default Layer 3 health method (ICMP).
• To send the Layer 3 health checks to the virtual IP address instead:
• Configure an ICMP health method with the transparent option
enabled, and with the alias address set to the virtual IP address.
• Globally enable DSR health checking.
Layer 4-7 health checks are sent to the same IP address as the Layer 3 health
checks, and then addressed to the specific protocol port. You can use the
default TCP and UDP health monitors or configure new health monitors.
This example uses the default TCP health monitor.
Requirements
This configuration has certain requirements:

• Requirements on the AX device:
• The AX device, virtual server, and the real servers all must be in the
same subnet.
• The virtual server IP address must be configured as a loopback
interface on each real server. (This is performed on the real server
itself, not as part of the real server’s configuration on the AX
device.)
• DSR must be enabled on the virtual service ports. (Enabling DSR is
equivalent to disabling destination NAT.)
Note: In the current release, for IPv4 VIPs, DSR is supported on virtual port
types (service types) TCP, UDP, FTP, and RTSP. For IPv6 VIPs, DSR is
supported on virtual port types TCP, UDP, and RTSP.
• Requirements on the real server:
• A loopback interface must be configured with the virtual server IP
address.
• ARP replies from the loopback interfaces must be disabled. (This
applies to the loopback interfaces that have the virtual server IP
address.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
This section shows how to implement the configuration shown in Figure 28.
USING THE GUI
Note: This example does not include configuration of the real servers, or config-
uration of the virtual server other than the steps for enabling DSR.
Specify the AX device’s IP address and default gateway

1. Select Config > Network > Interface.
2. On the menu bar, select Transparent.
3. Enter the IP address, network mask or prefix length, and default gate-
way address. (In this example, use the IPv4 tab and enter 10.10.10.2,
255.255.255.0, and 10.10.10.1.)
4. Click OK.
Enable Ethernet interface(s)

2. On the menu bar, select LAN.
3. Click on the checkbox next to the interface number to enable (for exam-
ple, “e3”).
4. Click Enable. The icon in the Status column changes to a green check-
mark to indicate that the interface is enabled.
Enable DSR on virtual ports

1. Select Config > Service > Server > Virtual Server.
2. Select the virtual server or click Add to create a new one.
3. Select the virtual port and click Edit, or click Add to create a new one.
4. On the Virtual Server Port tab, select Enabled next to Direct Server
Return. Configure other settings if needed. (The other settings are not
specific to DSR and depend on the application.)
5. Click OK. The virtual port list for the virtual server reappears.
6. Click OK again. The virtual server list reappears.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
way:
The following commands enable the Ethernet interface connected to the cli-
ents and server:



AX(config-slb virtual server)#port 80 tcp
AX(config-slb virtual server-slb virtua...)#no-dest-nat
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CONFIGURATION ON THE REAL SERVERS
For DSR to work, a loopback interface with the IP address of the virtual
server must be configured on each real server, and ARP replies from the
loopback address must be disabled.
Here is an example for a Unix/Linux server:

ifconfig lo:0 10.10.10.99 netmask 255.255.255.255 -arp up
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Direct Server Return in Route Mode

Figure 29 shows an example of an AX device deployed in a DSR configura-
tion in route mode.
FIGURE 29 AX Deployment Example – DSR in Route Mode
The configuration is very similar to the one for DSR in transparent mode,
except the AX device uses an IP interface configured on an individual
Ethernet port instead of a global IP address.
The requirements for the AX device and real servers are the same as those
for DSR in transparent mode. (See “Direct Server Return in Transparent
Mode” on page 74.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
This section shows how to implement the configuration shown in Figure 29.
Note: The following examples only show the part of the configuration that dif-
fers from deployment of DSR in transparent mode. The only difference is
configuration of the IP interface on the Ethernet interface connected to the
router, and configuration of a default route.
USING THE GUI
Configure an IP address on the Ethernet port

2. On the menu bar, select LAN.
3. In the Interface column, click on the interface name (for example, “e3”).
4. In the General section, click Enabled next to Status.
5. In the IPv4 section, enter the IP address and network mask.
6. Click OK.
Configure a default route

1. Select Config > Network > Route.
2. On the menu bar, select IPv4 Static.
3. Click Add.
4. Enter 0.0.0.0 in the IP Address and Netmask fields.
5. Enter the IP address of the gateway router in the Gateway field.
6. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
The following commands enable the Ethernet interface used in the example
and configure an IP address on it:
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
The rest of the configuration commands are the same as those shown in
“Direct Server Return in Transparent Mode” on page 74, beginning with
configuration of the real servers.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Direct Server Return in Mixed Layer 2/Layer 3 Environment

You can configure the AX device to use some servers as backups in a DSR
deployment. The backup servers are not required to be connected to the AX
device at Layer 2 or in the same IP subnet. Figure 30 shows an example that
uses a backup server in a different subnet.
Note: The deployment described in this section is useful for deploying backup
servers to use only if primary servers are unavailable.
FIGURE 30 Backup Server in DSR Configuration
In this example, two real servers are used as the primary servers for VIP
10.10.10.99:80. They are in the same IP subnet as the AX device. Each of
them is configured for DSR: destination NAT is disabled on the virtual port.
Another server, 192.168.1.10, is configured as a backup, to be used only if

both primary servers are unavailable. Since the backup server is a valuable
network resource, serving as a server farm backup is only one of its func-
tions. It also used by other applications elsewhere in the network. The AX
device can be configured to use the server as a backup to a DSR server farm,
without changing the network topology.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To deploy the backup server:
• In the service group, assign a higher priority to the members for the pri-
mary servers, so that the member for the backup server has the lower
priority. By default, the AX device will not use the lower-priority server
(the backup server) unless all the primary servers are down. Use the
same priority for all the primary servers.
• Enable destination NAT on the backup server. By default, destination
NAT is unset on real ports, and is set by the virtual port . Normally, des-
tination NAT is disabled on virtual ports used for DSR. However, desti-
nation NAT needs to be enabled on the real port on the backup server.
To enable destination NAT on a real port, create a real port template,
enable destination NAT in the template, and bind the template to the real
port. Destination NAT can not be set directly on an individual real port.
Enabling destination NAT for the backup server allows the server to
remain on a different subnet from the AX device, and still be used for
the VIP that normally is served by DSR. The backup server does not
need to be moved to a Layer 2 connection to the AX device and the
server’s IP address does not need to be changed. It can remain on a dif-
ferent subnet from the AX device and the primary servers.
USING THE GUI
Set member priorities in the service group

1. Select Config > Service > SLB.
2. On the menu bar, select Service Group.
3. Click on the service group name or click Add to create a new one.
4. If this is a new service group, enter the name.
5. In the Server section, when adding a member, select 16 from the Priority
field, for each of the primary server ports. Select 1 for the backup server
port.
Note: If you are modifying a member that is already in the list, click the check-
box in the row containing the member information, select the priority,
then click Update.
6. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Enable destination NAT on the backup server’s port
1. Configure a server port template:
a. Select Config > Service > SLB.
b. On the menu bar, select Template > Server Port.
c. Click Add.
d. Enter a name for the template in the Name field.
• In the Server Port Template section, select Disabled next to
Direct Server Return.
• In the real server Port section, select the checkbox next to the
port, select the port template from the Server Port Template
drop-down list, and click Update.
2. Apply the server port template to the real server port:

b. On the menu bar, select Server.
c. In the Port section, click on the checkbox in the row for the port, to
select the port. If you are adding a port, enter the port number in the
Port field.
d. Select the server port template from the Server Port Template drop-
down list.
e. Click Update (if you are updating a port) or Add (if you are adding a
new one).
f. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 32 Config > Service > SLB > Template > Server Port
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 33 Config > Service > SLB > Server - General and Port sections
USING THE CLI
To set the priority values of the primary servers to a higher value than the
backup server, re-add the members for the primary servers’ ports, and use
the priority option. Set the priority to a value higher than 1 (the default).
Use the same priority value on each of the primary server’s member ports.
To enable destination NAT on a service port within a service group, use the
dest-nat option in a server port template, then bind that template to the
server port in the service group.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI Example
The following commands add the members to the service group:

AX(config)#slb service-group sg-dsr tcp
AX(config-slb service group)#member primarys1:80 priority 16
AX(config-slb service group)#member primarys2:80 priority 16
AX(config-slb service group)#member secondarys1:80
The following commands configure a server port template for the backup
server and bind it to the HTTP port on the backup server:
AX(config)#slb template port dsrbackup
AX(config-rport)#dest-nat
AX(config-rport)#exit
AX(config)#slb server secondarys1 192.168.1.10
AX(config-real server-node port)#template port dsrbackup
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
HTTP Load Balancing
This chapter describes HTTP load balancing and how to configure it.
Overview
HTTP load balancing manages HTTP traffic across a Web server farm.
Figure 34 shows an example of an HTTP load balancing deployment.
Note: The network topologies in application examples such as this one are sim-
plified to focus on the application. For example, the Internet router con-
necting the clients to the AX device is not shown here. Likewise, a single
AX is shown. Your configuration might use an AX pair for High Avail-
ability (HA).
FIGURE 34 HTTP Load Balancing
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
In this example, a server farm consisting of three servers provides content
for Web site www.example.com. Clients access the site through its virtual
IP address, 192.168.10.11. When the AX device receives a client request for
the HTTP port (80) on 192.168.10.11, the AX device selects a real server
and sends the client request to the server.
For simplicity in this example, the real servers use the default protocol port
number for HTTP (80). The port numbers on the real and virtual servers are
not required to match.
The client is unaware of the real IP address of the real server, nor is the cli-
ent aware that the site actually consists of multiple servers. After selecting a
real server, the AX device automatically performs the necessary Network
Address Translation (NAT) to send the client request to the server, receive
the reply from the server, and send the reply to the client. From the client’s
perspective, the Web session is between the client and port 80 on
192.168.10.11.
SERVICE GROUPS
A service group contains a set of real servers from which the AX device can
select to service a client request.
This example uses a single service group that contains all the real servers
and the applicable service port (80). During configuration, you bind the ser-
vice group to the virtual port(s) on the virtual server.
The AX device selects a server based on the load balancing method used by
the service group, and on additional criteria relevant to the load balancing
method.
In this example, the default load balancing method, round robin, is used.
The round robin method selects servers in rotation. For example, the first
client request is sent to server web-2, the next client request is sent to server
web-3, and so on.
VIRTUAL SERVER
The virtual server in this example has IP address 192.168.10.11 and virtual
service port 80. When you configure a virtual service port, you specify the
protocol port number for the port. You also specify the service type. The AX
device supports the following service types for HTTP ports:
• HTTP – Complete TCP stack. Use this service type if you plan to cus-
tomize any templates. For example, if you plan to use SSL (HTTPS load
balancing or SSL offload), or customize the HTTP template to change
information in the HTTP headers of server replies, use the HTTP service
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
type. Also use this service type for stream-based applications such as
RAM Caching and compression.
• Fast-HTTP – Streamlined hybrid stack for high performance. If you do
not plan to offload SSL or customize any templates, use Fast-HTTP.
(For a complete list of the service types, see “Virtual Service Port Parame-
ters” on page 640.)
TEMPLATES
Templates are sets of configuration parameters that apply to specific service
types or to servers and service ports. This example uses the default settings
for each of the templates that are automatically applied to the HTTP service
type and to the real and virtual servers and ports. The rest of the information
in this section is for reference but is not required reading to continue with
this example.
For some of types of templates, the AX configuration has a “default” tem-

plate that is automatically applied to a service port unless you apply another
template of the same type instead. (See “Service Template Parameters” on
page 599.)
Service Templates
For HTTP, the AX configuration applies “default” templates of each of the

following template types to HTTP service ports:
• TCP-Proxy – TCP-proxy templates control TCP stack settings, includ-
ing the idle timeout for TCP connections. Unless you need to change the
setting for a TCP/IP stack parameter, you can safely allow the AX
device to apply the default TCP-proxy template to the service types that
use it.
• HTTP – HTTP templates provide many options, including options to
change information in the HTTP header, enable compression, and select
a service group based on the URL requested by the client. By default, all
the options in this template are disabled or not set, so you can safely
allow the AX device to apply the default for this template type too.
• Connection Reuse – Allows TCP connections between the AX device
and real servers to be reused for multiple clients instead of terminating a
connection and starting a new one for each new client. Although the
default connection reuse template is automatically applied, the default
settings in the template disable connection reuse. Unless you want to use
connection reuse, you can ignore this template. (Connection reuse
requires additional configuration. See “Connection Reuse” on
page 484.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
The following types of templates also can be used with HTTP service ports.
However, these types of templates do not have “default” templates that are
applied automatically.
• Cookie Persistence – Inserts a cookie in the HTTP header of a server
reply before sending the reply to the client. The cookie ensures that sub-
sequent requests from the client for the same virtual server and virtual
port are directed to the same service group, real server, or real service
port.
• Source-IP Persistence – Similar to cookie persistence, except the AX
device does not insert cookies. Instead, clients are directed to the same
resource in the server farm for every request, for the duration of a con-
figurable timer on the AX device. The granularity of the persistence can
be set to always use the same real server port, the same real server, or
the same service group.
(For an example that uses a source-IP persistence template, see “Layer 4

TCP/UDP Load Balancing” on page 213.)
Server and Port Templates

The AX device uses templates for configuration of some commonly used
server and port parameters. By default, the following templates are applied:
• Default server template – Contains configuration parameters for real
servers
• Default port template – Contains configuration parameters for real ser-
vice ports
• Default virtual-server template – Contains configuration parameters for
virtual servers
• Default virtual-port template – Contains configuration parameters for
virtual service ports
Each of the default templates is named “default”.
For more information about server and port templates, see the following:
• “Server and Port Templates” on page 281 in this guide
• “Config Commands: SLB Templates” chapter in the AX Series CLI Ref-

erence
• “Config > Service > SLB > Template” section in the “Config Mode”
chapter of the AX Series GUI Reference
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring HTTP Load Balancing
HEALTH MONITORS
This example uses the following types of health monitors to check the real
servers:
• Ping – A Layer 3 health method that sends an ICMP echo request to the
real server’s IP address. The server passes the health check if the AX
device receives a ping reply.
• TCP – By default, every 30 seconds the AX device sends a connection
request (TCP SYN) to each load balanced TCP port on each server, in
this case ports 80 and 443. A TCP port passes the health check if the
server replies to the AX device by sending a TCP SYN ACK. By
default, the AX device completes the TCP handshake.
In addition to these default health checks, you can configure health monitors
for specific service types. This example uses an HTTP health monitor, with
the following default settings.
• Every 30 seconds, the AX device sends an HTTP GET request for the
default index page.
• The HTTP service port passes the health check if the requested page is
present on the server and the server replies with an OK message (200).
(For more information about health monitors and their configurable options,
see “Health Monitoring” on page 297.)

To configure the HTTP load balancing solution described in “Overview” on
page 89, perform the following tasks on the AX device:
1. Configure an HTTP health monitor.
2. Configure the real servers. On each real server:

• Add the HTTP service port.
• Enable the HTTP health monitor.
3. Configure the service group. Add the real servers and service ports to
the group.
4. Configure the virtual server:

• Add the HTTP service port, with service type Fast-HTTP.
• Bind the service group to the virtual port.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
To configure an HTTP health method

1. Select Config > Service > Health Monitor.
2. Select Health Monitor on the menu bar.
3. Click Add.
4. On the Health Monitor tab, enter a name for the monitor.
5. On the Method tab, select HTTP from the Type drop-down list.
The other configuration fields on the tab change to those that apply to
HTTP health monitors.
6. Optionally, select or enter additional options for the health monitor. (See
“Health Monitoring” on page 297.)
In this example, you can use all the default settings
7. Click OK. The new monitor appears in the health monitor table.
FIGURE 35 Config > Service > Health Monitor > Health Monitor
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure the real servers
Perform the following procedure separately for each real server.
2. Select Server on the menu bar.
3. Click Add.
4. On the General tab, enter a name for the server in the Name field.
5. In the IP Address field, enter the IP address of the server.
Note: Enter the server’s real address, not the virtual server IP address.
6. In the Health Monitor drop-down list, select ping or leave the monitor
unset.
Note: If you leave the monitor unset, the Layer 3 health monitor that comes in
the AX configuration by default is used. (See “Default Health Checks” on
page 297.)
7. On the Port tab, enter the number of the service port on the real server in
the Port field. In this example, enter “80”.
8. In the Health Monitor drop-down list, select the HTTP health monitor
configured in “To configure an HTTP health method” on page 94.
9. Click Add. The port appears in the port list.
10. Click OK. The real server appears in the server table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 37 Config > Service > SLB > Server (real servers added)
Note: The AX device begins sending health checks to a real server’s IP address
and service ports as soon as you finish configuring the server. The overall
health status for the server is shown in the Health column. If the status is
Down ( ) instead of Up ( ), verify that health monitors are config-
ured for all the service ports. The default Layer 3 health method is auto-
matically used for the Layer 3 health check, unless you selected another
health method instead.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure the service group
1. Select Config > Service > SLB, if not still selected.
2. Select Service Group on the menu bar.
3. Click Add.
4. On the Service Group tab, select the load-balancing method from the
Algorithm drop-down list.
For this example, you can leave the default selected: Round Robin
5. On the Server tab, select a real server from the Server drop-down list.
6. In the port field, enter the service port number.
7. Click Add.
8. Repeat step 5 through step 7 for each real server.
9. Click OK. The new group appears in the service group table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure the virtual server
1. Select Config > Service > SLB, if not still selected.
2. Select Virtual Server on the menu bar.
3. Click Add. The General tab appears.
4. On the General tab, enter a name for the virtual server in the Name field.
5. In the IP Address field, enter the IP address that clients will request.
6. On the Port tab, click Add. The Virtual Server Port tab appears.
7. In the Type drop-down list, select the service type. In this example,
select Fast-HTTP.
8. In the Port field, enter the service port number. In this example, enter
“80”.
9. In the Service Group drop-down list, select the service group.
10. Click OK. The port appears in the Port list of the Port tab.
11. Click OK. The virtual server appears in the virtual server table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 39 Config > Service > SLB > Virtual Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 40 Config > Service > SLB > Virtual Server - Port tab
USING THE CLI
Note: The command syntax shown in this section is simplified for the configu-
ration example in this chapter. For complete syntax information about any
command, see the AX Series CLI Reference.
1. To configure HTTP and HTTPS health methods, use the following com-
mands:
health monitor monitor-name
Enter this command at the global configuration level of the CLI, for
each monitor to be configured. The command changes the CLI to the
configuration level for the monitor. At the monitor configuration level,
enter the following command:
method http
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Entering this command, without entering additional commands at this
level, configures the monitor to use all the default settings for the HTTP
method.
To customize settings for a health monitor, use additional commands at
the configuration level for the monitor.
2. To configure the real servers, use the following commands:

slb server server-name ipaddr
This command changes the CLI to the configuration level for the real
server, where you can use the following command to add the HTTP port
to the server:
port port-num tcp
The port-num specifies the protocol port number. In this example, spec-
ify “80”.
This command adds the port and changes the CLI to the configuration
level for the port, where you can use the following command to enable
the HTTP health check:
health-check monitor-name
For monitor-name, specify the name of the HTTP health monitor config-
ured in step 1.
3. To configure the service group, use the following commands:

slb service-group group-name tcp
This command changes the CLI to the configuration level for the service
group, where you can use the following command to add the real servers
and service ports to the group:
member server-name:portnum
The portnum is the protocol port number of the service to be load bal-
anced. In this example, specify “80”.
Repeat the command for each real server.
4. To configure the virtual server and virtual port, use the following com-
mands:
slb virtual-server name ipaddr
This command changes the CLI to the configuration level for the virtual
server, where you can use the following command to add the virtual port
to the server:
port port-number fast-http
or
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
port port-num http
For this example, use the first command (the one with fast-http as the
service type) and specify “80” as the port-num.
The port command changes the CLI to the configuration level for the
virtual port, where you can use the following command to bind the vir-
tual port to the service group:
service-group group-name
The group-name is the name of the service group configured in step 3.
CLI EXAMPLE
The following commands configure the HTTP health monitor:

AX(config)#health monitor http-monitor
AX(config-health:monitor)#method http
AX(config-health:monitor)#exit
The following commands configure the real servers:

AX(config)#slb server web-2 10.10.10.2
AX(config-real server-node port)#health-check http-hmon
The following commands configure the service group:

AX(config-slb service group)#member web-2:80
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the virtual server:
AX(config)#slb virtual-server web-vip 192.168.10.11
AX(config-slb virtual server-slb virtua...)#exit
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
HTTP Options for SLB
This chapter describes the HTTP options you can configure in HTTP tem-
plates, and provides examples of their use.
Overview
HTTP templates provide many SLB options. Some options control selection
of real servers or service groups, while other options modify HTTP header
information or enhance website performance.
Summary of HTTP Options

This section briefly describes each of the options you can configure in
HTTP templates.
Options for Server and Service Group Selection

You can use the following HTTP options to select real servers or service
groups. The server selection options override selection by the load-balanc-
ing method. By default, the AX device uses the load-balancing method set
for the service group to select a real server.
• URL hash switching – Selects a real server based on a hash value calcu-
lated from part of the URL string. (See “URL Hash Switching” on
page 108.)
• URL / host switching – Selects a service group based on the URL path
or domain in the client’s GET request. (See “URL / Host Switching” on
page 111.)
• Failover URL – If the URL in GET request cannot be reached due to
server unavailability, the AX device sends a 302 Redirect to the client.
(See “URL Failover” on page 119.)
• 5xx retry and reassignment – Retries a server that replies to a request
with a 5xx status code instead of sending the status code to the client,
and reassigns the request to another server if the first server continues to
reply with a 5xx status code. (See “5xx Retry and Reassignment” on
page 121.)
• Strict transaction switching – Performs server selection for each request
within a client-server session, rather than performing server-selection
once per session. This option provides a simple method to force rebal-
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
ancing of server selection. (See “Strict Transaction Switching” on
page 140.)
Performance Enhancing Option

• Content Compression – You can configure the AX device to offload
content compression from real servers. Enabling content compression
on the AX device can help increase overall website performance by
freeing real server resources from CPU-intensive compression tasks.
(See “Content Compression” on page 122.)
Options that Modify HTTP Requests

• Client IP insertion – Inserts the client’s IP address into GET requests
before sending the requests to a real server. The address is added as a
value to the X-ClientIP field by default. Optionally, you can add the cli-
ent address to a different field instead; for example: X-Forwarded-For.
(See “Client IP Insertion / Replacement” on page 129.)
• Header insertion / erasure – Inserts a field:value pair into requests or
responses, or deletes a header. (See “Header Insertion / Erasure” on
page 133.)
Options that Modify Server Replies

• Redirect rewrite – Modifies 302 Redirect messages from real servers
before sending the redirect messages to clients. This option can convert
HTTP URLs into HTTPS URLs, and can modify the domain or URL
path in the redirect message. (See “URL Redirect Rewrite” on
page 138.)
HTTP Template Configuration

To use the options in an HTTP template, you must configure the template,
then bind the template to virtual service ports. You can bind an HTTP tem-
plate to the following types of virtual service ports:
• HTTP
• Fast-HTTP
• HTTPS
To configure an HTTP template and bind it to a virtual service port, use

either of the following methods:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
USING THE GUI
To configure an HTTP template:

1. Select Config > Service > Template.
2. Select Application > HTTP on the menu bar.
3. Click Add. The HTTP tab appears.
4. Enter a name for the template.
5. Select or enter values for the template options you want to use. The
remaining sections in this chapter describe the fields for configuring
each option.
Note: Some settings are on the other HTTP template tabs (App switching, Redi-
rect Rewrite, and Compression).
6. When finished, click OK. The template appears in the HTTP template
list.
To bind a template to a virtual service port:

3. To edit an existing virtual server, select it. To configure a new one, Click
Add. The General tab appears.
4. Click Port. The Port tab appears.
5. Select the port or Click Add. The Virtual Server Port tab appears.
6. Make sure the port type is HTTP, Fast-HTTP, or HTTPS.
7. In the HTTP Template drop-down list, select the HTTP template.
8. Configure other options if needed. (For example, if you are configuring

a new port, make sure to select the service group.)
9. Click OK. The port appears in the Port list of the Port tab.
10. Click OK. The virtual server list reappears.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL Hash Switching
USING THE CLI
To configure an HTTP template, enter the following command at the global

configuration level of the CLI:
slb template http template-name
This command changes the CLI to the configuration level for the template.
The remaining sections in this chapter describe the commands for configur-
ing each option.
To bind a template to a virtual service port, enter the following command at

the configuration level for the port:
template http template-name
URL Hash Switching

URL hash switching provides a simple method for optimizing a server farm
in which the same content is served by multiple servers. This feature
enhances website performance by taking advantage of content caching on
the real servers.
When enabled, URL hashing selects a real server for the first request for
given content, and assigns a hash value to the server for the content. The
AX device then sends all subsequent requests for the content to the same
real server.
Figure 41 shows an example of URL hashing.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL Hash Switching
FIGURE 41 URL Hashing
In this example, a service group contains three real servers. Each of the real
servers contains the same set of .html(l), .pdf, and .jpg files. The AX device
is configured to calculate a hash value based on the last 3 bytes of the URL
string in the client request, and assign the hash value to a server.
After assigning a hash value to a server, the AX device sends all requests
that match the hash value to the same real server. In this example, all
requests that end with “pdf” are sent to the same server.
If the real server becomes unavailable, the AX device selects another server,
assigns a hash value to it, and uses that server for all subsequent requests for
URL strings that have the same hash value.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL Hash Switching
Hash Options
You can specify the following hash options:

• Bytes – Specifies how many bytes of the URL string to use to calculate
the hash value.
• First or last – Specifies which end of the URL string to use to calculate
the hash value.
The example in Figure 41 calculates hash values based on the last 3 bytes of
the URL strings.
Configuring URL Hashing

The following sections show how to configure URL hashing.
USING THE GUI

1. Access the configuration tabs for the template. (See “HTTP Template
Configuration” on page 106.)
2. Click the App Switching tab.
3. Select the URL Hash checkbox. This activates the configuration fields.
4. To set the hashing granularity:

a. Select the position in the URL upon which to calculate the hash
value.
b. Enter the number of bytes to use for calculating the hash value.
5. Click OK.
USING THE CLI
Enter the following command at the configuration level for the HTTP tem-
plate:
url-hash-persist {first | last} bytes
CLI Example
The following commands implement the URL hashing configuration shown

in Figure 41 on page 109.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL / Host Switching
The following commands configure the HTTP template:
AX(config)#slb template http hash
AX(config-HTTP template)#url-hash-persist last 3
AX(config-HTTP template)#url-switching ends-with .htm
AX(config-HTTP template)#exit
The following commands bind the HTTP template to virtual port 80:
AX(config)#slb virtual-server vs1 1.1.1.1
AX(config-slb virtual server-slb virtua...)#service-group sg1
AX(config-slb virtual server-slb virtua...)#template http hash

The AX device supports multiple service groups. URL / host switching
enables an AX device to select a service group based on the URL or domain
name in a client’s GET request. The selection overrides the service group
configured on the virtual port.
You can configure an HTTP template with one of the following service-
group switching options:
• URL switching – Selects a service group based on the URL path in the
GET line of the HTTP request’s header
• Host switching – Selects a service group based on the domain name in
the Host field of the HTTP request’s header
Note: If you plan to use URL / host switching along with cookie persistence,
you must enable the match-type service-group option in the cookie persis-
tence template. (See “Using URL / Host Switching along with Cookie
Persistence” on page 115.)
Figure 42 shows an example of URL switching.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 42 URL Switching
In this example, the AX device is configured to use separate service groups

for URLs in the www.example.com domain. The real servers in service
group sg-abc provide content for www.example.com/abc. The real servers
in service group sg-123 provide content for www.example.com/123.
URL switching rules configured on the AX device select a service group

based on the beginning of the URL on the GET line of client requests.
Requests for URLs that begin with “/abc” are sent to service group sg-abc.
Likewise, requests for URLs that begin with “/123” are sent to service
group sg-123.
Note: An HTTP template can be configured with only one type of service-group
switching, URL switching or host switching.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Match Options
URL / host switching selects a service group based on rules that map part of
the URL string or host (domain name) to the service group. You can use the
following match options in URL / host switching rules:
• Starts-with string – matches only if the URL or host name starts with the
specified string.
• Contains string – matches if the specified string appears anywhere
within the URL or host name.
• Ends-with string – matches only if the URL or host name ends with the
specified string.
These match options are always applied in the following order, regardless of
the order in which the rules appear in the configuration. The service group
for the first match is used.
• Starts-with
• Contains
• Ends-with
If a template has more than one rule with the same option (starts-with, con-
tains, or ends-with) and a URL or host name matches on more than one of
them, the most-specific match is always used. For example, if a template
has the following rules, requests for host “www.ddeeff.org” will always be
directed to service group http-sgf:
host-switching contains d service-group http-sgd
host-switching contains dd service-group http-sge
host-switching contains dde service-group http-sgf
If you use the starts-with option with URL switching, use a slash in front of
the URL string. For example:
url-switching starts-with /urlexample service-group http-sg1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring URL / Host Switching

The following sections show how to configure URL / host switching.
USING THE GUI

2. Click the App Switching tab.
3. Select the type of switching, URL or Host. This activates configuration

fields for the type of switching you select.
4. For URL switching:

a. In the URL field, enter the URL.
b. In the Service Group drop-down list, select the service group to
which to send client requests.
c. In the Match Type drop-down list, select the match option to use.
Note: The “Match” match option is a deprecated version of the “Contains”

option. Use “Contains” instead of “Match”.
5. For host switching:

a. In the Host field, enter the domain name.
b. In the Service Group drop-down list, select the service group to
which to send client requests.
c. In the Match Type drop-down list, select the match option to use.
Note: The “Match” match option is a deprecated version of the “Contains”

option. Use “Contains” instead of “Match”.
6. Click Add.
7. Click OK. The HTTP template list reappears.
USING THE CLI
Enter one of the following commands at the configuration level for the
HTTP template:
url-switching
{starts-with | contains | ends-with} url-string
service-group service-group-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
host-switching
{starts-with |contains | ends-with} host-string
CLI Example
The following commands implement the URL switching configuration

shown in Figure 42 on page 112.

AX(config)#slb template http urlswitch
AX(config-HTTP template)#url-switching starts-with abc service-group sg-abc
AX(config-HTTP template)#url-switching starts-with 123 service-group sg-123
The following commands bind the HTTP template and service group sg-abc
to virtual port 80:
AX(config-slb virtual server-slb virtua...)#template http urlswitch
AX(config-slb virtual server-slb virtua...)#service-group sg-abc
The following commands bind the HTTP template and service group sg-123
to virtual port 80:
AX(config-slb virtual server-slb virtua...)#template http urlswitch
AX(config-slb virtual server-slb virtua...)#service-group sg-123
Using URL / Host Switching along with Cookie Persistence

The AX device supports use of URL / host switching and cookie persistence
in the same SLB configuration. However, to enable this support, you must
enable the match-type service-group option in the cookie persistence tem-
plate.
By default, the service-group option is disabled in cookie persistence tem-

plates. In this case, URL switching or host switching is used only for the
initial request from a client. After the initial request, the same service group
is always used for subsequent requests from the same client.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To continue using URL switching or host switching to select a service group
for each request, enable the service-group option in the cookie persistence
template. In this case, for each request from the client, the AX device first
selects a service group, then uses information in the cookie to select the real
server and port within the service group.
Figure 43 shows an example.
FIGURE 43 URL Switching with Cookie Persistence
In this example, URL switching and cookie persistence are both configured,
and the service-group option is enabled in the cookie persistence template.
For each client request, URL switching selects a service group first. Then,
after a service group is selected, a real server and port are selected within
the service group.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• If the client’s request does not have a persistence cookie that includes
the selected service group, the AX device uses SLB to select a server,
then inserts a persistence cookie into the reply from the server. The
cookie includes the service group name.
• If the client’s request already has a persistence cookie containing the
name of the selected service group, the AX device uses the information
in the cookie to select the same server within the service group.
For example, the first time service group sgabc is selected by URL switch-
ing, the AX device inserts a cookie into the server's reply, to ensure that the
same server is used the next time URL switching selects sgabc. The first
time service group sg123 is selected by URL switching, the AX device
inserts a second cookie into the server’s reply, to ensure that the same server
is used the next time URL switching selects sg123. Even though URL
switching does not always select the same service group, the same server
within the selected service group is always selected.
Cookie Persistence Match-Type Options
When cookie persistence is configured, the AX device adds a persistence

cookie to the server reply before sending the reply to the client. The client’s
browser re-inserts the cookie into each request. The format of the cookie
depends on the match-type setting:
• match-type (port) – This is the default setting. Subsequent requests
from the client will be sent to the same real port on the same real server.
URL switching or host switching is used only for the first request.
The cookie that the AX device inserts into the server reply has the fol-
lowing format:
Set-Cookie: cookiename-vport=rserverIP_rport
The vport is the virtual port number. The rserverIP is the real server IP
address and the rport is the real server port number.
Note: The port option is shown in parentheses because the CLI does not have a
“port” keyword. If you do not set the match type to server (see below),
the match type is automatically “port”.
• match-type server – Subsequent requests from the client for the same
VIP will be sent to the same real server, provided that all virtual ports of
the VIP use the same cookie persistence template with match-type set to
server. URL switching or host switching is used only for the first
request.
lowing format:
Set-Cookie: cookiename=rserverIP
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• match-type (port) service-group – Subsequent requests from the client
will be sent to the same real port on the same real server, within the ser-
vice group selected by URL switching or host switching. URL switch-
ing or host switching is still used for every request.
lowing format:
Set-Cookie: cookiename-vport-servicegroupname=rserverIP_rport
• match-type server service-group – Subsequent requests from the cli-
ent for the same VIP will be sent to the same real server, within the ser-
vice group selected by URL switching or host switching. URL
switching or host switching is still used for every request.
lowing format:
Set-Cookie: cookiename-servicegroupname=rserverIP
Note: For security, address information in the persistence cookies is encrypted.
USING THE CLI
To enable the service-group option, use the following command at the con-
figuration level for the cookie persistence template:
[no] match-type
{server [service-group] | service-group}
The default granularity is port-level granularity as described above. (There

is no port keyword.)
To use the service-group option with port-level granularity, enter the fol-
lowing command: match-type service-group
To use the service-group option with server-level granularity, enter the fol-
lowing command: match-type server service-group
CLI Example
The following commands configure a cookie persistence template named

“persist-cookie-sg” and enable port-level persistence with support for URL
switching or host switching:
AX(config)#slb template persist cookie persist-cookie-sg
AX(config-cookie persistence template)#name SGCookie
AX(config-cookie persistence template)#match-type service-group
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL Failover
Using URL / Host Switching along with Source IP Persistence

By default, if URL / host switching is configured along with source IP per-
sistence, the URL / host switching settings are not used. Instead, the default
service group is always selected. To enable URL / host switching to be used
along with source IP persistence, you must use the match-type service-
group option in the source IP persistence template.
For more information, see the description of the slb template persist
source-ip command in the “Config Commands: SLB Templates” chapter of
the AX Series CLI Reference.
URL Failover
The AX device can send an HTTP 302 Redirect message to a client when
the real servers for the URL requested by the client are unavailable.
FIGURE 44 URL Failover
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL Failover
In this example, a client sends a request for www.example.com (virtual IP
address 192.168.10.10). However, this VIP is unavailable because all the
real servers are failing their health checks. The AX device is configured to
send an HTTP 302 Redirect message if the VIP is down, redirecting clients
to www.example.com.
By default, URL failover is not configured. To configure it, you specify the
URL to which to redirect clients. Like the other HTTP options, you can
apply this option to a virtual port by configuring the option in an HTTP tem-
plate, and binding the template to the virtual port.
Note: The URL failover option does not affect redirect messages sent by real
servers. To alter redirect messages from real servers, use the URL redi-
rect-rewrite option instead. (See “URL Redirect Rewrite” on page 138.)
Configuring URL Failover

The following sections show how to configure URL failover.
USING THE GUI

2. In the URL Failover field of the HTTP tab, enter the URL to which to
redirect clients.
USING THE CLI
plate:
failover-url url-string
CLI Example
The following commands implement the URL failover configuration shown


AX(config)#slb template http urlfailover
AX(config-HTTP template)#failover-url www.example2.com
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
5xx Retry and Reassignment
AX(config-slb virtual server-slb virtua...)#template http urlfailover
5xx Retry and Reassignment

By default, if a real server replies to a request with a 5xx status code (for
example, HTTP 503 – Service Unavailable), the AX device forwards the
error to the client.
HTTP templates have an option to override this behavior. You can configure
the AX device to retry sending a client’s request to a service port that replies
with an HTTP 5xx status code, and reassign the request to another server if
the first server replies with a 5xx status code. The AX device is allowed to
reassign the request up to the configured number of retries.
For example, assume that a service group has three members (s1, s2, and
s3), and the retry is set to 1. In this case, if s1 replies with a 5xx status code,
the AX device reassigns the request to s2. If s2 also responds with a 5xx sta-
tus code, the AX device will not reassign the request to s3, because the max-
imum number of retries has already been used.
Depending on the 5xx retry option you configure, either the service port and
server remain eligible for more client requests, or the AX device briefly
stops sending client requests to the service port and server.
Note: Server re-selection is not performed if Layer 3 features such as PBSLB or

source-IP persistence are configured on the virtual port. These features
override the server re-selection.
Note: Use of this HTTP template option also requires the strict-transaction-
switch option to be used in the same HTTP template. (See “Strict Transac-
tion Switching” on page 140.)
USING THE CLI

To configure server re-selection if a real server repeatedly replies with 5xx
status codes, use one of the following commands at the configuration level
for the HTTP template.
[no] retry-on-5xx-per-req num
[no] retry-on-5xx num
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Content Compression
The first command continues to use the service port and server for client
requests, even after a reassignment has occurred. The second command
briefly stops using the service port and server after a reassignment occurs.
The num option specifies the number of times the AX device will resend the
request to the server before assigning the request to another server. You can
specify 1-3 retries. The default is 3.
An HTTP template can contain only one of the commands shown above.
CLI Example
The following commands configure an HTTP template to reselect a server if
the initially selected server responds 4 times to a client’s request with a 5xx
status code. The AX device briefly stops using the service port and server
following reassignment.
AX(config)#slb template http 5xxretry
AX(config-HTTP)#strict-transaction-switch
AX(config-HTTP)#retry-on-5xx
Content Compression
Most types of real servers are able to compress media (content) before send-
ing it to clients. Compression reduces the amount of bandwidth required to
send content to clients.
Although compression optimizes bandwidth, compression also can some-

times actually hinder overall website performance, if the real servers spend
a lot of their CPU resources performing the compression.
To maximize the benefits of content compression, you can enable the AX

device to perform compression for the real servers.
Compression is disabled by default. When you enable it, the AX device

compresses media of types “text” and “application” by default. You can
configure the AX device to compress additional media types You also can
configure the AX device to exclude specific media types and even specific
URIs from compression.
Accept-Encoding Field
An HTTP request from clients usually contains an Accept-Encoding field in

the header. This field indicates to the real server whether the client is willing
to accept compressed content.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Content Compression
If compression is enabled on the real server, the real server will compress
content before sending it to a client, if the client’s request contains the
Accept-Encoding field with the “compress” value for the requested content
type.
By default, when you enable compression on the AX device, the device

removes the entire Accept-Encoding field from the request before sending
the request to the server. As a result, the server does not compress the con-
tent before sending it in the reply. The AX device compresses the content,
then sends the reply with the compressed content to the client.
If you still want the server to compress some content, you can configure the
AX device to leave the Accept-Request field unchanged. In this case, com-
pression is performed by the real server instead of the AX device, if the
server is configured to perform the compression. The AX device can still
compress content that the real server does not compress.
Compression Level
The AX device supports compression level 1-9. Each level provides a
higher compression ratio, beginning with level 1, which provides the lowest
compression ratio. A higher compression ratio results in a smaller file size
after compression. However, higher compression levels also require more
CPU processing than lower compression levels, so performance can be
affected.
The default compression level is 1, which provides the fastest compression
speed but with the lowest compression ratio.
Note: The actual performance impact of a given compression level depends on

the content being compressed. For example, if the content has a lot of
repeated string patterns (for example, XML files), compression is faster
than it is for content with few repeated string patterns (for example,
graphics).
Hardware-Based Compression
Hardware-based compression is available using an optional hardware mod-
ule in new AX devices, on the following models: AX 2100, AX 2200,
AX 3100, and AX 3200.
Note: Installation of the compression module into AX devices in the field is not
supported. Contact A10 Networks for information on obtaining an AX
device that includes the module.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Content Compression
Hardware-based compression is disabled by default. When you enable it, all
compression settings configured in HTTP templates, except the compres-
sion level, are used.
Note: Hardware-based compression is automatically set on the module and can

not be set using a template. The module always uses the same compres-
sion level, regardless of the compression level configured in an HTTP
template.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Content Compression
How the AX Device Determines Whether to Compress a File

The AX device uses the following process to determine whether to com-
press a file before sending it to a client.
FIGURE 45 Content Compression
Note: If the AX device is configured to leave the Accept-Encoding field

unchanged, and the real server has already compressed the file, the AX
device forwards the compressed file without recompressing it.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Content Compression
Configuring Content Compression

The following sections show how to configure content compression.
USING THE GUI

1. Access the configuration tabs for the HTTP template. (See “HTTP Tem-
plate Configuration” on page 106.)
2. Click Enabled next to Compression Flag.
3. To keep the Accept-Encoding field in client requests, select Enabled

next to Compression Keep Accept Encoding. Otherwise, to remove the
field, leave this option disabled.
4. To specify the minimum content length that is eligible for compression,

enter the minimum number of bytes the content must be in the Compres-
sion Content Length field.
5. To add more content types to be compressed:

a. Click the Compression Type tab.
b. In the Type field, enter the string for a content type to compress.
c. Click Add.
d. Repeat step b and step c for each type of content to compress.
6. Click OK.
7. If your AX device supports hardware-based compression, enable the

feature:
b. On the menu bar, select Global.
c. Select Enabled next to Hardware Compression.
d. Click OK.
Note: If the Hardware Compression option is not present, your AX device does
not contain a compression module.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Content Compression
USING THE CLI
To configure HTTP compression, use the following commands:
[no] slb template http template-name
Enter this command at the global configuration level of the CLI. The com-
mand changes the CLI to the configuration level for the template.
[no] compression enable
This command enables HTTP compression.
[no] compression level number
This command changes the compression level (for software-based compres-

sion only). The number option specifies the compression level and can be
1-9. The default is 1.
[no] compression minimum-content-length number
This command changes the minimum payload size that is eligible for com-
pression. You can specify 0-2147483647 bytes. The default is 120 bytes.
[no] compression content-type content-string
[no] compression exclude-content-type

content-string
These commands explicitly include or exclude specific media types for

compression. By default, media types “text” and “application” are included
and all other media types are excluded. The order in which content-type and
exclude-content-type filters appear in the configuration does not matter.
[no] compression exclude-uri uri-string
This command excludes an individual URI from being compressed. The

URI string can be 1-31 characters. An HTTP template can exclude up to 10
URI strings.
[no] compression keep-accept-encoding
This command configures the AX device to leave the Accept-Encoding

field in HTTP requests from clients instead of removing the field. When
keep-accept-encoding is enabled, compression is performed by the real
server instead of the AX device, if the server is configured to perform the
compression. The AX device compresses the content that the real server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Content Compression
does not compress. This option is disabled by default, which means the AX
device performs all the compression.
To display compression statistics, use the following command:
show slb http-proxy [detail]
To enable hardware-based compression (if supported on your AX device),

use the following command at the global configuration level of the CLI:
[no] slb hw-compression
To display statistics for the feature, use the following command:
show slb hw-compression
Note: If the slb hw-compression and show slb hw-compression commands are
not in the CLI, your AX device does not contain a compression module.
CLI Example
The following commands configure an HTTP template called "http-com-

press" that uses compression level 5 to compress files with media type
"application" or "image". Files with media type "application/zip" are explic-
itly excluded from compression.
AX(config)#slb template http http-compress
AX(config-HTTP template)#compression enable
AX(config-HTTP template)#compression level 5
AX(config-HTTP template)#compression content-type image
AX(config-HTTP template)#compression exclude-content-type application/zip
The following command displays HTTP compression statistics. The

counters are in bytes and apply to all HTTP compression configured in all
HTTP templates on the AX device. The compression counters are shown in
bold type.
AX(config-HTTP template)#show slb http-proxy
Total
------------------------------------------------------------------
Curr Proxy Conns 58
Total Proxy Conns 49
HTTP requests 306
HTTP requests(succ) 269
No proxy error 0
Client RST 17
Server RST 0
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Client IP Insertion / Replacement
No tuple error 0
Parse req fail 0
Server selection fail 0
Fwd req fail 0
Fwd req data fail 0
Req retransmit 0
Req pkt out-of-order 0
Server reselection 0
Server premature close 0
Server conn made 50
Source NAT failure 0
Tot data before compress 1373117
Tot data after compress 404410
The following commands enable hardware-based compression and display

statistics for the feature:
AX(config)#slb hw-compression
AX(config)#show slb hw-compression
Hardware compression device is installed.
Hardware compression module is enabled.
Total
------------------------------------------------------------------
total request count 177157
total submit count 177157
total response count 177157
total failure count 0
last failure code 0
compression queue full 0
max queued request count 84
max queued submit count 68

Many websites find it useful to know the IP addresses of clients. When the
default NEtwork Address Translation (NAT) settings for SLB are used, the
source IP address of a request received by the AX device continues to be the
source IP address when the AX device sends the request to a real server. The
real server therefore knows the IP addresses of its clients. (An example is
shown in Figure 141 on page 483.)
However, in configurations where IP source NAT is enabled for SLB, the

client’s IP address is not the source IP address in the request received by the
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
real server. Instead, the source IP address of the request is the address into
which the AX device translated the client’s IP address.
To add the client’s IP address back to the request, you do not need to change
the network configuration or NAT settings. Instead, you can simply enable
the AX device to insert the client’s IP address into the header of the client’s
GET request before sending the request to a real server.
Figure 46 shows an example of client IP insertion.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 46 Client IP Insertion
In this example, SLB source NAT changes the source address of the client’s
GET request from 192.168.100.3 to 10.20.20.11. However, the client’s
source IP address is preserved within the HTTP header of the request, by
inserting the address into the X-ClientIP field.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
This option inserts the client’s IP address into the X-ClientIP field by
default. However, you can specify another field name instead. For example,
you can configure the option to insert the client IP address into the
X-Forwarded-For field.
Note: To insert HTTP header fields with other types of values, or to erase fields,
see “Header Insertion / Erasure” on page 133.
Replace Option
By default, the client IP address is appended to addresses already in the tar-

get header field. You can configure the AX device to replace any addresses
that are already in the field.
Without this option, the client IP address is appended to the lists of client IP
addresses already in the header. For example, if the header already contains
“X-Forwarded-For:1.1.1.1”, the field:value pair becomes
“X-Forwarded-For:1.1.1.1, 2.2.2.2”.
If you enable replacement of the client IP addresses, the field:value pair

becomes “X-Forwarded-For:2.2.2.2”.
Configuring Client IP Insertion / Replacement

The following sections show how to enable client IP insertion / replace-
ment.
USING THE GUI

2. On the HTTP template, select the “Header Name for Inserting Client IP”
checkbox.
This enables the option and displays the name of the header field to
which the client IP address will be added.
3. Optionally, to replace any client addresses that are already in the header,
select Replace. Without this option, the client IP address is appended to
the lists of client IP addresses already in the header.
4. To change the name of the field, edit the name. Otherwise, leave the
field name set to the default (X-ClientIP).
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Header Insertion / Erasure
USING THE CLI
plate:
insert-client-ip [http-fieldname] [replace]
The http-fieldname option specifies the HTTP field, for example:

X-Forwarded-For. Without this option, the client IP address is inserted into
the X-ClientIP field.
The replace option replaces any client addresses that are already in the
header.
CLI Example
The following commands implement the client IP insertion configuration

shown in Figure 46 on page 131.

AX(config)#slb template http insertclientip
AX(config-HTTP template)#insert-client-ip
AX(config-slb virtual server-slb virtua...)#template http insertclientip

You can configure the AX device to insert, replace, or erase headers in cli-
ent requests or server responses. Like other HTTP options, header insertion
and erasure are configured using HTTP template options. Insert and delete
options can be used in the same HTTP template.
An HTTP template can contain options to insert, replace, or erase a maxi-

mum of 8 headers.
Note: The header insert, replace, and erase options described in this section are
not supported with the fast-http service type. The AX device does not
allow an HTTP template with any of these header options to be bound to a
fast-http virtual port. Likewise, the AX device does not allow any of the
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
header options to be added to an HTTP template that is already bound to a
fast-http virtual port.
Note: To configure the AX device to insert the client’s IP address, see “Client IP
Insertion / Replacement” on page 129.
Note: Header insertion is not supported on fast-HTTP virtual ports.
Configuring Header Insertion / Replacement

To configure header insertion or replacement, specify the header (the
field:value pair), and the insert or replace option. The insert / replace option
can be one of the following:
• Insert-always – always inserts the field:value pair. If the request already
contains a header with the same field name, the new field:value pair is
added after the existing field:value pair. Existing headers are not
replaced.
• Insert-if-not-exist – inserts the header only if the packet does not already
contain a header with the same field name.
• Default behavior (neither of the options above) – inserts the header. If
the packet already contains one or more headers with the specified field
name, this option replaces the first header.
Effects of the Insert / Replace Options

Here are some examples of the effects of the insert / replace options: insert-
always, insert-if-not-exist, and the default (no options). For these examples,
assume that a client’s request packet already contains the following Cookie
headers: “Cookie: a=1” and “Cookie: b=2”.
GET / HTTP/1.1
Host: www.example.com
Cookie: a=1
Cookie: b=2
...
Effect When insert-always Is Used

If you configure an HTTP template to insert “Cookie: c=3”, and you use the
insert-always option, the client’s header is changed as follows:
GET / HTTP/1.1
Cookie: a=1
Cookie: b=2
Cookie: c=3
...
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Effect When insert-if-not-exist Is Used
If you configure an HTTP template to insert “Cookie: c=3”, and you use the
insert-if-not-exist option, the client’s header is changed only if it does not
contain any “Cookie” headers. Therefore, the client request in this example
is unchanged:
GET / HTTP/1.1
Cookie: a=1
Cookie: b=2
...
Effect When Default Behavior (Neither Option Above) Is Used

If you configure an HTTP template to insert “Cookie: c=3”, but you do not
use either the insert-always or insert-if-not-exist option, the header is
always inserted into the request. If the packet already contains a “Cookie”
header, the header is replaced. If the packet contains multiple “Cookie”
headers, the first one is replaced. Here is the result:
GET / HTTP/1.1
Cookie: c=3
Cookie: b=2
...
USING THE GUI

2. Click on the Header Insert tab to display its fields.
3. To insert a request header:

a. In the Request section of the tab, enter the name:value pair in the
Name field.
b. By default, if a packet already contains one or more headers with the
specified field name, the command replaces the first header. Option-
ally, to change this behavior, select one of the following options
from the drop-down list next to the Name field:
• Insert Always – The AX device always inserts the field:value
pair. If the request already contains a header with the same field
name, the new field:value pair is added after the existing
field:value pair. Existing headers are not replaced.
• Insert if not already present – The AX device inserts the header
only if the packet does not already contain a header with the
same field name.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
c. Click Add.
4. To insert a response header, follow the same steps as those for inserting
a request header, but use the Response section of the tab.
USING THE CLI
To insert a header, use the following command:
[no] request-header-insert field:value

[insert-always | insert-if-not-exist]
The field:value pair indicates the header field name and the value to insert.
• By default, if a packet already contains one or more headers with the
specified field name, the command replaces the first header.
• If you use the insert-always option, the command always inserts the
field:value pair. If the request already contains a header with the same
field name, the new field:value pair is added after the existing
field:value pair. Existing headers are not replaced.
• If you use the insert-if-not-exist option, the command inserts the header
only if the packet does not already contain a header with the same field
name.
To insert a field:value pair into response headers, use the following com-
mand:
[no] response-header-insert field:value

[insert-always | insert-if-not-exist]
CLI Examples
The following command configures an HTTP template that inserts
“Cookie: c=3” into every HTTP request. If the request already contains
“Cookie” headers, the first header is replaced.
AX(config)#slb template http replace-cookie
AX(config-HTTP template)#request-header-insert "Cookie: c=3"
The following command configures an HTTP template that always inserts

“Cookie: c=3” into HTTP requests, but does not replace other “Cookie”
headers. The “Cookie: c=3” header is added after any “Cookie” headers that
are already present in the request.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
AX(config)#slb template http add-cookie
AX(config-HTTP template)#request-header-insert "Cookie: c=3" insert-always
The following command configures an HTTP template that inserts

“Cookie: c=3” into HTTP requests, but only if the requests do not already
have a “Cookie” header.
AX(config)#slb template http add-cookie-unless-present
AX(config-HTTP template)#request-header-insert "Cookie: c=3" insert-if-not-
exist
Configuring Header Erasure

The following sections show how to erase headers from HTTP requests or
responses.
USING THE GUI

2. Click on the Header Erase tab to display its fields.
3. To erase a request header:

a. In the Request section of the tab, enter the field name (the name por-
tion of the name:value pair) in the Name field.
b. Click Add.
4. To erase a response header, follow the same steps as those for erasing a
request header, but use the Response section of the tab.
USING THE CLI
To erase a header from requests, use the following command:
[no] request-header-erase field
The field value specifies the header name.
To erase a header from responses, use the following command:
[no] response-header-erase field
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL Redirect Rewrite
CLI Example
The following command removes the Set-Cookie header from HTTP

responses:
AX(config-HTTP template)#response-header-erase Set-Cookie

The AX device can be configured to alter redirect messages sent by real
servers. You can use redirect-rewrite options to make the following types of
changes:
• URL change – You can change the URL before sending the redirect to
the client. For example, if the real server redirects the client to
http://www.example1.com, you change the URL to
http://www.example2.com or https://www.example2.com.
• Secure redirection – You can change an unsecure redirect (HTTP) to a
secure one (HTTPS). For example, if the real server redirects the client
to http://www.example1.com, you change the URL to
https://www.example1.com.
You can use one or both options.
Redirect-Rewrite Rule Matching

If a URL matches on more than redirect-rewrite rule within the same HTTP
template, the AX device selects the rule that has the most specific match to
the URL. For example, if a server sends redirect URL 66.1.1.222/000.html,
and the HTTP template has the redirect-rewrite rules shown below, the AX
device will use the last rule because it is the most specific match to the
URL:
slb template http 1
redirect-rewrite match /00 rewrite-to http://66.1.1.202/a
redirect-rewrite match /000.html rewrite-to /001.gif
redirect-rewrite match 66.1.1.222/000.html rewrite-to 66.1.1.202/003.bmp
Configuring URL Redirect Rewrite
USING THE GUI

2. Click the Redirect Rewrite tab.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. To change the URL:
a. In the Pattern field, enter the URL string to be changed.
b. In the Redirect To field, enter the new URL.
4. To change “http://” to “https://”:

a. Select Enable next to HTTPS Rewrite.
b. To change the SSL port number, edit the number in the field. (The
default is 443.)
5. Click OK.
USING THE CLI
To change the URL in redirect messages from servers, enter the following
command at the configuration level for the HTTP template:
redirect-rewrite match url-string

rewrite-to url-string
To change “http://” to “https://”, enter the following command at the config-

uration level for the HTTP template:
redirect-rewrite secure {port tcp-portnum}
The default SSL port number (tcp-portnum) is 443. If you do not spec-
ify a port number, the AX device does not include a port number in the
URL. In this case, the client browser adds the SSL port number when send-
ing a request to the redirect URL.
If you do specify the port number, the AX includes the port number in the
redirect URL.
CLI Example
The following commands configure the AX device to change unsecure

URLs to secure URLs in redirect messages.
The following commands configure the HTTP template. Redirect URLs that
begin with “http://” are changed to “https://”. The URLs in the redirect mes-
sages are otherwise unchanged.
AX(config)#slb template http secureredirect
AX(config-HTTP template)#redirect-rewrite secure
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Strict Transaction Switching
AX(config-slb virtual server-slb virtua...)#template http secureredirect
Strict Transaction Switching

By default, the AX device performs server selection once for a client ses-
sion. After the initial selection, all requests within that session are automati-
cally sent to the same real server. A new server is selected during the session
only if the server that was originally selected is no longer available.
If the load among real servers appears to be unbalanced, you can enable
strict transaction switching to rebalance the load. The strict transaction
switching option forces the AX device to perform server selection for each
request within every session.
Note: Use this option only if needed, and disable the option once the server load
is rebalanced. This option makes server selection much more granular but
also uses more AX system resources.
Enabling Strict Transaction Switching

The following sections show how to enable strict transaction switching.
USING THE GUI

2. On the HTTP tab, select Enabled next to Strict Transaction Switch.
USING THE CLI
To enable strict transaction switching, enter the following command at the

configuration level for the HTTP template:
strict-transaction-switch
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
FTP Load Balancing
This chapter describes how to configure SLB for FTP services.
Overview
FTP load balancing optimizes the download experience for clients by bal-
ancing FTP traffic across servers in a server farm. You can provide clients
with a single, published virtual IP address for large files, and serve the files
from a set of real servers.
Figure 47 shows an example of an FTP load balancing solution.
FIGURE 47 FTP Load Balancing
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
In this example, FTP files are served by three real servers. Each server has
the same set of files available for download. One of the servers also pro-
vides the HTML pages for the download site.
The AX device supports both the passive and port FTP modes.
The AX Series device sends all HTTP requests to server ftp-2, and balances
FTP requests among servers ftp-2, ftp-3, and ftp-4. In this example, the
load-balancing method is changed from the default, round robin, to
weighted round robin.
By assigning a weight to a real server and using a weighted load-balancing

metric, you can bias load-balancing decisions to favor that server. This
example assumes that the servers have equivalent capacity and perfor-
mance. The differing weights compensate for the greater load to be placed
on the server that is handling the HTTP requests.
Service Groups
This example uses a single service group containing all three servers. To
provide weighted load balancing as described above, the load balancing
method is changed from the default (round robin) to weighted round robin.
Templates
In this example, two TCP templates are required.

• For HTTP, the default TCP template is used. You do not need to explic-
itly bind this template to the HTTP port on the virtual server. The AX
device automatically binds this template to a virtual TCP port on a vir-
tual server when you create the port, unless you explicitly bind another
TCP template to the virtual port instead.
• For FTP, a custom TCP template is required, with the idle time set to a
high value, to prevent FTP download sessions from timing out if they
pause for a while. This custom TCP template must be explicitly bound
to the virtual FTP port on the virtual server. In this case, the custom tem-
plate is used instead of the default TCP template.
The default HTTP template is assigned to the virtual HTTP port by default.
However, the parameters in the default HTTP template are unset by default.
For this configuration, you do not need to configure a different HTTP tem-
plate or change settings in the default one.
This example does not include configuration of server or port templates, so

the default templates and their settings are applied.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FTP Load Balancing
For more information about templates, see the following:
• “Service Template Parameters” on page 599
• “Server and Port Templates” on page 281
Health Monitors
This example uses the following health monitors to check the real servers:
• Ping – Tests Layer 3 connectivity to the servers. The Ping health moni-
tor is already configured by default, and is enabled by default when you
add the real server.
• HTTP – Tests the HTTP port by requesting a Web page from the port. In
this example, the default settings are used: Every 30 seconds, the AX
device sends an HTTP Get request for the index.html page.
• FTP – Tests the FTP port by sending a login request to the port. In this
example, the default settings are used: Every 30 seconds, the AX device
sends an anonymous FTP login request to port 21.
The Ping health monitor is already configured by default, and is enabled by

default when you add the real server.
The HTTP and FTP monitors must be configured and applied to the real
server ports.
The AX device has default Layer 4 health checks it uses to test the TCP and
UDP transport layers. This configuration also uses those health checks. (For
information, see “Default Health Checks” on page 297.)

To configure FTP load balancing:
1. Configure HTTP and FTP health methods, to use for checking the
health of the HTTP and FTP ports on the servers.
2. Configure the real servers:

a. For each server, add its FTP port and enable health checking of the
port, using the FTP health method configured in step 1.
b. For the server that will serve the Web pages, add the server’s HTTP
port and enable health checking of the port, using the HTTP health
method configured in step 1.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
c. Assign weight 80 to the HTTP/FTP server. Assign weight 100 to
each of the FTP servers that will not also be handling HTTP. These
weights will cause the AX device to select the HTTP/FTP server for
FTP only 80% as often as each of the other servers.
3. Configure a TCP template and set the idle time in the template to a high
value.
4. Configure a service group for HTTP and add the HTTP server to it.
5. Configure another service group for FTP and add the FTP servers to it.
6. Configure the virtual server:

a. Add TCP ports for HTTP and FTP.
b. Bind the HTTP port to the HTTP service group.
c. Bind the FTP port to the FTP service group and to the TCP tem-
plate.
USING THE GUI
To configure the health monitors

2. Click Add.
3. On the Health Monitor tab, enter a name for the monitor in the Name
field.
4. On the Method tab to display the Method tab.
5. On the Method tab, select HTTP from the Type drop-down list.
6. Click OK. The new health monitor appears in the health monitor table.
7. Repeat step 2 through step 6 to configure the FTP health monitor. In

step 5, select FTP instead of HTTP.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 48 Config > Service > Health Monitor (for HTTP monitor)
FIGURE 49 Config > Service > Health Monitor - Method tab (for FTP
monitor)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 50 Config > Service > Health Monitor (showing configured health
monitors)
To configure the real servers

2. Select Server on the menu bar.
3. Click Add.
4. On the General tab, enter a name for the server in the Name field.
5. Enter the IP address of the server in the IP Address field.
6. Change the weight be editing the number in the Weight field. In this
example, change the weight for the HTTP/FTP server to 80 and change
the weights of the two other FTP servers to 100.
7. On the Port tab, enter the HTTP (or FTP) port number in the Port field.
8. Leave the transport protocol set to TCP.
9. In the Health Monitor drop-down list, select the HTTP or FTP health
monitor you configured in “To configure the health monitors” on
page 144. (Select the monitor that matches the port type, HTTP or FTP.)
10. Click Add. The new port appears in the port list.
11. Click OK. The new server appears in the server table.
12. Repeat step 3 through step 11 for each of the other real servers.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 51 Config > Service > SLB > Server (ftp-2)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 54 Config > Service > SLB > Server (showing configured real
servers)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure the TCP template for FTP
2. Select L4 > TCP on the menu bar.
3. Click Add.
4. Enter a name for the template in the Name field.
5. In the Idle Timeout field, enter 15000.
6. Click OK. The new template appears in the TCP template table.
FIGURE 55 Config > Service > Template > L4 > TCP
To configure a service group for HTTP

2. Select Service Group on the menu bar, if not already selected.
3. Click Add.
4. On the Service Group tab, enter a name in the Name field.
5. Leave the transport protocol set to TCP.
6. In the Algorithm field, select the load balancing method. For this exam-
ple, select Weighted Round Robin.
7. Enter the real server’s IP address in the Server field.
8. Enter the protocol port in the Port field.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
9. Click Add. The server and port appear in the member list. Repeat for
each combination of server and port. In this example, add member
10.10.10.2 for port 80 and again for port 21 to service group http-grp.
10. Click OK. The new service group appears in the service group table.
FIGURE 56 Config > Service > Service Group (for HTTP)
To configure a service group for FTP

Repeat the procedure in “To configure a service group for HTTP” on
page 150, with the following differences:
• In the Algorithm drop-down list, select Weighted Round Robin. (If your
configuration does not use weights to bias server selection, you can
leave this field set to Round Robin.)
• Add members 10.10.10.2-4 for port 21.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 57 Config > Service > Service Group (for FTP)
FIGURE 58 Config > Service > Service Group (service groups added)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure the virtual server
2. Select Virtual Server on the menu bar, if not already selected.
3. Click Add.
4. On the General tab, enter a name in the Name field.
5. Enter the virtual IP address in the IP Address field. This is the IP address
to which clients will send HTTP and FTP requests.
6. On the Port tab, click Add. The Virtual Server Port tab appears.
7. In the Type drop-down list, select the service type.

In this example, there are two services, HTTP and FTP. Select HTTP
first and go to the next step.
8. Edit the number in the Port field to match the protocol port that clients
will request at the virtual IP address.
9. Select the service group from Service Group drop-down list.

In this example, select http-grp for HTTP and ftp-grp for FTP.
10. Click OK. The port and service group appear in the virtual port list.
11. Repeat from step 6 for the FTP service.

In this example, select the TCP template you configured in “To config-
ure the TCP template for FTP” on page 150.
12. Click OK. The new virtual server appears in the virtual server table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 59 Config > Service > Virtual Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 60 Config > Service > Virtual Server - Virtual Server Port tab (for
HTTP)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 61 Config > Service > Virtual Server - Virtual Server Port tab (for
FTP)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 62 Config > Service > Virtual Server - Port tab (ports added)
FIGURE 63 Config > Service > Virtual Server (virtual server added)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI

1. To configure the health monitors, use the following commands:
Enter this command at the global Config level of the CLI to create a
monitor and access the configuration level for it.
To configure an HTTP health method, use the following command at the
configuration level for the monitor:
method http
To configure an FTP health method, use the following command at the
configuration level for the monitor:
method ftp
In this example, none of the optional parameters are used. The default
settings are used for both types of health monitors. (For information
about the optional parameters, see the AX Series CLI Reference.)

Enter this command at the global Config level of the CLI. The command
creates the server and changes the CLI to the configuration level for it.
weight number
The slb server command creates the real server. The weight command
assigns a weight to the server, for use with weighted load-balancing
methods.
port port-num tcp
The port command adds a TCP port for HTTP or FTP, and changes the
CLI to the configuration level for the port. Enter a separate port com-
mand for each port number to be load balanced.
To assign the HTTP or FTP health monitor to a port, use the following
command at the configuration level for the port.
3. To configure the TCP template for FTP, use the following commands:
slb template tcp template-name
This command creates the TCP template and changes the CLI to the
configuration level for the template.
idle-timeout seconds
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The idle-timeout command specifies the number of seconds a TCP ses-
sion can remain idle. The default is 60 seconds. For this example, set the
idle timeout to 1500 seconds (the maximum).
4. To configure a service group for HTTP, use the following commands:

This command creates the service group and changes the CLI to the con-
figuration level for it.
The member command adds the HTTP server to the service group. The
server-name is the name you used when you configured the real server.
The portnum is the protocol port number configured on the real server.
Use the following command to change the load balancing method:
method
{fastest-response |
least-connection |
service-least-connection |
weighted-least-connection |
service-weighted-least-connection |
weighted-rr
}
In this example, use the weighted-rr option. (For descriptions of the
other options, see the AX Series CLI Reference.)
5. To configure a service group for FTP, use the following commands:

method weighted-rr
The member command adds the servers and their ports to the service
group. Enter a separate command for each port. The method command
changes the load-balancing method from the default (simple round
robin) to weighted round robin.
6. To configure the virtual server, use the following commands:

This command creates the virtual server and changes the CLI to the con-
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
port port-number http
port port-number ftp
The port commands add virtual ports for HTTP and FTP. For each port,
the command changes the CLI to the configuration level for the port,
where the following commands are used:
template tcp template-name
The service-group command binds the virtual port to a service group.
The template tcp command binds the virtual port to a TCP template.
CLI CONFIGURATION EXAMPLE
The following commands configure the HTTP and FTP health monitors:
AX(config)#health monitor http-monitor
AX(config-health:monitor)#method http
AX(config)#health monitor ftp-monitor
AX(config-health:monitor)#method ftp

AX(config)#slb server ftp-2 10.10.10.2
AX(config-real server)#weight 80
AX(config-real server-node port)#health-check http-monitor
AX(config-real server-node port)#health-check ftp-monitor
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the TCP template for use with FTP:
AX(config)#slb template tcp ftp-longidletime
AX(config-L4 TCP LB template)#idle-timeout 15000
AX(config-L4 TCP LB template)#exit
The following commands configure the service group for HTTP:

AX(config)#slb service-group http-grp tcp
AX(config-slb service group)#member ftp-2:8801
The following commands configure the service group for FTP:

AX(config)#slb service-group ftp-grp tcp
AX(config-slb service group)#method weighted-rr

AX(config)#slb virtual-server ftp-vip 192.168.10.21
AX(config-slb virtual server-slb virtua...)#service-group http-grp
AX(config-slb virtual server)#port 21 ftp
AX(config-slb virtual server-slb virtua...)#service-group ftp-grp
AX(config-slb virtual server-slb virtua...)#template tcp ftp-longidletime
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
SIP Load Balancing
This chapter describes Session Initiation Protocol (SIP) load balancing and
how to configure it.
Overview
AX Series devices support SIP load balancing. SIP load balancing balances
SIP registration messages from clients across a service group of SIP Regis-
trar servers. SIP load balancing enables you to offload registration process-
ing from other SIP servers so those servers can more efficiently process
other SIP traffic.
Figure 64 shows an example of a SIP load balancing configuration. The
commands to implement this configuration are shown in “Configuring SIP
Load Balancing” on page 164.
FIGURE 64 SIP Load Balancing
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring SIP Load Balancing

To configure SIP load balancing:
1. Configure SIP health monitors using the SIP health method.
2. Configure a real server for each SIP Registrar server, add the SIP port to
the server, and assign the SIP health monitor to the port.
3. Configure a real server as a proxy for each SIP server that will handle
SIP messages other than registration messages. Add the SIP port to each
server. The SIP port can be the same on the Registrar servers and these
proxy servers. The AX selects a service group based on the message
type.
4. Configure a service group for the Registrar servers and add them to the
group.
5. Configure a service group for the other SIP servers and add them to the
group. This is the SIP proxy group.
6. Configure a SIP template to redirect all SIP registration messages to the

SIP Registrar service group.
7. Configure a virtual server containing the SIP port and bind the port to
the SIP proxy group. Add the SIP proxy service group and the SIP tem-
plate to the port.
The following sections provide detailed steps and examples.
USING THE GUI

1. Configure a SIP health monitor for the Registrar servers:
a. Select Config > Service > Health Monitor.
b. Select Health Monitor on the menu bar.
c. Click Add.
d. On the Health Monitor tab, enter a name for the health monitor.
e. On the Method tab, select SIP in the Type drop-down list.
f. To send health checks to the default SIP port (5060), leave the port
unchanged.
Otherwise, to send the request to a different port, edit the port num-
ber in the Port field.
g. Select Register to send a REGISTER request. (By default, an
OPTION request is sent instead.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
h. Click OK. The new SIP health monitor appears in the Health Moni-
tor table.
2. Configure a SIP health monitor for the other SIP servers:

a. Click Add.
b. On the Health Monitor tab, enter a name for the health monitor.
c. On the Method tab, select SIP in the Type drop-down list.
d. To use the default monitoring settings for SIP (OPTION request sent
to port 5060), leave the other settings unchanged.
e. Click OK. The new SIP health monitor appears in the Health Moni-
tor table.
3. Configure a real server for the SIP Registrar server:

b. Select Server on the menu bar.
c. Click Add.
d. On the General tab, enter a name for the Registrar server.
e. Enter the IP address of the server.
f. On the Port tab, enter the SIP port number in the Port field.
g. In the Protocol drop-down list, select UDP.
h. In the Health Monitor drop-down list, select the health monitor.
i. Click Add. The port appears in the Port list.
j. Click OK. The server appears in the real server table.
4. Use the same steps to configure a real server as a proxy for each SIP
server that will handle SIP messages other than registration messages.
The steps are the same as the steps for adding the Registrar servers. (See
Figure 68.)
5. To configure a service group for the Registrar servers and add them to
the group:
a. Select Service Group on the menu bar.
b. Click Add.
c. On the Service Group tab, enter a name for the group.
d. In the Type drop-down list, select UDP.
e. On the Port tab, select the real server for the SIP Registrar server
from the Server drop-down list.
f. In the Port field, enter the SIP port number.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
g. Click Add.
h. Repeat for each Registrar server.
i. Click OK. The new service group appears in the service group table.
6. Use the same steps to configure a service group for the other SIP servers
and add them to the group. This is the SIP proxy group.
7. To configure a SIP template to redirect all SIP registration messages to

the SIP Registrar service group:
a. Select Config > Service > Template.
b. Select Application > SIP from the menu bar.
c. Click Add.
d. Enter a name for the template.
e. Optionally, erase, insert, or replace text in the SIP header.
f. In the Registrar Service Group drop-down list, select the service
group.
g. Click OK. The new SIP template appears in the SIP template table.
8. To configure a virtual server for the SIP proxy:

b. Select Virtual Server on the menu bar.
c. Click Add.
d. On the General tab, enter a name for the virtual server.
e. In the IP Address field, enter the IP address to which clients will
send SIP Registration messages.
f. On the Port tab, select SIP from the Type drop-down list.
g. In the Port field, enter the SIP port number.
h. In the Service Group drop-down list, select the SIP service group
you created above for non-registration traffic.
i. In the SIP Template drop-down list, select the SIP template.
j. Click Add. The port appears in the Port list for the virtual server.
k. Click OK. The virtual server appears in the virtual server table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GUI CONFIGURATION EXAMPLE
The following GUI examples show the configuration steps.
(example for Registrar servers)
(example for other SIP servers)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 68 Config > Service > SLB > Server - Registrar and Proxy servers
added
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 69 Config > Service > Service Group (registrar group)
FIGURE 70 Config > Service > Service Group - groups added
FIGURE 71 Config > Service > Template > Application > SIP
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 72 Config > Service > Template > Application > SIP - template
added
FIGURE 73 Config > Service > Virtual Server - Port tab
FIGURE 74 Config > Service > Virtual Server - server added
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
1. To configure a SIP health monitor using the SIP health method, use the
following commands:
Enter this command at the global Config level.
method sip [register [port port-num]]
Enter this command at the configuration level for the health method.
The SIP health monitor sends an OPTION request to port 5060 by
default.
To send a REGISTER request instead, use the register option. To send
the request to a port other than 5060, use the port option to specify the
port number.
2. To configure a real server for a SIP Registrar server, add the SIP port to
it, and apply the SIP health monitor to the port, use the following com-
mands:
port port-num udp
Enter this command at the configuration level for the real server.
Enter this command at the configuration level for the SIP port.
3. To configure a real server as a proxy for each SIP server that will handle
SIP messages other than registration messages, use the same commands
as in step 2.
4. To configure a service group for the Registrar servers and add them to
the group, use the following commands:
slb service-group group-name udp
member server-name [priority number]
Enter this command at the configuration level for the service group.
5. To configure a service group for the other SIP servers and add them to
the group, use the same commands as in step 4.
6. To configure a SIP template to redirect all SIP registration messages to

the SIP Registrar service group, use the following commands:
slb template sip template-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
registrar service-group group-name
header-erase string
header-insert string
header-replace string new-string
timeout minutes
pass-real-server-ip-for-acl acl-id
The header-erase, header-insert, and header-replace commands edit
information in the SIP header of each SIP packet before sending it to the
service group. Each command erases, inserts, or replaces a single header
field.
The timeout command specifies how many minutes the AX device
leaves a SIP call session up. You can specify 1-250 minutes. The default
is 30.
The pass-real-server-ip-for-acl command disables reverse NAT based
for traffic from the server, based on IP address. This command is useful
in cases where a SIP server needs to reach another server, and the traffic
must pass through the AX device. (See “Disabling Reverse NAT Based
on Destination IP Address” on page 174.)
Enter these commands at the configuration level for the SIP template.
Caution: A10 Networks recommends that you do not set the timeout
to a value lower than 30 minutes. The SIP termination message
(Bye) does not necessarily go through the AX device, thus the AX
device does not know for certain that a conversation has ended.
7. To configure a virtual server for the SIP proxy servers (the servers that
will handle all other SIP traffic except registration messages), use the
following commands:
port port-number sip
Enter this command at the configuration level for the virtual server.
template sip template-name
Enter these commands at the configuration level for the virtual port.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The commands in the following example implement the SIP load balancing
configuration shown in Figure 64 on page 163.
The following commands configure the SIP health monitors:

AX(config)#health monitor sip_monitor
AX(config-health:monitor)#method sip
AX (config-health:monitor)#exit
AX(config)#health monitor sipreg_monitor
AX(config-health:monitor)#method sip register
AX (config-health:monitor)#exit
The following commands configure the Registrar servers:

AX(config)#slb server Registrar1 10.10.10.56
AX(config-real server)#port 5060 udp
AX (config-real server-node port)#health-check sipreg_monitor
AX (config-real server-node port)#exit
AX(config)#slb server Registrar2 10.10.10.57
AX (config-real server-node port)#health-check sipreg_monitor
AX (config-real server-node port)# #exit
AX(config-real serverexit
The following commands configure the SIP proxy servers:

AX(config)#slb server Proxy3 10.10.20.11
AX (config-real server-node port)#health-check sip_monitor
AX(config)#slb server Proxy4 10.10.20.12
AX (config-real server-node port)#health-check sip_monitor
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the service groups:
AX(config)#slb service-group Registrar_gp udp
AX(config-slb service group)#member Registrar1:5060
AX(config-slb service group)#member Registrar2:5060
AX(config)#slb service-group sip5060 udp
AX(config-slb service group)#member Proxy3:5060
AX(config-slb service group)#member Proxy4:5060
The following commands configure the SIP template:

AX(config)#slb template sip Registrar_template
AX(config-SIP LB template)#registrar service-group Registrar_gp
AX(config-SIP LB template)#header-insert Max-Forwards:22
AX(config-SIP LB template)#header-replace Max-Forwards 15
AX(config-SIP LB template)#header-erase Contact
AX(config-SIP LB template)#exit
The following commands configure the VIP for the SIP registrar:
AX(config)#slb virtual-server sip1 192.168.20.1
AX(config-slb virtual server)#port 5060 sip
AX(config-slb virtual server-slb virtua...)#service-group sip5060
AX(config-slb virtual server-slb virtua...)#template sip Registrar_template
Disabling Reverse NAT Based on Destination IP Address

You can use a SIP template to disable reverse NAT for traffic from servers,
based on IP address. This option is useful in cases where a SIP server needs
to reach another server, and the traffic must pass through the AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 75 Revere NAT Disabled for Traffic from a SIP Server
By default, the AX device performs reverse NAT on all traffic from a SIP
server before forwarding the traffic. Reverse NAT translates the source IP
address of return traffic from servers to clients back into the VIP address
before forwarding the traffic to clients.
However, if the SIP server needs to reach another server, and the traffic
must pass through the AX device, the destination server will receive the
traffic from the VIP address instead of the SIP server address.
To disable reverse NAT in this type of situation:

1. Configure an extended ACL that matches on the SIP server IP address
or subnet as the source address, and matches on the destination server’s
IP address or subnet as the destination address.
2. Configure a SIP template that disables reverse NAT based on the ACL.
3. Bind the SIP template to the SIP virtual port.
USING THE GUI

2. On the menu bar, select Application > SIP.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. Click on the template name of click Add to create a new one.
4. Select the ACL from the Pass Real Server IP for ACL drop-down list.
USING THE CLI
To disable reverse NAT based on the IP addresses in an extended ACL, use

the following command at the configuration level for the SIP template:
[no] pass-real-server-ip-for-acl acl-id
The acl-id specifies an extended ACL ID (100-199).
CLI Example
The commands in this section are applicable to Figure 75.
The following command configures an extended ACL that matches on the

SIP server’s subnet and on the database server’s subnet:
AX(config)#access-list 101 permit ip 10.10.10.0 /24 10.20.20.0 /24
The following commands configure a SIP template that disables reverse

NAT for traffic that matches the ACL:
AX(config)#slb template sip sip1
AX(config-sip)#pass-real-server-ip-for-acl 101
AX(config-sip)#exit
The following commands bind the SIP template to the SIP virtual port:
AX(config)#slb virtual-server sip-vip 192.168.20.1
AX(config-slb vserver)#port 5060 sip
AX(config-slb vserver-vport)#template sip sip1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
SSL Offload and SSL Proxy
This chapter describes how to configure optimization of Secure Sockets

Layer (SSL).
Overview
The AX device provides the following types of SSL optimization:
• SSL Offload – The AX device applies Layer 7 features to HTTPS traffic
per your configured HTTP template options, such as those described in
“HTTP Options for SLB” on page 105.
• SSL proxy – The AX device acts as a Layer 4 SSL proxy for TCP ser-
vices such as POPS, SMTPS, IMAPS, and LDAPS.
SSL offload uses service type (virtual port type) HTTPS, and supports deep
packet inspection and header manipulation. SSL proxy uses service type
SSL-proxy and provides Layer 4 SLB but does not provide deep packet
inspection or header manipulation.
Both types of SSL optimization perform SSL handshakes, as well as

encryption / decryption. SSL certificates and keys are required. You can
import the certificates and keys or create them on the AX device.
Note: The AX device devices also support STARTTLS acceleration and encryp-
tion. See “STARTTLS for Secure SMTP” on page 195.
Choosing an SSL Optimization Implementation

To choose which of the SSL optimization features to implement in your
server farm, consider the following.
Implement SSL offload if the following are true:

• The traffic will be HTTPS traffic.
• Layer 7 processing (deep packet inspection or manipulation) is required.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Client SSL
Implement SSL proxy if the following are true:
• The traffic will be SSL-secured traffic over TCP, but not necessarily
HTTPS traffic.
• Layer 7 features are not required.

1. Import or create a certificate and its key to use for TLS sessions with
clients.
You can create a self-signed certificate on the AX device or import a
certificate.
The configuration example in this chapter uses an imported certificate.
For more information about certificate options, see “SSL Certificate
Management” on page 647.
2. Configure a client SSL template and add the certificate and key to it.
USING THE GUI

1. To import a certificate and its key to use for TLS sessions with clients:
a. Select Config > SLB > SSL Management.
b. On the menu bar, select Certificate.
c. Click Import.
d. In the Name field, enter a name for the certificate. This is the name
you will refer to when adding the certificate to a client-SSL or
server-SSL template.
e. Select Certificate from the Type drop-down list, if not already
selected.
f. Click Browse and navigate to the location of the certificate.
g. Click Open. The path and filename appear in the Source field.
h. Click OK. The certificate appears in the certificate and key list.
i. Click Import.
j. In the Name field, enter a name for the key. This is the name you
will refer to when adding the key to a client-SSL or server-SSL tem-
plate.
k. Select Key from the Type drop-down list.
l. Click Browse and navigate to the location of the key.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
m. Click Open. The path and filename appear in the Source field.
n. Click OK. The key appears in the certificate and key list.
2. To configure a client SSL template and add the certificate and key to it:
a. Select Configure > Service > Template.
b. Select SSL > Client SSL from the menu bar.
c. Click Add.
d. On the Client SSL tab, enter a name for the template in the Name
field.
e. In the Certificate Name drop-down list, select the certificate you
imported in the previous step.
f. In the Key Name field, select the private key you imported in the
previous step.
g. If the files are secured with a passphrase, enter the passphrase.
h. Click OK. The new template appears in the Client SSL template
table.
FIGURE 76 Configure > Service > SSL Management - Import (for the
certificate)
FIGURE 77 Configure > Service > SSL Management - Import (for the
private key)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 78 Configure > Service > Template > SSL > Client SSL
USING THE CLI

1. To import a certificate and key, use the following commands at the glo-
bal Config level of the CLI:
slb ssl-load certificate file-name url
slb ssl-load key file-name url
The url specifies the file transfer protocol, username (if required), direc-
tory path, and filename.
You can enter the entire URL on the command line or press Enter to dis-
play 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
2. To configure a client SSL template, use the following commands:

slb template client-ssl template-name
cert cert-name
Enter this command at the configuration level for the client SSL tem-
plate.
key key-name [passphrase passphrase-string]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands import certificates and keys, and configure a cli-
ent-SSL template to use them.
The following commands import an SSL certificate and key:

AX(config)#slb ssl-load certificate sslcert1.crt ftp:
Address or name of remote host []?1.1.1.2
User name []?axadmin
Password []?*********
File name [/]?sslcert1.crt
AX(config)#slb ssl-load key sslcertkey.pem ftp:
Password []?*********
File name [/]?sslcertkey.pem
The following commands configure a client SSL template to use the certifi-
cate and key:
AX(config)#slb template client-ssl sslcert-tmplt
AX(config-client SSL template)#cert sslcert.crt
AX(config-client SSL template)#key sslcertkey.pem
AX(config-client SSL template)#exit
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring HTTPS Offload

To configure the AX device to perform Layer 7 SLB for HTTPS clients:
1. Configure client SSL. (See “Configuring Client SSL” on page 178.)
2. Configure the real servers for the TCP service.
3. Configure a service group for the servers and add them to the group.
4. If needed for your specific application, configure HTTP template

options. (For information and examples, see “HTTP Options for SLB”
on page 105.)
5. Configure a virtual server and add a virtual port that has the service type
https. Bind the service-group to the virtual port and to the HTTP tem-
plate (if configured) and client-SSL template.
USING THE GUI

1. To configure real servers:
c. Click Add. The General tab appears.
d. On the General tab, enter a name for the server and enter its IP
address, in the Name and IP Address fields.
e. On the Port tab, enter the port number in the Port field.
f. In the Protocol drop-down list, select TCP, if not already selected.
g. Select the health monitor, if your configuration will use one.
h. Click Add. The port appears in the Port list.
i. Click OK. The server appears in the server table.
j. Repeat for each real server.
2. To configure a service group for the servers and add them to the group:
b. Click Add.
c. On the Service Group tab, enter a name for the service group.
d. In the Type drop-down list, select TCP, if not already selected.
e. Select the health monitor, if your configuration will use one.
f. On the Port tab, select a server from the Server drop-down list.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
g. Enter the service port in the Port field.
h. Click Add. The port appears in the list.
i. Repeat step f through step h for each server.
j. Click OK. The new service group appears in the service group table.
3. To configure HTTP template options, see “HTTP Options for SLB” on

page 105.
4. To configure a virtual server for SSL offload:

a. Select Virtual Server on the menu bar.
b. Click Add.
c. On the General tab, enter a name for the virtual server.
d. In the IP Address field, enter the VIP address.
e. On the Port tab, click Add.
f. In the Type drop-down list, select HTTPS.
g. In the Port field, enter the service port number.
h. In the Service Group drop-down list, select the service group.
i. If a custom HTTP template has been configured for this application,
select the template from the HTTP Template drop-down list.
j. In the Client-SSL Template drop-down list, select the template.
k. Click OK. The HTTPS port appears in the port list for the virtual
server.
l. Click OK again. The new virtual server appears in the virtual server
table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 79 Configure > Service > SLB > Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 80 Configure > Service > SLB > Service Group
FIGURE 81 Configure > Service > SLB > Virtual Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 82 Configure > Service > SLB > Virtual Server - Port tab
USING THE CLI

1. To configure a real server, use the following commands:
port port-num tcp
2. To configure a service group for the servers and add them to the group,
use the following commands:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. To configure HTTP template options, see “HTTP Options for SLB” on

page 105.
4. To configure a virtual server and HTTPS virtual port, use the following
commands:
port port-number https
template http template-name
template client-ssl template-name
Enter these commands at the configuration level for the virtual port to
bind the port to the service group and the application templates.
The following commands configure SSL offload. The feature is enabled by

the https option of the port command at the virtual server configuration
level of the CLI.

AX(config)#slb server HTTPS1 10.5.5.2
AX(config)#slb server HTTPS2 10.5.5.3
The following commands configure a service group for the HTTPS servers:
AX(config)#slb service-group HTTPS_servers tcp
AX(config-slb service group)#member HTTPS1:443
AX(config-slb service group)#member HTTPS2:443
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring the SSL Proxy Feature
The following commands configure the VIP to which clients will send
HTTPS traffic:
AX(config)#slb virtual-server v1 10.6.6.6
AX(config-slb virtual server)#port 443 https
AX(config-slb virtual server-slb virtua...)#service-group HTTPS_servers
AX(config-slb virtual server-slb virtua...)#template http HTTPS_1
AX(config-slb virtual server-slb virtua...)#template client-ssl sslcert-tmplt

To configure the AX device as an SSL proxy for a TCP service:
1. Configure client SSL. (See “Configuring Client SSL” on page 178.)
2. Configure the real servers for the TCP service.
3. Configure a service group for the servers and add them to the group.
4. Configure a virtual server and add a virtual port that has the service type
ssl-proxy. Bind the service-group to the virtual port and to the client-
SSL template.
USING THE GUI

1. To configure real servers:
d. On the General tab, enter a name for the server and enter its IP
address, in the Name and IP Address fields.
e. On the Port tab, enter the port number in the Port field.
f. In the Protocol drop-down list, select TCP, if not already selected.
g. Select the health monitor, if your configuration will use one.
h. Click Add. The port appears in the Port list.
i. Click OK. The server appears in the server table.
j. Repeat for each real server.
2. To configure a service group for the servers and add them to the group:
b. Click Add.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
c. On the Service Group tab, enter a name for the service group.
d. In the Type drop-down list, select TCP, if not already selected.
e. Select the health monitor, if your configuration will use one.
f. On the Port tab, select a server from the Server drop-down list.
g. Enter the service port in the Port field.
h. Click Add. The port appears in the list.
i. Repeat step f through step h for each server.
j. Click OK. The new service group appears in the service group table.
3. To configure a virtual server for SSL proxy:

a. Select Virtual Server on the menu bar.
b. Click Add.
c. On the General tab, enter a name for the virtual server.
d. In the IP Address field, enter the VIP address.
e. On the Port tab, click Add.
f. In the Type drop-down list, select SSL-Proxy.
g. In the Port field, enter the service port number.
h. In the Service Group drop-down list, select the service group.
i. In the Client-SSL Template drop-down list, select the template.
j. Click OK. The SSL proxy port appears in the port list for the virtual
server.
k. Click OK again. The new virtual server appears in the virtual server
table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 83 Configure > Service > SLB > Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 84 Configure > Service > SLB > Service Group
FIGURE 85 Configure > Service > SLB > Virtual Server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 86 Configure > Service > SLB > Virtual Server - Port tab
USING THE CLI

1. To configure a real server, use the following commands:
port port-num tcp
2. To configure a service group for the servers and add them to the group,
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. To configure a virtual server and port for the TCP service, use the fol-
lowing commands:
port port-number ssl-proxy

The following commands configure proxy SSL for POPS. The same com-
mands can be used to configure SSL proxy for other TCP services. In each
case, the feature is enabled by the ssl-proxy option of the port command at
the virtual server configuration level of the CLI.

AX(config)#slb server POP1 10.5.5.2
AX(config)#slb server POP2 10.5.5.3
The following commands configure a service group for the POP servers:
AX(config)#slb service-group POP_servers tcp
AX(config-slb service group)#member POP1:110
AX(config-slb service group)#member POP2:110
The following commands configure the VIP to which clients will send
POPS traffic:
AX(config-slb virtual server)#port 110 ssl-proxy
AX(config-slb virtual server-slb virtua...)#service-group SMTP_servers
AX(config-slb virtual server-slb virtua...)#template client-ssl sslcert-tmplt
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
STARTTLS for Secure SMTP
This chapter describes how to configure the AX device to secure Simple

Mail Transfer Protocol (SMTP) mail using STARTTLS.
Overview
AX Series devices support the STARTTLS feature. STARTTLS is an exten-
sion to SMTP that enables you to secure mail traffic to and from your leg-
acy SMTP servers. SMTP itself does not provide any security.
When the AX device is configured to perform STARTTLS, the AX acts as a

proxy between SMTP clients and servers. Mail traffic to and from clients is
encrypted by the AX, whereas traffic between the AX and the SMTP serv-
ers is clear (not encrypted).
Figure 87 shows an example of the STARTTLS feature.
FIGURE 87 STARTTLS
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Additional SMTP Security Options
In addition to providing encryption of mail traffic for clients, the AX
STARTTLS feature has additional security options:
• Require STARTTLS – By default, client use of STARTTLS is optional.
You can configure the AX to require STARTTLS. In this case, before
any mail transactions are allowed, the client must issue the STARTTLS
command to establish a secured session.
If the client does not issue the STARTTLS command, the AX sends the
following message to the client: "530 - Must issue a STARTTLS com-
mand first”
• Disable SMTP commands – By default, the VRFY, EXPN, and TURN
commands are allowed. You can disable support of any of these com-
mands. In this case, if the client tries to issue a disabled SMTP com-
mand, the AX sends the following message to the client: “502 -
Command not implemented”
Domain Switching
By default, SMTP traffic from all client domains is sent to the same service
group. You can configure multiple service groups and send traffic to the
groups based on the client domain. For example, you can send SMTP traffic
from clients in domain "CorpA" to a different service group than SMTP
traffic from clients in domain "CorpB".
FIGURE 88 STARTTLS Domain Switching
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring STARTTLS
To configure STARTTLS:
1. Import a certificate and its key to use for TLS sessions with clients.
2. Configure a client SSL template and add the certificate and its key to it.
3. Configure a real server for each SMTP server and add the SMTP port to
the server.
4. Configure a service group for the SMTP servers and add them to the
group.
5. Configure an SMTP template. Within the template:

a. Specify the email server domain. The default is “mail-server-
domain”.
b. Optionally, modify the service ready message. The default message
text is "ESMTP mail service ready". The complete message sent to
the client is constructed as follows:
200 - smtp-domain service-ready-string
c. Optionally, disable one or more of the following SMTP commands:
VRFY, EXPN, or TURN. If a client sends an SMTP command that
is disabled on the AX, the AX sends the following message to the
client: “502 - Command not implemented”
d. Optionally, change STARTTLS from being optional to being
required. If you leave the setting "optional", mail clients will be able
to send and receive unencrypted mail.
e. Optionally, load balance SMTP traffic among multiple service
groups based on client domains.
6. Configure a virtual server and port for the SMTP address to which cli-
ents will send SMTP traffic, and add the SMTP service group and
SMTP template to the port.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
In the GUI, most of the configuration steps (step 1 through step 4 above) for
STARTTLS are the same as those for SSL proxy support. (See “Configuring
the SSL Proxy Feature” on page 188.)
To configure an SMTP template for STARTTLS (step 5 above):

1. Select Configure > Service > Template.
2. Select Application > SMTP from the menu bar.
3. Click Add. The SMTP tab appears.
4. On the SMTP tab, enter general settings for the template:

a. In the Name field, enter a name for the template.
b. To force clients to use STARTTLS, select Enforced next to START-
TLS.
c. To disable STARTTLS commands sent by the client, select the com-
mands to disable.
d. In the Server Domain field, enter the domain for which the AX will
provide STARTTLS service.
e. In the Service Ready Message field, enter the message that the AX
will send to client to inform them that the STARTTLS service is
ready.
5. To configure domain switching settings:

a. On the Client Domain Switching tab, enter the client SMTP domain
in the Client Domain field.
b. In the Service Group drop-down list, select the service group to use
for the client domain.
c. Click Add.
d. Repeat for each client domain.
6. Click OK. The new template appears in the SMTP template table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure a virtual server for STARTTLS (step 6 above):
1. Select Configure > Service > Server.
3. Click Add.
4. On the General tab, enter general settings for the virtual server:
a. Enter a name for the virtual server.
b. In the IP address field, enter the VIP address.
5. Configure port settings for the virtual server:

a. On the Port tab, click Add. The Virtual Server Port tab appears.
b. In the Type drop-down list, select SMTP.
c. In the Port field, enter the service port number.
d. In the Service Group drop-down list, select the service group.
e. In the Client-SSL Template drop-down list, select the client SSL
template.
f. In the SMTP Template drop-down list, select the SMTP template.
g. Click OK. The port appears in the port list for the virtual server.
h. Click OK again. The new virtual server appears in the virtual server
table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 89 Config > Service > Template > Application > SMTP
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 90 Config > Service > SLB > Virtual Server - Port tab
USING THE CLI

1. To import a certificate and its key, use the following commands at the
global Config level of the CLI:
slb ssl-load certificate file-name url
slb ssl-load key file-name url
The url specifies the file transfer protocol, username (if required), direc-
tory path, and filename.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
2. To configure a client SSL template, use the following commands:

slb template client-ssl template-name
cert cert-name
Enter this command at the configuration level for the client SSL tem-
plate.
key key-name [passphrase passphrase-string]
3. To configure a real server for an SMTP server, use the following com-
mands:
port port-num tcp
4. To configure a service group for the SMTP servers and add them to the
group, use the following commands:
5. To configure an SMTP template, use the following commands:

slb template smtp template-name
Enter this command at the global Config level. Use the following com-
mands at the configuration level for the SMTP template to set SMTP
options:
server-domain name
service-ready-message string
starttls {disable | optional | enforced}
domain-switching match string service-group
group-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The disable option of the starttls command disables STARTTLS sup-
port on the VIP that uses the SMTP template.
The domain-switching command is required only if you have multiple
service groups and you want to direct SMTP clients to specific service
groups based on the client's domain.
6. To configure a virtual server and port for the SMTP address to which
clients will send SMTP traffic, add the SMTP service group, and add the
SMTP and client SSL templates to the port, use the following com-
mands:
port port-num smtp
template smtp template-name
Displaying STARTTLS Statistics
To display STARTTLS statistics, use the following command at the Privi-

leged EXEC level or any configuration level of the CLI:
show slb smtp [detail]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands implement the STARTTLS configuration shown

To begin, the following commands import an SSL certificate and key:

AX(config)#slb ssl-load certificate starttls.crt ftp:
Password []?*********
File name [/]?starttls.crt
AX(config)#slb ssl-load key tlscertkey.pem ftp:
Password []?*********
File name [/]?tlscertkey.pem
The following commands configure a client SSL template to use the certifi-
cate and key:
AX(config)#slb template client-ssl mailcert-tmplt
AX(config-client SSL template)#cert starttls.crt
AX(config-client SSL template)#key tlscertkey.pem
AX(config-client SSL template)#exit
The following commands configure the SMTP real servers:

AX(config)#slb server SMTP1 10.1.1.2
AX(config)#slb server SMTP2 10.1.1.3
The following commands configure a service group for the SMTP servers:
AX(config)#slb service-group SMTP_servers tcp
AX(config-slb service group)#member SMTP1:25
AX(config-slb service group)#member SMTP2:25
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the STMP template. In this example,
additional security is added by enforcing STARTTLS and by disabling the
SMTP commands VRFY, EXPN, and TURN.
AX(config)#slb template smtp starttls-tmplt
AX(config-slb template)#server-domain “mycorp.com”
AX(config-slb template)#service-ready-message “MyCorp ESMTP mail service is
ready”
AX(config-slb template)#starttls enforced
AX(config-slb template)#command-disable vrfy expn turn
The following commands configure the VIP to which mail clients will send
SMTP traffic:
AX(config-slb virtual server)#port 25 smtp
AX(config-slb virtual server-slb virtua...)#service-group SMTP_servers
AX(config-slb virtual server-slb virtua...)#template client-ssl mailcert-tmplt
AX(config-slb virtual server-slb virtua...)#template smtp starttls-tmplt
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Streaming-Media Load Balancing
This chapter describes streaming-media load balancing and how to config-

ure it.
Overview
AX Series devices support content-aware load balancing of the following
widely used streaming-media types:
• Real Time Streaming Protocol (RTSP)
• Microsoft Media Server (MMS)
Note: The AX Series also supports load balancing of Session Initiation Protocol
(SIP) sessions. For information, see “SIP Load Balancing” on page 163.
Figure 91 shows an example of a streaming-media load balancing solution.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
FIGURE 91 Streaming-Media Load Balancing
In this example, a server farm provides streaming content in both RTSP and
MMS format. All the servers are allowed to serve HTTP and HTTPS
requests. Two of the servers (stream-rs2 and stream-rs3) are configured to
serve RTSP and MMS requests.
Service Groups
This example uses the following service groups:
• all80-grp – The servers in this service group provide HTTP and HTTPS
service. In this example, all the servers are members of this service
group.
• rtsp554-grp – The servers in this service group provide RTSP content.
• mms1755-grp – The servers in this service group provide MMS content.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Streaming-Media SLB
Note: Using separate service groups makes it easier to adapt the configuration
when the server farm grows. For example, if RTSP and MMS content is
separated onto different servers, the membership of the RTSP group can
easily be edited to include only the RTSP servers, and so on.
Templates
By default, the default TCP template is applied to RTSP and MMS traffic.
(For information, see “TCP Template Parameters” on page 624.)
Health Monitors
This example uses the default Layer 3 health check (ping) and the default
Layer 4 TCP health check.

To configure streaming-media load balancing:
1. Configure the real servers. Make sure to add the RTSP or MMS ports.
2. Configure service groups. If both supported streaming-media types are

used (RTSP and MMS), make sure to configure a separate service group
for each type.
3. Configure the virtual server by adding virtual service ports for the
streaming-media services.
Most of the configuration procedures are the same as the configuration pro-
cedures for other types of SLB.
USING THE GUI
To configure a streaming-media template:

2. Select Application > RTSP on the menu bar.
3. Click Add.
4. Enter a name for the template.
5. Configure other options, if applicable to your configuration.
6. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
When configuring the virtual server, select RTSP or MMS as the service
port type.
USING THE CLI

Enter this command at the global Config level of the CLI.
The command creates the server and changes the CLI to the configura-
tion level for it.
port port-num tcp
Available at the configuration level for the server, the port command
adds a TCP port and changes the CLI to the configuration level for the
port. Enter a separate port command for each port number to be load
balanced.
2. To configure the service groups, use the following commands:

The member command adds a server to the service group. The server-
name is the name you used when you configured the real server. The
portnum is the protocol port number configured on the real server.

This command creates the virtual server and changes the CLI to the con-
port port-number http
port port-number https
port port-number rtsp
port port-number mms
The port commands add virtual ports for each service to be load bal-
anced. For each port, the command changes the CLI to the configuration
level for the port, where the following command is used:
The service-group command binds the virtual port to a service group.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009

AX(config)#slb server stream-rs1 192.168.66.21
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
AX(config)#slb service-group all80-grp tcp
AX(config-slb service group)#member stream-rs1:80
AX(config)#slb service-group rtsp554-grp tcp
AX(config)#slb service-group mms1755-grp tcp

AX(config)#slb virtual-server streaming-vip 192.168.69.4
AX(config-slb virtual server-slb virtua...)#service-group all80-grp
AX(config-slb virtual server)#port 443 https
AX(config-slb virtual server-slb virtua...)#service-group all80-grp
AX(config-slb virtual server)#port 554 rtsp
AX(config-slb virtual server-slb virtua...)#service-group rtsp554-grp
AX(config-slb virtual server)#port 1755 mms
AX(config-slb virtual server-slb virtua...)#service-group mms1755-grp
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Layer 4 TCP/UDP Load Balancing
This chapter describes Layer 4 load balancing of TCP and UDP traffic and
how to configure it.
Note: The Layer 4 load balancing described in this chapter requires you to spec-
ify the protocol port numbers to be load balanced. To load balance traffic
based solely on transport protocol (TCP, UDP, or other), see “IP Protocol
Load Balancing” on page 221.
Overview
In addition to load balancing for well-known and widely used types of ser-
vices such as HTTP, HTTPS, and FTP, AX devices also support Layer 4
load balancing for custom applications. If a service you need to load balance
is not one of the well-known service types recognized by the AX device,
you still can configure Layer 4 TCP or UDP load balancing for the service.
Figure 92 shows an example of a Layer 4 load balancing implementation.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
FIGURE 92 Layer 4 SLB
Layer 4 load balancing balances traffic based on the transport protocol (TCP
or UDP) and the protocol port number. The payload of the UDP or TCP
packets is not examined.
In this example, a custom application is running on a server farm consisting

of three real servers. Clients navigate to the VIP to use the custom applica-
tion.
Note: To configure deeper packet inspection for custom applications, you can
use aFleX policies. For example, you can configure an aFleX policy to
examine the byte value at a certain position within each client request
packet and select a server based on the value of the byte. For information
about aFleX policies, see the AX Series aFleX Reference.
SERVICE GROUPS
This example uses a single service group that contains all the real servers.
The service group uses the default load balancing method (round robin).
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
VIRTUAL SERVER
The custom application on the real servers is accessed at TCP port 1020 by
clients through virtual IP address 192.168.55.55.
TEMPLATES
The AX device has default TCP and UDP templates. You can use the
default template or configure another TCP or UDP template and use that
one instead. If your Layer 4 load balancing configuration is for a TCP appli-
cation and you do not bind a TCP template to the virtual port, the default
TCP template is used. For a UDP application, the default UDP template is
used unless you bind another UDP template to the virtual port.
One of the parameters you can configure in TCP and UDP templates is the
idle time. Depending on the requirements of your application, you can
reduce or increase the amount of time the AX device allows a session to
remain idle.
For UDP transaction-based applications, another parameter you can adjust

is how quickly connections are terminated after a server reply is received.
For example, if there are licensing costs associated with active sessions, you
can minimize unnecessary costs by quickly terminating idle sessions, and
immediately terminating connections that are no longer needed.
For more information about the parameters controlled by TCP and UDP
templates, see the following sections:
• “TCP Template Parameters” on page 624
• “UDP Template Parameters” on page 626
Optionally, you also can configure a source-IP persistence template and

bind it to the virtual port. The example in this chapter uses a source-IP per-
sistence template that is configured to send all traffic from a given client IP
address to the same real server. Without this custom template, different
requests from a given client can be sent to different servers, based simply on
the load balancing method.
See “Source-IP Persistence Template Parameters” on page 617.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Layer 4 Load Balancing
HEALTH MONITORS
This example uses the default Layer 3 and Layer 4 health monitors. The
Layer 3 monitor (Ping) and the applicable Layer 4 monitor (TCP or UDP)
are enabled by default when you configure the real server and real service
ports.
Note: You can create an external health monitor using a script and import the
monitor onto the AX device. For information, see “Health Monitoring” on
page 297.

To configure Layer 4 load balancing:
1. Configure the real servers. Add the custom application’s TCP or UDP
port number, with the applicable service type (TCP or UDP).
2. Configure a service group. Add the real servers, service port, and any
custom templates to the group.
3. If applicable, configure a custom TCP or UDP template.
4. If applicable, configure a source-IP persistence template.
5. Configure the virtual server. Bind the virtual service port on the virtual
server to the service group and custom templates, if configured.
USING THE GUI

1. To configure the real servers:
c. Click Add.
d. On the General tab, configure general settings for the server.
e. On the Port tab, enter the protocol port number of the application in
the port field.
f. In the Type drop-down list, select the transport protocol for the
application, TCP or UDP.
g. Configure other port settings if needed, then click Add. The applica-
tion port appears in the Port list.
h. Click OK. The real server appears in the real server table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
2. To configure the service group:
a. Select Config > Service > SLB, if not already selected.
b. Select Service Group on the menu bar.
c. Click Add.
d. On the Service Group tab, enter a name for the service group.
e. In the Type drop-down list, select the transport protocol for the
f. On the Server tab, select a server from the Server drop-down list.
g. Enter the protocol port number in the Port field.
h. Click Add.
i. Repeat step f through step h for each server and port.
j. Click OK. The service group appears in the Service Group table.
3. To configure a custom TCP or UDP template:

b. Select L4 > TCP or L4 > UDP on the menu bar.
c. Click Add.
e. Edit template settings as needed for your application. (See “TCP
Template Parameters” on page 624 or “UDP Template Parameters”
on page 626.)
f. Click OK.
4. To configure a source-IP persistence template:

b. Select Persistent > Source IP Persistent on the menu bar.
c. Click Add.
e. Edit template settings as needed for your application. (See “Source-
IP Persistence Template Parameters” on page 617.)
f. Click OK.
5. To configure the virtual server:

a. Select Config > Service > SLB, if not already selected.
c. Click Add.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
d. Enter a name for the virtual server.
e. In the IP Address field, enter the virtual IP address to which clients
will send requests.
f. Select or enter other general settings as needed.
g. On the Port tab, click Add. The Virtual Server Port tab appears.
h. In the Type drop-down list, select the transport protocol for the
i. Enter the application port number in the Port field.
j. If you configured any custom templates, select them from the drop-
down lists for each template type.
k. Enter or select other values as needed.
l. Click OK. The port appears in the port section.
m. Click OK again. The virtual server appears in the virtual server list.
USING THE CLI

This command changes the CLI to the configuration level for the real
server, where you can use the following command to add the TCP or
UDP port to the server:
port port-num {tcp | udp}
The port-num specifies the protocol port number. In this example, spec-
ify “1020”.
This command adds the port and changes the CLI to the configuration
level for the port, where additional commands are available. (For infor-
mation, see the AX Series CLI Reference.)
2. To configure the service group, use the following commands:

slb service-group group-name {tcp | udp}
This command changes the CLI to the configuration level for the service
group, where you can use the following command to add the real servers
and service ports to the group:
The portnum is the protocol port number of the service to be load bal-
anced. In this example, specify “tcp-2:1020”. Repeat the command for
“tcp-3:1020” and “tcp-4:1020”.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. To configure a custom TCP or UDP template, use the following com-
mands at the global configuration level of the CLI:
slb template tcp template-name
slb template udp template-name
These commands create the template and change the CLI to the configu-
ration level for the template, where additional commands are available.
(See “TCP Template Parameters” on page 624 or “UDP Template
Parameters” on page 626. Also see the “Config Commands: SLB Tem-
plates” chapter in the AX Series CLI Reference.)
4. To configure a source-IP persistence template, use the following com-

mand at the global configuration level of the CLI:
slb template persist source-ip template-name

server, where you can use the following command to add the virtual port
to the server:
port port-number {tcp | udp}
For this example, specify tcp and “1020” as the port-num.
The port command changes the CLI to the configuration level for the
virtual port, where you can use the following command to bind the vir-
tual port to the service group:
The group-name is the name of the service group configured in step 2.
If you configured a custom template, use the following command to
bind the template to the service group:
template template-type template-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI EXAMPLE

AX(config)#slb server tcp-2 10.10.10.2

AX(config)#slb service-group tcp-sg tcp
AX(config-slb service group)#member tcp-2:1020
The following commands configure a source-IP persistence template:

AX(config)#slb template persist source-ip app1020persist
AX(config-source ip persistence template)#match-type server
AX(config-source ip persistence template)#exit

AX(config)#slb virtual-server web-vip 192.168.55.55
AX(config-slb virtual server-slb virtua...)#service-group tcp-sg
AX(config-slb virtual server-slb virtua...)#template persist source-ip
app1020persist
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
IP Protocol Load Balancing
This chapter describes load balancing of traffic based solely on transport

protocol (TCP, UDP, or other), without the need to specify the protocol port
numbers to be load balanced.
Overview
IP protocol load balancing enables you to easily load balance traffic based
solely on whether the traffic is TCP, UDP, or other (not UDP or TCP), with-
out the need to specify the protocol port numbers to be load balanced.
You can combine IP protocol load balancing with other load balancing con-
figurations. For example, you can use IP protocol load balancing along with
HTTP load balancing. In this case, HTTP traffic to the VIP HTTP port num-
ber is load balanced separately from traffic to other port numbers.
Figure 93 shows an example of an IP protocol load balancing deployment.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
FIGURE 93 IP Protocol Load Balancing
This example uses separate service groups for each of the following types of
traffic:
• HTTP traffic addressed to TCP port 80 is sent to service group http-grp.
• All TCP traffic addressed to any TCP port except port 80 is sent to ser-
vice group tcp-grp.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
• All UDP traffic, addressed to any UDP port, is sent to service group
udp-grp.
• All other traffic (all non TCP/UDP traffic) is sent to service group oth-
ers-grp.
Although this example shows separate service groups for each type of traf-
fic, you can use the same service group for multiple traffic types.
In IP protocol load-balancing configurations, port 0 (zero) is used as a wild-

card port and matches on any port number. In configurations where some
protocol port numbers are explicitly specified, SLB for those ports takes
precedence over SLB for the wildcard port (0). In the example above, the
service group configured for TCP port 80 is always used for client requests
addressed to that port, instead of a service group configured for the wildcard
port.
Health checking does not apply to the wildcard port. When you configure IP
protocol load balancing, make sure to disable health checking of port 0. If
you leave health checking enabled, the port will be marked down and the
client’s request therefore will not be serviced.
SLB NAT
For client request traffic to which IP protocol load balancing applies, the
AX device translates only the destination IP address, not the protocol port
number. The AX device translates the destination IP address in the request
from the VIP address to a real server’s IP address. The AX device then
sends the request to the same protocol port number as the one requested by
the client. (Likewise, the AX device does not translate the port number to
“0”.)
In configurations where some protocol port numbers are explicitly speci-

fied, auto port translation is still supported for the explicitly specified port
numbers. In the example above, SLB NAT can translate TCP port 80 into
another TCP port number if required by the configuration.
Template Support
For TCP or UDP, a TCP or UDP template is applied, as in other types of

SLB. Optionally, you also can use a source-IP persistence template.
For non-TCP/UDP traffic, the TCP template is used.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring IP Protocol Load Balancing
Direct Server Return
For either of the following types of applications, IP protocol load balancing

is supported only when Direct Server Return (DSR) is enabled on the virtual
port.
• Application Layer Gateway (ALG) applications, such as FTP. For an
ALG application, either enable DSR or configure SLB explicitly for the
ALG service port.
• Any application that requires inspection of any part of the client request
packet other than the destination IP address
Note: In the CLI, DSR is enabled by the no-dest-nat command.
Comparison of IP Protocol Load Balancing to Layer 4 TCP/UDP

Load Balancing
IP protocol load balancing is similar to Layer 4 load balancing, except IP

protocol load balancing enables you to load balance non-TCP/UDP traffic.
Layer 4 load balancing applies only to TCP or UDP traffic. In addition, IP
protocol load balancing uses a wildcard port number that matches on any
TCP port, UDP port, or any non-TCP/UDP port, depending on the configu-
ration. Layer 4 load balancing requires you to explicitly specify the protocol
port numbers to load balance.

To configure IP protocol load balancing:
1. Configure the real servers. For each real server that will service requests
to IP protocol load-balanced traffic, add service port 0 (the wildcard
port).
Disable health checking of port 0. Health checking does not apply to the
wildcard port.
2. Configure the service group(s). To add members (real servers) for traffic
to which IP protocol load balancing will apply, specify 0 as the protocol
port for the member.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. Configure the virtual server. Bind virtual port 0 to the service group(s)
that have members for port 0. Specify one of the following as the service
type:
• TCP
• UDP
• Others
Note: For load balancing of non-TCP/UDP traffic, you can specify TCP or UDP
as the transport protocol, in the configurations of the real server ports and
service groups. If the port number is 0 and the service type on the virtual
port is “others”, the AX device will load balance the traffic as non-TCP/
UDP traffic.
USING THE GUI

Configuration of IP protocol SLB is similar to configuration of TCP/UDP
SLB, with the following differences.
1. On the real server Port tab (Config > Service > SLB > Server), enter 0
in the Port field.
2. On the Service Group tab, enter 0 as the port number on the Service
Group tab.
3. On the Virtual Server Port tab (Config > Service > SLB > Virtual
Server), select TCP, UDP, or Others in the Type drop-down list.
USING THE CLI
The following commands configure the real servers shown in Figure 93 on

page 222.
For simplicity, the example assumes that only the default TCP health check
is used for port 80. Health checking does not apply to the wildcard port
number and is therefore disabled. Health checking of other, explicitly speci-
fied port numbers is still supported as in previous releases.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
AX(config-real server)#no health-check
The following commands configure the service groups.

AX(config)#slb service-group http-grp tcp
AX(config)#slb service-group tcp-grp tcp
AX(config)#slb service-group udp-grp udp
AX(config)#slb service-group others-grp tcp
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the virtual server.
AX(config-slb virtual server-slb virtua...)#service-group http-grp
AX(config-slb virtual server-slb virtua...)#service-group tcp-grp
AX(config-slb virtual server)#port 0 udp
AX(config-slb virtual server-slb virtua...)#service-group udp-grp
AX(config-slb virtual server)#port 0 others
AX(config-slb virtual server-slb virtua...)#service-group tcp-others
To display configuration information and statistics, you can use the same
show commands used for other types of SLB:
show slb virtual
show slb server
show slb service-group
show session
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring a Wildcard VIP
Wildcard VIPs
You can create SLB configurations that use wildcard VIPs and wildcard vir-
tual ports. A wildcard VIP matches on any destination IP address. Likewise,
a wildcard virtual port matches on any port number.
Wildcard VIPs enable you to configure a feature that applies to multiple

VIPs, without the need to re-configure the feature separately for each VIP.
To specify the subset of VIP addresses and ports for which the feature
applies, you can use an ACL. If applicable, the ACL also can specify the
subset of clients allowed to access the VIPs.
You can use wildcard VIPs for all types of load balancing:
• SLB
• IP load balancing
• Transparent Cache Switching (TCS)
• Link Load Balancing (LLB)
• Firewall Load Balancing (FWLB)
Note: Use of wildcard VIPs and interface-based SYN cookies is not supported.

The procedure for configuring a wildcard VIP is the same as the procedure
for configuring a standard VIP, except you have the option to bind an ACL
to the wildcard VIP.
Wildcard VIPs have IP address 0.0.0.0. Likewise, wildcard protocol ports

have port number 0.
You can configure multiple wildcard VIPs and wildcard ports. The AX
device allows multiple VIPs to have IP address 0.0.0.0. Likewise, multiple
ports that have port number 0 are allowed.
In the current release, wildcard ports must have service type TCP or HTTP.
Other service types are not supported on wildcard ports in the current
release.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Promiscuous VIP support must be enabled on the interface connected to cli-
ents who will access wildcard VIPs. By default, promiscuous VIP support is
disabled.
Note: The ACL acts as a “catch-all”, and treats any IP address permitted by the
ACL, and received on the promiscuous VIP interface, as a wildcard VIP.
A10 Networks recommends that you use the most restrictive ACL possi-
ble, to permit only the IP addresses that should be treated as VIPs and
deny all other IP addresses.
Default Wildcard VIP

The AX device can have multiple wildcard VIPs, bound to different ACLs.
However, the AX device can have only one wildcard VIP that is not bound
to any ACL. This is the default wildcard VIP. The default wildcard VIP is
used for traffic that does not match any of the ACLs bound to other wild-
card VIPs.
If you do not configure a default wildcard VIP, traffic that does not match
any of the ACLs bound to the other wildcard VIPs is forwarded at Layer 2/
3, if applicable.
Pass-Through Layer 2/3 Forwarding Support for Layer 4 Wild-

card VIP Traffic
AX Release 2.0.2 and later supports forwarding of wildcard VIP traffic that
is not bound to a service group. The AX device creates a session for the traf-
fic and forwards it at Layer 2/3. This feature is useful in mixed wildcard vir-
tual server environments where Layer 4-7 features apply to certain VIPs and
Layer 2/3 forwarding applies to other traffic.
In AX releases prior to 2.0.2, Layer 4 traffic for a wildcard VIP that is not
bound to a service group is dropped.
USING THE GUI
To configure a wildcard VIP:

3. Click Add. The General tab appears.
4. On the General tab, enter a name for the virtual server in the Name field.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
5. Select the Wildcard checkbox next to the Name field. Selecting this
checkbox causes the Access List drop-down list to appear in place of the
IP Address field.
6. Select the ACL from the Access List drop-down list.
7. Configure other VIP settings, then click OK.
To enable promiscuous VIP support:

1. Select Network > Interface.
2. Click on the interface name to display the configuration tabs for the
interface.
3. Click on the VIP tab to display the configuration fields.
4. Select Enabled next to Allow Promiscuous VIP.
5. Click OK.
FIGURE 94 Config > Service > SLB > Virtual Server - wildcard VIP
configuration
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 95 Config > Service > SLB > Virtual Server - promiscuous VIP
support
USING THE CLI
To configure a wildcard VIP, use the following command at the global con-
figuration level of the CLI:
[no] slb virtual-server 0.0.0.0 ipaddr [acl acl-id]
The ipaddr is used as the name of the virtual server and can be an IPv4
address or an IPv6 address.
If you specify an ACL, the ACL is used to control the clients allowed to
access the VIPs and the VIP addresses managed by the wildcard VIP. The
source address in the ACL filters the clients. The destination address in the
ACL filters the VIPs.
To enable promiscuous VIP support, use the following command at the con-
figuration level for each interface connected to clients:
[no] ip allow-promiscuous-vip
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
See the following:

• “Outbound Link Load Balancing” on page 235
• “Transparent Cache Switching” on page 241
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Outbound Link Load Balancing
The AX Series supports outbound Link Load Balancing (LLB). Outbound

LLB enables you to balance 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.
Figure 96 shows an example of outbound LLB.
FIGURE 96 Link Load Balancing
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
In this example, the AX device is configured to balance client traffic across

a set of two WAN links, through next-hop routers 192.168.10.1 and
192.168.20.1.
When the AX device receives a request from a client, the AX device uses
SLB load balancing to select one of the WAN links. The AX device then
uses source IP NAT to translate the client’s private IP address into a public
IP address, then sends the client’s request to the next-hop router for the
selected WAN link.
When the AX device receives the server’s reply to the client’s request, the
AX device translates the destination IP address from the NAT address back
into the client’s private IP address, then forwards the reply to the client.
Load Balancing Methods

You can use either of the following load balancing methods to load balance
traffic across the WAN links:
• Round-robin – Selects the links in simple rotation. This results in each
link being selected an equal number of times.
• Least-connections – Selects the link that has the least current client con-
nections on it. The connection count is based on client connections initi-
ated on the link by the AX device.
The default is round-robin.
Network Address Translation Requirements

In an outbound LLB topology, the next-hop routers for the WAN links must
be able to send the server reply traffic back to the AX device. To ensure that
the server reply traffic passes back through the AX device, use an IP source
NAT pool for each WAN link.
The pools do not need to contain more than a few addresses. The AX device
internally uses a separate protocol port number for each client session on a
pool address.
SLB destination NAT, which is enabled by default, must be disabled. In a

standard SLB configuration, destination NAT is used to translate the server
address (destination IP address) requested by clients from the VIP address
into the server’s real address. However, this NAT operation is not applicable
to outbound LLB.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Link Load Balancing

To configure LLB:
1. Configure an IP source NAT pool for each link to be load balanced. The
address range in a pool must be in the same subnet as the next-hop
router’s interface with the AX device.
Configure a pool group and add the pools to it.
2. Configure the AX interfaces connected to the clients. Enable promiscu-

ous VIP support on the interfaces.
3. Configure the AX interfaces connected to the next-hop routers for the

links to be load balanced. (Do not enable promiscuous VIP on these
interfaces.)
4. Configure a real server for each link to be load balanced. Add wildcard
ports (TCP 0, UDP 0, or both) to the server.
Note: You can use Layer 3 health checking (ICMP ping) to check the health of
the router’s IP interface. However, the configuration requires health
checking to be disabled on the wildcard ports added for a router. The
router will not respond to these health checks. If you leave health check-
ing enabled on the wildcard ports, the AX device will mark the ports
down and LLB will not work.
5. Configure a service group for the links (real servers). If the real server
configurations for the links have both TCP and UDP ports, configure a
service group for TCP and another service group for UDP.
6. Configure a virtual server with virtual IP address 0.0.0.0 (the wildcard

VIP address). Using the wildcard VIP address enables the configuration
to work for any destination IP address requested by clients.
Add the wildcard TCP port (TCP 0) and bind it to the TCP service
group. Likewise, add the wildcard UDP port and bind it to the the UDP
service group.
Bind the ports to service group(s). On each port, bind the port to the IP
Source NAT pool group and disable destination NAT.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI Example
The commands in this example implement the LLB configuration shown in

Figure 96 on page 235.
The following commands configure the IP source NAT pools and pool
group:
AX(config)#ip nat pool nat10 192.168.10.3 192.168.10.4 netmask /24
AX(config)#ip nat pool nat20 192.168.20.3 192.168.20.4 netmask /24
AX(config)#ip nat pool-group outbound-nat-group nat10 nat20
The following commands enable promiscuous VIP support on the AX inter-

faces connected to clients.
Note: For simplicity, this example uses a single Ethernet port for each interface
to the clients and the next-hop routers. You also can use trunk interfaces,
virtual Ethernet (VE) interfaces, or both.
AX(config-if: ethernet3)#ip address 10.10.10.1 255.255.255.0
AX(config-if: ethernet3)#ip allow-promiscuous-vip
AX(config-if: ethernet3)#exit
AX(config-if: ethernet4)#ip allow-promiscuous-vip
The following commands configure the AX interfaces to the next-hop rout-

ers for the load-balanced links:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure a real server for each link to be load
balanced:
AX(config)#slb server link-101 192.168.10.1
AX(config-real server-node port)#no health-check
AX(config)#slb server link-201 192.168.20.1
The following commands configure service groups for the links:

AX(config)#slb service-group outbound-tcp-links tcp
AX(config-slb svc group)#member link-101:0
AX(config-slb svc group)#exit
AX(config)#slb service-group outbound-udp-links udp

AX(config)#slb virtual-server wildcard-vip 0.0.0.0
AX(config-slb vserver)#port 0 tcp
AX(config-slb vserver-vport)#service-group outbound-tcp-links
AX(config-slb vserver-vport)#source-nat pool outbound-nat-group
AX(config-slb vserver-vport)#no-dest-nat
AX(config-slb vserver-vport)#exit
AX(config-slb vserver)#port 0 udp
AX(config-slb vserver-vport)#service-group outbound-udp-links
AX(config-slb vserver-vport)#source-nat pool outbound-nat-group
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Transparent Cache Switching
The AX Series supports Transparent Cache Switching (TCS). TCS enables

you to improve server response times by redirecting client requests for con-
tent to cache servers containing the content.
FIGURE 97 Transparent Cache Switching
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
In this example, a client sends a request for content that is hosted by the
content server. The AX device redirects the client’s request to the cache
server. If the cache server has the requested content, the cache server sends
the content to the AX device, which sends the content to the client.
If the content is cacheable, but the cache server does not have the requested
content or the content is stale, the cache server requests the content from the
content server, caches the content, then sends the content to the AX device,
which sends the content to the client.
Granularity of TCS
You can configure Layer 4 TCS or Layer 7 TCS.

• Layer 4 TCS – Sends all TCP or UDP traffic addressed to the content
server to the cache server instead
• Layer 7 TCS – You can configure Layer 7 TCS with either of the fol-
lowing levels of granularity:
• Sends all HTTP requests to the cache server and sends all other
requests to the content server
• Sends HTTP requests for specific URLs to the cache server, and
sends other requests to the content server
Optimizing When Using Multiple Cache Servers
If your network uses multiple cache servers, you can configure destination-
IP persistence, to always select the same cache server for content from a
given destination IP address. This technique reduces cache misses, by
ensuring that requests for a given site IP address always go to the same
cache server.
For even greater control, you can configure the AX device to select from
among multiple cache service groups based on the requested URL. When
combined with destination-IP persistence, this method allows you to control
initial selection of the cache service group, after which the AX device
always sends requests for the same content to the same cache server within
the cache service group.
Application Templates
TCS does not require configuration of any application templates. However,
you can use the following types of application templates for advanced fea-
tures, such as URL-based Layer 7 TCS:
• HTTP template – If you want to selectively redirect client requests
based on URL strings, you can use an HTTP template containing URL
switching rules. When a client request matches the URL string in a URL
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
switching rule, the AX device selects the service group specified in the
URL switching rule, instead of the service group bound to the virtual
port.
For example, you can configure a URL switching rule that matches on
any URL that contains “.mycorp/”. In this case, requests for any URL
that contains “.mycorp/” are sent to the service group that contains the
cache server. Requests for other URLs are sent to the gateway router
instead.
In a Layer 7 TCS configuration that uses URL switching, a separate real
server is required for the gateway router, and the real server is required
to be placed in its own service group. The gateway router’s service
group is used as the default service group for the virtual port. Client
requests to a URL that does not match a URL switching rule are sent to
the gateway router’s service group instead of the cache server’s service
group.
• Destination-IP persistence template – In deployments that use multiple
cache servers, you can use a destination-IP persistence template to
ensure that the same cache server is used for every request for content
on a given content server. The AX device uses standard SLB to select a
cache server for the first request to a real server IP address, and assigns a
hash value to the server. All subsequent requests for the same real server
are sent to the same cache server.
By always using the same cache server for content from a given server, a
destination-IP persistence template can reduce duplication of content on
multiple cache servers, and can also reduce cache misses.
• RAM caching template – To also cache some content on the AX device
itself, you can use a RAM caching template. In this case, the AX device
directly serves content that is cached on the AX device, and only sends
requests to the cache server for content that is not cached on the AX
device.
• Connection reuse template – You can use a connection reuse template to
reuse TCP connections. When a client’s session ends, the TCP connec-
tion is not terminated. Instead, the connection is reused for a new client
session.
Support for Spoofing Caches
Some cache servers can use the client’s IP address instead of the cache
server’s IP address as the source address when obtaining content requested
by the client. A cache server operating in this mode is a spoofing cache
server. Configuration for a spoofing cache server includes a couple of addi-
tional steps. (See “Enabling Support for Cache Spoofing” on page 254.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Layer 4 TCS

To configure Layer 4 TCS:
1. Configure the interfaces connected to the clients, the content servers,
and the cache server. Enable promiscuous VIP on the AX interface(s)
connected to the clients.
2. Configure an extended ACL that uses the permit action and that matches
on client addresses as the source address, and on the content server
address as the destination address.
3. Configure a real server for the cache server. Add the TCP or UDP port;
for example, TCP port 80.
If the cache server will spoof client IP addresses when requesting con-
tent from content servers, enable cache spoofing support.
4. Configure a service group for the cache server and add the cache server
to it.

VIP address) and bind it to the ACL.
Add virtual port 80 and bind it to the service group containing the cache
server. Disable destination NAT on the virtual port.
6. If the cache server will spoof client IP addresses when requesting con-
tent from content servers, enable cache spoofing support on the AX
interface connected to the cache server, and on the real server (cache
server).
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI Example
The commands in this section implement the TCS configuration shown in

Figure 98.
FIGURE 98 Layer 4 TCS
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the AX interface to the client. Promis-

cuous VIP is enabled on the interface.
AX(config)#trunk 4
AX(config-trunk:4)#ethernet 3 to 4
AX(config-trunk:4)#exit
AX(config)#vlan 4
AX(config-vlan:4)#tagged ethernet 3 to 4
AX(config-vlan:4)#router-interface ve 4
AX(config)#interface ve 4
AX(config-if:ve4)#ip address 192.168.19.1 255.255.255.0
AX(config-if:ve4)#ip allow-promiscuous-vip
AX(config-if:ve4)#exit
The following commands configure the AX interface to the content server.

AX(config)#trunk 2
AX(config-trunk:2)#ethernet 1 to 2
AX(config-trunk:2)#exit
AX(config)#vlan 2
AX(config-vlan:2)#tagged ethernet 1 to 2
AX(config-vlan:2)#router-interface ve 2
AX(config)#interface ve 2
AX(config-if:ve2)#ip address 10.10.10.1 255.255.0.0
AX(config-if:ve2)#exit
The following commands configure the interface to the cache server:

AX(config-if:ethernet5)#ip address 110.110.110.254 255.255.255.0
The following command configures an extended ACL to match on clients

and on the content server. The ACL in this example matches on any source
address (client IP address) and on the destination IP address of the content
server.
AX(config)#access-list 198 permit ip any host 20.20.20.10 log
The following commands configure a real server for the cache server. TCP
port 80 is added to the real server.
AX(config)#slb server cache-rs 110.110.110.10
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following command configures a service group for the cache server:
AX(config)#slb service-group sg-tcs tcp
AX(config-slb svc group)#member cache-rs:80
The following commands configure a wildcard VIP and bind it to the ACL:
AX(config)#slb virtual-server wildcard 0.0.0.0 acl 198
AX(config-slb vserver)#port 80 tcp
AX(config-slb vserver-vport)#service-group sg-tcs
Configuring Layer 7 TCS

Layer 7 TCS can be configured in either of the following ways. Select one
of these methods based on the level of granularity you want to use for traffic
redirection.
• Service type HTTP without URL switching rules – This method redi-
rects all HTTP traffic to the cache server. The configuration steps are
very similar to those for Layer 4 TCS. The only difference is use of
HTTP instead of TCP or UDP as the service type of the virtual port.
• Service type HTTP with URL switching rules – This method uses an
HTTP template containing URL switching rules. Traffic that matches a
URL switching rule is redirected to the cache server. Other traffic is sent
to the gateway router.
This method requires configuration of a separate real server and service
group for the gateway router.
Figure 99 on page 248 shows an example of the first method, which does
not use URL switching rules. Figure 100 on page 249 shows an example of
the second method, which does use URL switching rules.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 99 Layer 7 TCS Without URL Switching Rules
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 100 Layer 7 TCS Using URL Switching Rules
Service Type HTTP Without URL Switching Rules

To configure this type of Layer 7 TCS:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. Configure a real server for the cache server. Add the TCP port; for
example, TCP port 80.
to it.

Add virtual port 80 with service type HTTP and bind it to the service
group containing the cache server. Enable disable destination NAT on
the virtual port.
CLI Example

Figure 99 on page 248. The commands for configuring the interfaces and
ACL, and the real server and service group for the cache server, are the
same as those used in the Layer 4 TCS example, and are therefore not
shown.
AX(config-slb vserver)#port 80 http
AX(config-slb vserver-vport)#service-group sg-tcs
Service Type HTTP with URL Switching Rules

To configure this type of Layer 7 TCS:
3. Configure a real server for the cache server. Add the TCP or UDP port;
for example, TCP port 80.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
4. Configure a real server for the next-hop router through which the AX
device will reach the content servers. Add the same TCP port number as
the one on the cache server (for example, TCP port 80). Disable health
checking on the port.
Note: The configuration requires health checking to be disabled on the router

port. The router will not respond to the health check. If you leave health
checking enabled, the AX device will mark the port down and TCS will
not work.
to it.
6. Configure a separate service group for the router, and add the router to
it.
7. Configure an HTTP template with URL switching rules. Add a separate

URL switching rule for each URI string based on which to select a ser-
vice group.

group containing the cache server. Bind the virtual port to the HTTP
template. Enable disable destination NAT.
group containing the router. Enable disable destination NAT.
CLI Example

Figure 100 on page 249. The commands for configuring the interfaces and
ACL, and the real server and service group for the cache server, are the
same as those used in the Layer 4 TCS example, and are therefore not
shown.
The following commands configure a real server for the gateway router:
AX(config)#slb server router 10.10.10.20
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure a service group for the router:

AX(config)#slb service-group sg-router tcp
AX(config-slb svc group)#member router:80
The following commands configure an HTTP template containing URL

switching rules. Client requests for any URL that contains “.examplecorp/”
or “.mycorp/” will be redirected to the service group for the cache server.
Requests for any other URL will instead be sent to the service group for the
router.
AX(config)#slb template http http1
AX(config-HTTP template)#url-switching contains .examplecorp/ service-group
sg-tcs
AX(config-HTTP template)#url-switching contains .mycorp/ service-group sg-tcs
AX(config-slb vserver-vport)#service-group sg-router
AX(config-slb vserver-vport)#template http http1
Optimizing TCS with Multiple Cache Servers
To optimize TCS in deployments that use more than one cache server, use a
destination-IP persistence template.
CLI Example

Figure 101. Only the commands specific to destination-IP persistence are
shown. The other commands are the same as those shown in the previous
sections.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 101 TCS with Multiple Cache Servers
The following commands configure the destination-IP persistence template:

AX(config)#slb template persist destination-ip d-sticky
AX(config-dest ip persistence template)#match-type service-group
Note: The match-type service-group command is required, to enable use of

URL switching and persistence in the same configuration.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the VIP. The commands are the same as
those used for Layer 7 TCS, with the addition of a command to bind the
destination-IP persistence template to the virtual port.
AX(config-slb vserver-vport)#template http http1
AX(config-slb vserver-vport)#service-group sg-router
AX(config-slb vserver-vport)#template persist destination-ip d-sticky
AX(config-slb vserver)#exit
Enabling Support for Cache Spoofing
If the cache server spoofs client IP addresses when requesting content from
servers, the following additional configuration is required:
1. Enable cache spoofing support on the AX interface connected to the
spoofing cache server. In the CLI, enter the following command at the
configuration level for the AX interface:
cache-spoofing-port
2. In the real server configuration for the cache server, enable spoof cach-
ing support. In the CLI, enter the following command at the configura-
tion level for the real server:
spoofing-cache
CLI Example
The commands in this section enable cache spoofing support for the TCS
configuration shown in Figure 101.
AX(config-if:ethernet5)#ip address 110.110.110.254 255.255.255.0
AX(config-if:ethernet5)#ip cache-spoofing-port
AX(config)#slb server cache-rs 110.110.110.10
AX(config-real server)#spoofing-cache
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Firewall Load Balancing
This chapter describes how to configure Firewall Load Balancing (FWLB).
Overview
AX Series devices support Firewall Load Balancing (FWLB). FWLB load
balances server-client sessions across firewalls. Figure 102 shows an exam-
ple FWLB topology.
FIGURE 102 Example FWLB Topology
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
This example shows two pairs of AX devices. One pair is located on the
public (unprotected) side of the network. The other pair is located on the
secured side of the network. Each pair is configured for High Availability
(HA). One member of the pair is the Active AX device and the other is a hot
Standby.
SLB for the real servers is configured on one of the AX pairs. You can con-
figure SLB for the servers on either AX pair. However, do not add the SLB
configuration to both AX pairs.
The upstream/downstream routers and the firewalls need to be configured to

use the AX device as the next hop. If HA pairs are being used, the next hop
IP configured on the upstream/downstream routers and firewalls must be an
HA-capable IP address. The following types of IP addresses are HA-capa-
ble:
• Floating IP addresses (shown in Figure 102)
• Virtual IP addresses
• IP addresses allocated from IP source NAT pools
In HA deployments, each AX device needs an HA-capable IP interface in

the subnets connected to the firewalls and those connected to real servers
and upstream/downstream routers.
Firewall Groups
This example uses a single firewall group for both firewall nodes. When
you configure FWLB, make sure to configure a firewall group for the fire-
walls rather than an SLB service group.
Templates
Although this example does not use one, you can use a source-IP persis-
tence template in an FWLB configuration. You can bind a source-IP persis-
tence template to the virtual firewall or to individual service ports on the
virtual firewall.
• If you apply a source-IP persistence template to the virtual firewall, the
AX device sends all traffic from a given source address through the
same firewall.
• If you apply a source-IP persistence template to an individual service
port on the virtual firewall, the AX device sends all traffic from a given
client for that service port through the same firewall.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Health Monitors
To monitor the health of a firewall, use a Layer 3 monitor with the ICMP
method, and with transparent mode enabled. This type of health monitor
verifies a firewall’s health by verifying the path through the firewall to the
AX device or HA pair on the other side of the firewall.
FWLB HA with Direct Connection of AX Devices to Firewalls

Layer 2 switches are not required between the A device and the firewalls.
You can connect the AX device directly to the firewalls, as shown in
Figure 103.
FIGURE 103 FWLB HA with Direct Connection of AX Devices to Firewalls
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
In this topology, each AX device is directly connected to only two of the
four firewalls, but can reach the other two firewalls at Layer 2 through the
other AX device. In this topology, one AX device is active for SLB and
FWLB and the other AX device is a hot standby for these services. The
standby AX device allows Layer 2 client-server traffic to pass through but
blocks other traffic. The active AX device load balances client-server traffic
across all four firewalls.
For example, assume that External AX1 is the active member of the HA pair
(is the one actively performing SLB and FWLB). External AX1 is directly
connected to the firewalls with interfaces 20.1.1.1 and 20.1.1.2, but can also
reach the other two firewalls by sending the traffic at Layer 2 through Exter-
nal AX2. External AX2, the standby for SLB and FWLB, allows client-
server traffic to pass through at Layer 2.
Interfaces to Clients and Servers
This topology is supported on AX devices that are deployed in route mode

(also called gateway mode). Virtual Ethernet (VE) interfaces are used to
connect the AX device to clients, servers, and the other AX device. Each
VE is configured with an IP address. In this example, External AX1 is con-
figured with the following VE interfaces:
• VE1 – Connects the AX device to clients (through the gateway routers).
• VE2 – Directly connects the AX device to some of the firewalls, and

indirectly connects to the other firewalls through the other AX device.
• VE50 – Provides the HA management and session synchronization con-
nection to the other AX device.
Static IP Routes
Each of the AX devices requires static IP routes to the following:

• Firewall VE subnet of the other AX pair
• Client or server VE subnet of the other AX pair:

• On the external AX devices, the destination address of this route is
the VE subnet connected to the real servers.
• On the internal AX devices, the destination address of this route is
the virtual IP address of a pair of external access routers running a
router redundancy protocol such as VRRP.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
In the example above, External AX1 has the following static routes:
• Destination: 30.1.1.0 Next hop: 20.1.1.1 – This route reaches the fire-
wall VE subnet of the internal AX devices, through one of the firewalls.
• Destination: 40.1.1.0 Next hop: 20.1.1.1 – This route reaches the VE
subnet of the real servers, through one of the firewalls.
Internal AX1 has the following static routes:

• Destination: 10.1.1.0 Next hop: 30.1.1.1 – This route reaches the client
VE subnet of the external AX devices, through one of the firewalls.
• Destination: 20.1.1.0 Next hop: 30.1.1.1 – This route reaches the fire-
wall VE subnet of the external AX devices, through one of the firewalls.
Notice that on each AX device, both static routes use the same next hop.
This is not required but it is recommended. Using the same hop does not
present a single point of failure. If the route to the specified next hop goes
down, the AX device automatically looks for another path to the route's des-
tination through another firewall.
Note: If the management interface is on a separate subnet, a static IP route for

this interface might also be required. This is network-dependent and is not
covered in this example.
FWLB, SLB, and HA Configuration
The FWLB and HA configuration is the same as in previous releases. There

are no new commands or options required to configure this HA solution.
To simplify configuration, A10 Networks recommends that you configure

SLB on only one of the AX pairs, either the external pair or the internal pair.
SLB does not need to be configured on both pairs.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FWLB Parameters
FWLB Parameters
Table 4 lists the FWLB parameters.
TABLE 4 FWLB Parameters

Parameter Description and Syntax Supported Values
Firewall Node Parameters
Firewall Configures the firewall. Default: None configured
(Required) [no] fwlb node fwall-name ipaddr
Config > Service > Firewall > Firewall Node
Health check Applies a configured health check to the firewall. Name of a configured health monitor
(Optional) The only type of health monitor supported for Default: The AX device attempts to
FWLB is Layer 3 ICMP with the transparent option use the default Layer 3 method (ping).
enabled. The transparent option sends health check However, this default method does not
packets to the AX device or HA pair on the other use the transparent option.
side of the firewall.
Config > Service > Firewall > Firewall Node
Firewall Group Parameters
Firewall service Configures the firewall group. Default: None configured
group fwlb service-group group-name
(Required) Config > Service > Firewall > Firewall Group
Member Adds a firewall to the firewall group. Default: None
(Required) member fwall-name [priority num] When you configure one, the default
The priority option enables you to designate some priority is 1.
firewalls as backups (the lower priority firewalls) to
be used only if the higher priority firewalls all are
unavailable.
Config > Service > Firewall > Firewall Group
Load balancing Changes the algorithm used to select a firewall for a Default: round robin
method client request, from round-robin to least-connection.
(Optional) Least connection selects the firewall that has the
fewest connections.
[no] least-connection
Config > Service > Firewall > Firewall Group
Firewall Virtual Server Parameters
Virtual firewall State of the firewall virtual server Enabled or disabled
state [no] disable Default: Enabled
(Optional) Config > Service > Firewall > Firewall Virtual
server
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FWLB Parameters
TABLE 4 FWLB Parameters (Continued)
Service ports Specifies the service ports to load balance. Protocol port number, 1-65535
(Optional) port port-number {tcp | udp} Default: No service ports are specified,
Config > Service > Firewall > Firewall Virtual which means all traffic is load bal-
server - Port tab anced.
(See the “Firewall Virtual Service Port Parameters”
below for additional port settings)
Firewall group Specifies the firewall group to use. Name of a configured firewall group
(Required) You also can specify a firewall group on individual Default: not set
service ports. If you specify a firewall group at each
level, the firewall group specified for the individual
service port takes precedence.
[no] service-group group-name
Config > Service > Firewall > Firewall Virtual
server
High Availabil- Specifies the HA group to use for the virtual fire- 1-31
ity (HA) group wall’s traffic. Default: not set
(Optional) [no] ha-group group-id
server
Session synchro- Synchronizes active sessions onto the standby AX Enabled or disabled
nization in the HA pair, to prevent the sessions from being Default: Disabled
(Optional) interrupted if an HA failover occurs.
[no] ha-conn-mirror
server
Source-IP persis- Sends all traffic from a given source address to the Name of a configured source-IP per-
tence template same firewall. sistence template
(Optional) You also can specify a source-IP persistence tem- Default: not set
plate on individual service ports. If you specify a
template at each level, the template specified for the
individual service port takes precedence.
Note: The match-type option is not applicable to
FWLB. The match type for FWLB is always server,
which sets the granularity of source-IP persistence
to individual firewalls, not firewall groups or indi-
vidual service ports.
[no] template persist source-ip
template-name
This parameter cannot be configured using the GUI.
D e s i g n 261 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FWLB Parameters
TCP idle timeout Specifies the number of seconds a TCP session 60-15000 seconds
(Optional) through a firewall can remain idle before the AX Default: 300 seconds
device terminates the session.
[no] tcp-idle-timeout seconds
server
Note: The idle timeout applied to a session can
come from the idle timeout configured here, the idle
timeout configured on the virtual firewall port, or
the idle time configured in SLB. See “TCP and
UDP Session Aging” on page 263.
UDP idle time- Specifies the number of seconds a UDP session 60-15000 seconds
out through a firewall can remain idle before the AX Default: 300 seconds
(Optional) device terminates the session.
[no] udp-idle-timeout seconds
server
timeout configured on the virtual firewall port, or
the idle time configured in SLB. See “TCP and
UDP Session Aging” on page 263.
Firewall Virtual Service Port Parameters
Firewall group Specifies the firewall group to use. Name of a configured firewall group
(Optional) If you specify a firewall group at this level, the fire- Default: not set
wall group specified here takes precedence over the
firewall group specified at the firewall level.
server - Port tab
Source-IP persis- Sends all traffic from a given source address to the Name of a configured source-IP per-
tence template same firewall. sistence template
(Optional) If you specify a source-IP persistence template at Default: not set
this level, the template specified here takes prece-
dence over the template specified at the firewall
level.
[no] template persist source-ip
template-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FWLB Parameters
TCP/UDP idle Specifies the number of seconds a session through a 60-15000 seconds
timeout firewall on this service port can remain idle before Default: 300 seconds
(Optional) the AX device terminates the session.
[no] idle-timeout seconds
server - Port tab
timeout configured on the virtual firewall, or the
idle time configured in SLB. See “TCP and UDP
Session Aging” on page 263.
TCP and UDP Session Aging

By default, the AX device allows TCP or UDP connections through a fire-
wall to be idle for 300 seconds (5 minutes). The idle timeout for a TCP or
UDP session through a firewall is determined as follows:
• For service-type UDP (Layer 4), if the idle-timeout is set on the virtual
firewall or the UDP virtual firewall port, that idle-timeout is used. Oth-
erwise, if the UDP idle-timeout is not set in FWLB, the idle-timeout in
the default SLB UDP template is used. Unless the default template has
been changed, the idle-timeout is 120 seconds.
• For service-type TCP (Layer 4), the idle-timeout in the default SLB
TCP template is used. Unless the default template has been changed, the
idle-timeout is 120 seconds.
• For service-type HTTP (Layer 7), the idle-timeout in the default SLB
TCP-proxy template is used. Unless the default template has been
changed, the idle-timeout is 600 seconds.
Note: In the current release, the TCP idle-timeout settings in FWLB are never
used. The AX device allows you to configure them but they are not used.
D e s i g n 263 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
Configuring FWLB
To configure FWLB:
1. Configure High Availability (HA) parameters: HA ID, HA group, ses-
sion synchronization, and floating IP address.
2. Configure a health check for each firewall.
3. Configure the firewalls.
4. Configure a firewall group and add the firewalls to the group.
5. Configure a virtual firewall.
To apply FWLB only to traffic for specific services, create a virtual port for
each service, and bind the firewall group to each virtual port. If FWLB will
apply to all traffic types, do not configure any virtual ports on the virtual
firewall.
If the AX device is configured for HA, specify the HA group ID to use for
the virtual port.
Note: The essential steps are described in this section. For the complete list of
FWLB settings you can configure, see Table 4 on page 260.
USING THE GUI
To configure a health check for a firewall path

3. Click Add.
4. On the Health Monitor tab, enter a name for the health monitor.
5. On the Method tab, select ICMP from the Type drop-down list.
6. Select Transparent. The Alias Address field appears.
7. Enter the AX IP address at the other end of the path to check:

• If there is a single AX device on the other side of the firewall, enter
the IP address of the AX.
• If there is an HA pair of AX device on the other side of the firewall,
enter the floating IP address of the HA pair.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
8. Click OK. The new health monitor appears in the Health Monitor table.
FIGURE 104 Config > Service > Health Monitor
To configure a firewall node

1. Select Config > Service > Firewall.
2. Select Firewall Node on the menu bar.
3. Click Add. The Firewall Node tab appears.
4. Enter the firewall name and IP address.
5. Select the health method to use for checking the path through the fire-
wall to the other AX device.
If an HA pair is configured on the other side of the firewall, enter the
floating IP address of the HA pair.
6. Click OK. The firewall appears in the Firewall Node table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
FIGURE 105 Config > Service > Firewall > Firewall Node
To configure a firewall group

1. Select Firewall Group on the menu bar.
2. Click Add. The Firewall Group tab appears.
3. On the Firewall Group tab, enter a name for the service group.
4. On the Member tab, enter the IP address of a firewall in the Firewall

field.
5. Click Add.
6. Repeat step 4 and step 5 for each firewall.
7. Click OK. The firewall group appears in the Firewall Group table.
FIGURE 106 Config > Service > Firewall > Firewall Group
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
To configure the virtual firewall
1. Select Virtual Firewall Server on the menu bar.
2. Click Add.
3. On the Default tab, select the HA group, if HA is configured.
4. Select the firewall group.
5. If you want to load balance all types of traffic through the firewalls,
click OK to complete the configuration. Otherwise, to load balance only
specific services, go to step 6.
6. To specify services to load balance:

a. On the Port tab, click Add.
b. Enter the protocol port number in the Port field.
c. Select the transport protocol (TCP or UDP) from the Type drop-
down list.
d. Select the firewall group from the Firewall Group drop-down list.
e. If HA is configured and you plan to use connection mirroring (ses-
sion synchronization), select Enabled next to HA Connection Mir-
ror.
f. Click OK.
g. Repeat for each protocol port.
h. Click OK to complete the firewall virtual server configuration.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
FIGURE 107 Config > Service > Firewall > Firewall Virtual Server
FIGURE 108 Config > Service > Firewall > Firewall Virtual Server - Port tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
USING THE CLI
1. To configure HA parameters, use the following commands at the global
ha id {1 | 2}
ha group group-id priority number
ha conn-mirror ip ipaddr
ha interface ethernet port-num
[router-interface | server-interface | both]
[no-heartbeat | vlan vlan-id]
floating-ip ipaddr ha-group group-id
2. To configure a health check for a firewall path, use the following com-
mands:
[interval seconds | retry number |
timeout seconds]
method icmp transparent ipaddr
Enter this command at the configuration level for the health monitor.
The transparent option is required and configures the health method to
check the full path through the firewall to the other AX. The ipaddr
specifies the IP address of the AX on the other side of the firewall. In an
HA configuration, the ipaddr is the floating IP address of the HA group
on the other side of the firewall.
3. To configure a firewall and assign a health monitor to it, use the follow-
ing commands:
fwlb node fwall-name ipaddr
Enter this command at the configuration level for the firewall.
4. To configure a firewall group and add the firewalls to it, use the follow-
ing commands:
fwlb service-group group-name
member fwall-name [priority num]
method least-connection
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
The priority option enables you to designate some firewalls as backups
(the lower priority firewalls) to be used only if the higher priority fire-
walls all are unavailable.
The method command is optional and changes the load-balancing
method from round-robin (the default) to least-connections.
Enter these commands at the configuration level for the firewall group.
5. To configure the virtual firewall, use the following commands:

fwlb virtual-firewall default
firewall named "default". The "default" virtual firewall is the only one
supported in the current release.
port port-number {tcp | udp}
ha-group {1 | 2}
Enter these commands at the configuration level for the virtual firewall.
The port command specifies the service port that is being protected by
the firewall. This is the virtual port configured on the VIP in the SLB
configuration. The ha-group command specifies the HA group the vir-
tual port is in.
service-group fwall-name
ha-conn-mirror
Enter these commands at the configuration level for the virtual port. The
service-group command binds the firewall group to the virtual port. The
ha-conn-mirror command enables session synchronization (connection
mirroring) between the Active and Standby AX devices in the HA con-
figuration.
Displaying FWLB Information
To display FWLB configuration information and statistics, use the follow-

ing commands:
show fwlb node [fwall-name] [config]
show fwlb service-group [group-name] [config]
show fwlb virtual-firewall [config]
In each command, the config option displays configuration information. If

you omit the config option, statistics are displayed instead.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
CLI CONFIGURATION EXAMPLE—TOPOLOGY USING LAYER 2 SWITCHES
The commands in the following example implement the FWLB configura-

tion for the External AX (Active) shown in Figure 102 on page 255. The
same commands can be used on the other AX devices, with the following
exceptions:
• The ha id command on each AX in an HA pair must use a different HA
ID. For example, since External AX A uses HA ID 1, External AX B
must use HA ID 2.
• The ha group command on each AX in an HA pair should use a differ-
ent HA priority. For example, since External AX A uses priority 100 for
the HA group, External AX B uses priority 1.
• The floating-ip commands on the each AX device must use addresses
within the subnets connected to the firewalls and upstream/downstream
routers or servers. In Figure 102 on page 255, the external AX devices
need floating IP addresses 10.1.1.100 and 192.168.1.100. The internal
AX devices need floating IP addresses 10.5.1.100 and 10.20.1.100.
• The method icmp transparent commands on the External AX devices
must use the floating IP address of the subnet on which the Internal AX
pair is connected to the firewalls.
Likewise, the method icmp transparent commands on the Internal AX
devices must use the floating IP address of the subnet on which the
External AX pair is connected to the firewalls.
CLI Commands on External AX (Active)
The following commands configure global HA parameters:

AX-Ext-A(config)#ha id 1
AX-Ext-A(config)#ha group 1 priority 100
AX-Ext-A(config)#ha interface ethernet 1
AX-Ext-A(config)#ha interface ethernet 2
AX-Ext-A(config)#ha conn-mirror ip 10.1.1.6
AX-Ext-A(config)#floating-ip 192.168.1.100 ha-group 1
AX-Ext-A(config)#floating-ip 10.1.1.100 ha-group 1
The following commands configure the health monitors:

AX-Ext-A(config)#health monitor fwpathcheck
AX-Ext-A(config-health:monitor)#method icmp transparent 10.5.1.100
AX-Ext-A(config-health:monitor)#exit
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
The following commands configure the firewalls:
AX-Ext-A(config)#fwlb node fw1 10.1.1.1
AX-Ext-A(config-firewall node)#health-check fwpathcheck
AX-Ext-A(config-firewall node)#exit
AX-Ext-A(config)#fwlb node fw2 10.1.1.2
AX-Ext-A(config-firewall node)#health-check fwpathcheck
AX-Ext-A(config-firewall node)#exit
The following commands configure the firewall groups:

AX-Ext-A(config)#fwlb service-group fwsg
AX-Ext-A(config-fwlb service group)#member fw1
AX-Ext-A(config-fwlb service group)#member fw2
AX-Ext-A(config-fwlb service group)#exit
The following commands configure the virtual firewall:

AX-Ext-A(config)#fwlb virtual-firewall default
AX-Ext-A(config-fwlb virtual firewall default)#ha-group 1
AX-Ext-A(config-fwlb virtual firewall default)#port 80 tcp
AX-Ext-A(config-fwlb virtual firewall default...)#service-group fwsg
AX-Ext-A(config-fwlb virtual firewall default...)#ha-conn-mirror
CLI Commands on External AX (Standby)

AX-Ext-S(config)#ha id 2
AX-Ext-S(config)#ha group 1 priority 1
AX-Ext-S(config)#ha interface ethernet 1
AX-Ext-S(config)#ha interface ethernet 2
AX-Ext-S(config)#ha conn-mirror ip 10.1.1.6
AX-Ext-S(config)#floating-ip 192.168.1.100 ha-group 1
AX-Ext-S(config)#floating-ip 10.1.1.100 ha-group 1
AX-Ext-S(config)#health monitor fwpathcheck
AX-Ext-S(config-health:monitor)#method icmp transparent 10.5.1.100
AX-Ext-S(config-health:monitor)#exit
AX-Ext-S(config)#fwlb node fw1 10.1.1.1
AX-Ext-S(config-firewall node)#health-check fwpathcheck
AX-Ext-S(config-firewall node)#exit
AX-Ext-S(config)#fwlb node fw2 10.1.1.2
AX-Ext-S(config-firewall node)#health-check fwpathcheck
AX-Ext-S(config-firewall node)#exit
AX-Ext-S(config)#fwlb service-group fwsg
AX-Ext-S(config-fwlb service group)#member fw1
AX-Ext-S(config-fwlb service group)#member fw2
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
AX-Ext-S(config-fwlb service group)#exit
AX-Ext-S(config)#fwlb virtual-firewall default
AX-Ext-S(config-fwlb virtual firewall default)#ha-group 1
AX-Ext-S(config-fwlb virtual firewall default)#port 80 tcp
AX-Ext-S(config-fwlb virtual firewall default...)#service-group fwsg
AX-Ext-S(config-fwlb virtual firewall default...)#ha-conn-mirror
CLI Commands on Internal AX (Active)

AX-Int-A(config)#ha id 1
AX-Int-A(config)#ha group 1 priority 100
AX-Int-A(config)#ha interface ethernet 1
AX-Int-A(config)#ha interface ethernet 2
AX-Int-A(config)#ha conn-mirror ip 10.5.1.6
AX-Int-A(config)#floating-ip 10.5.1.100 ha-group 1
AX-Int-A(config)#floating-ip 10.20.1.100 ha-group 1
AX-Int-A(config)#health monitor fwpathcheck
AX-Int-A(config-health:monitor)#method icmp transparent 10.1.1.100
AX-Int-A(config-health:monitor)#exit
AX-Int-A(config)#fwlb node fw1 10.5.1.1
AX-Int-A(config-firewall node)#health-check fwpathcheck
AX-Int-A(config-firewall node)#exit
AX-Int-A(config)#fwlb node fw2 10.5.1.2
AX-Int-A(config-firewall node)#health-check fwpathcheck
AX-Int-A(config-firewall node)#exit
AX-Int-A(config)#fwlb service-group fwsg
AX-Int-A(config-fwlb service group)#member fw1
AX-Int-A(config-fwlb service group)#member fw2
AX-Int-A(config-fwlb service group)#exit
AX-Int-A(config)#fwlb virtual-firewall default
AX-Int-A(config-fwlb virtual firewall default)#ha-group 1
AX-Int-A(config-fwlb virtual firewall default)#port 80 tcp
AX-Int-A(config-fwlb virtual firewall default...)#service-group fwsg
AX-Int-A(config-fwlb virtual firewall default...)#ha-conn-mirror
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
CLI Commands on Internal AX (Standby)
AX-Int-S(config)#ha id 2
AX-Int-S(config)#ha group 1 priority 1
AX-Int-S(config)#ha interface ethernet 1
AX-Int-S(config)#ha interface ethernet 2
AX-Int-S(config)#ha conn-mirror ip 10.5.1.5
AX-Int-S(config)#floating-ip 10.5.1.100 ha-group 1
AX-Int-S(config)#floating-ip 10.20.1.100 ha-group 1
AX-Int-S(config)#health monitor fwpathcheck
AX-Int-S(config-health:monitor)#method icmp transparent 10.1.1.100
AX-Int-S(config-health:monitor)#exit
AX-Int-S(config)#fwlb node fw1 10.5.1.1
AX-Int-S(config-firewall node)#health-check fwpathcheck
AX-Int-S(config-firewall node)#exit
AX-Int-S(config)#fwlb node fw2 10.5.1.2
AX-Int-S(config-firewall node)#health-check fwpathcheck
AX-Int-S(config-firewall node)#exit
AX-Int-S(config)#fwlb service-group fwsg
AX-Int-S(config-fwlb service group)#member fw1
AX-Int-S(config-fwlb service group)#member fw2
AX-Int-S(config-fwlb service group)#exit
AX-Int-S(config)#fwlb virtual-firewall default
AX-Int-S(config-fwlb virtual firewall default)#ha-group 1
AX-Int-S(config-fwlb virtual firewall default)#port 80 tcp
AX-Int-S(config-fwlb virtual firewall default...)#service-group fwsg
AX-Int-S(config-fwlb virtual firewall default...)#ha-conn-mirror
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
CLI CONFIGURATION EXAMPLE—TOPOLOGY WITHOUT LAYER 2 SWITCHES
The following sections show the CLI commands for configuring interfaces,
FWLB, and HA on each of the AX devices shown in Figure 103 on
page 257. For simplicity, the SLB configuration is not shown.
Configuration of External AX1
The following commands configure the HA management and session syn-

chronization interface to the other AX device.
Ext-AX1(config)#trunk 1
Ext-AX1(config-trunk:1)#ethernet 9 to 10
Ext-AX1(config-trunk:1)#exit
Ext-AX1(config)#vlan 50
Ext-AX1(config-vlan:50)#untagged ethernet 9 to 10
Ext-AX1(config-vlan:50)#router-interface ve 5
Ext-AX1(config-vlan:50)#exit
Ext-AX1(config)#interface ve 5
Ext-AX1(config-if:ve5)#ip address 50.1.1.1 255.255.255.0
Ext-AX1(config-if:ve5)#exit
The following commands configure the VE interface to clients:

Ext-AX1(config-vlan:10)#untagged ethernet 1
The following commands configure the VE interface to the firewalls:

Ext-AX1(config-vlan:20)#untagged ethernet 2 ethernet 4 ethernet 13
The following commands configure the static routes:

Ext-AX1(config)#ip route 40.1.1.0 /24 20.1.1.1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
Ext-AX1(config)#ha id 1
Ext-AX1(config)#ha group 1 priority 200
Ext-AX1(config)#ha interface ethernet 1
Ext-AX1(config)#ha conn-mirror ip 50.1.1.2
Ext-AX1(config)#ha preemption-enable
Ext-AX1(config)#floating-ip 20.1.1.254 ha-group 1
The following commands configure a Layer 2 health monitor to check the

health of the paths through the firewalls to the floating IP address config-
ured on the other AX pair:
Ext-AX1(config)#health monitor tsping interval 15
Ext-AX1(config-health:monitor)#method icmp transparent 40.1.1.254
Ext-AX1(config-health:monitor)#exit
The following commands configure the FWLB parameters:

Ext-AX1(config)#fwlb node fw1 20.1.1.1
Ext-AX1(config-firewall node)#health-check tsping
Ext-AX1(config-firewall node)#exit
Ext-AX1(config)#fwlb service-group fwsg
Ext-AX1(config-fwlb service group)#member fw1
Ext-AX1(config-fwlb service group)#exit
Ext-AX1(config)#fwlb virtual-firewall default
Ext-AX1(config-fwlb virtual firewall default)#ha-group 1
Ext-AX1(config-fwlb virtual firewall default)#service-group fwsg
Ext-AX1(config-fwlb virtual firewall default)#ha-conn-mirror
Ext-AX1(config-fwlb virtual firewall default)#port 80 tcp
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
Ext-AX1(config-slb virtual firewall default...)#service-group fwsg
Ext-AX1(config-slb virtual firewall default...)#ha-conn-mirror
Configuration of External AX2
This configuration is like the configuration for External AX1, with the fol-
lowing exceptions:
• The VE IP addresses are different (although they are in the same subnets
as those on the other AX device).
• The HA ID, priority, and connection mirroring IP address are different
from the other AX device.
The FWLB configuration is the same. For brevity, it is not shown.

Ext-AX2(config)#trunk 1
Ext-AX2(config-trunk:1)#ethernet 9 to 10
Ext-AX2(config-trunk:1)#exit
Ext-AX2(config-vlan:50)#untagged ethernet 9 to 10
Ext-AX2(config-vlan:10)#untagged ethernet 1
Ext-AX2(config-vlan:20)#untagged ethernet 2 ethernet 4 ethernet 13
Ext-AX2(config)#ha id 2
Ext-AX2(config)#ha group 1 priority 100
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
Ext-AX2(config)#ha conn-mirror ip 50.1.1.1
Ext-AX2(config)#ha preemption-enable
Ext-AX2(config)#floating-ip 20.1.1.254 ha-group 1
Configuration of Internal AX1
This configuration is like the configuration for External AX1, with the fol-
lowing exceptions:
• The VE IP addresses and subnets are different. (The VLAN numbers
and some of the VE numbers also are different, but this is not required.
For simplicity, the VLAN numbers were selected to match the subnet
numbers.)
• The static routes are different.
• The floating IP address and connection mirroring IP address are differ-

ent.
• The target IP address of the transparent Layer 3 health check is the float-
ing IP address of the external AX pair.
• The IP addresses of the firewall nodes are different.
The following commands configure the HA management and session syn-

chronization interface to the other AX device.
Int-AX1(config)#trunk 1
Int-AX1(config-trunk:1)#ethernet 9 to 10
Int-AX1(config-trunk:1)#exit
Int-AX1(config)#vlan 60
Int-AX1(config-vlan:60)#untagged ethernet 9 to 10
Int-AX1(config-vlan:60)#router-interface ve 60
Int-AX1(config-vlan:60)#exit
Int-AX1(config)#interface ve 60
Int-AX1(config-if:ve60)#ip address 60.1.1.1 255.255.255.0
Int-AX1(config-if:ve60)#exit
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
The following commands configure the VE interface to the servers:
Int-AX1(config-vlan:40)#untagged ethernet 2
The following commands configure the VE interface to the firewalls:

Int-AX1(config-vlan:30)#untagged ethernet 1 ethernet 3 ethernet 13
The following commands configure the static routes:

Int-AX1(config)#ip route 10.1.1.0 /24 30.1.1.1

Int-AX1(config)#ha id 1
Int-AX1(config)#ha group 1 priority 200
Int-AX1(config)#ha interface ethernet 1
Int-AX1(config)#ha conn-mirror ip 60.1.1.2
Int-AX1(config)#ha preemption-enable
Int-AX1(config)#floating-ip 40.1.1.254 ha-group 1
Configuration of Internal AX2
This configuration is like the configuration for Internal AX1, with the fol-
lowing exceptions:
• The VE IP addresses are different (although they are in the same subnets
as those on the other AX device).
• The HA ID, priority, and connection mirroring IP address are different
from the other AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring FWLB
The health monitor and FWLB configuration is the same. For brevity, it is
not shown.
Int-AX2(config)#trunk 1
Int-AX2(config-trunk:1)#ethernet 9 to 10
Int-AX2(config-trunk:1)#exit
Int-AX2(config-vlan:60)#untagged ethernet 9 to 10
Int-AX2(config-vlan:40)#untagged ethernet 2
Int-AX2(config-vlan:30)#untagged ethernet 1 ethernet 3 ethernet 13
Int-AX2(config)#ha id 2
Int-AX2(config)#ha group 1 priority 100
Int-AX2(config)#ha conn-mirror ip 60.1.1.1
Int-AX2(config)#ha preemption-enable
Int-AX2(config)#floating-ip 40.1.1.254 ha-group 1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Server and Port Templates
This chapter describes how to configure parameters for multiple servers and
service ports using server and port templates.
Overview
The AX device supports the following types of templates for configuration
of SLB servers and ports:
• Server – Contains configuration parameters for real servers
• Port – Contains configuration parameters for real service ports
• Virtual-server – Contains configuration parameters for virtual servers
• Virtual-port – Contains configuration parameters for virtual service

ports
These template types provide the same benefit as other template types. They
allow you to configure a set of parameter values and apply the set of values
to multiple configuration items. In this case, you can configure sets of
parameters (templates) for SLB assets (servers and service ports) and apply
the parameters to multiple servers or ports.
Some of the parameters that can be set using a template can also be set or
changed on the individual server or port.
• If a parameter is set (or changed from its default) in both a template and
on the individual server or port, the setting on the individual server or
port takes precedence.
• If a parameter is set (or changed from its default) in a template but is not
set or changed from its default on the individual server or port, the set-
ting in the template takes precedence.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Parameters That Can Be Configured Using Server and Port

Templates
Table 5 describes the server and port parameters you can configure using
templates.
TABLE 5 SLB Port and Server Template Parameters

Template Type Parameter Description
Real Server Health monitor Assigns a configured Layer 3 health monitor to all servers
that use the template. (See “Configuring and Applying a
Health Method” on page 303.)
Connection limit Specifies the maximum number of connections allowed on
any server that uses the template. (See “Connection Limit-
ing” on page 290.)
Connection rate limit- Limits the rate of new connections the AX is allowed to
ing send to any server that uses the template. (See “Connection
Rate Limiting” on page 292.)
Slow start Provides time for servers that use the template to ramp-up
after TCP/UDP service is enabled, by temporarily limiting
the number of new connections on the server. (See “Slow-
Start” on page 294.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
TABLE 5 SLB Port and Server Template Parameters (Continued)
Real Server Port Health monitor Assigns a configured Layer 4-7 health monitor to all service
ports that use the template. (See “Configuring and Applying
a Health Method” on page 303.)
In-band health monitor Provides rapid server status change and reassignment based
on client-server traffic.
This is an enhanced health check mechanism that works
independently of the standard out-of-band health mecha-
nism. See “In-Band Health Monitoring” on page 322.
Connection limit Specifies the maximum number of connections allowed on
any real port that uses the template. (See “Connection Lim-
iting” on page 290.)
ing send to any real port that uses the template. (See “Connec-
tion Rate Limiting” on page 292.)
Destination NAT Enables destination Network Address Translation (NAT).
Destination NAT is enabled by default, but is disabled in
Direct Server Return (DSR) configurations.
You can re-enable destination NAT on individual ports for
deployment of mixed DSR configurations. See “Direct
Server Return in Mixed Layer 2/Layer 3 Environment” on
page 82.
DSCP Sets the differentiated services code point (DSCP) value in
the IP header of a client request before sending the request
to a server.
Slow start Provides time for real ports that use the template to ramp-up
after TCP/UDP service is enabled, by temporarily limiting
the number of new connections on the ports. (See “Slow-
Start” on page 294.)
Source NAT Specifies the IP NAT pool to use for assigning a source IP
address to client traffic addressed to the port. For informa-
tion about NAT, see “Network Address Translation” on
page 483
Weight Biases load-balancing selection of this port. A higher weight
gives more favor to the server and port relative to the other
servers and ports.
For an example of weighted SLB, see “FTP Load Balanc-
ing” on page 141. (The example configures weights directly
on the real service ports rather than using templates, but still
illustrates how the weight option works.)
Note: The weight option applies only to the weighted-least-
connection, service-weighted-least-connection, and
weighted-round-robin load-balancing methods.
D e s i g n 283 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
TABLE 5 SLB Port and Server Template Parameters (Continued)
Virtual Server Connection limit Specifies the maximum number of connections allowed on
any VIP that uses the template. (See “Connection Limiting”
on page 290.)
ing send to any VIP that uses the template. (See “Connection
Rate Limiting” on page 292.)
ICMP rate limiting Limits the rate at which ICMP packets can be sent to the
VIP. (See “ICMP Rate Limiting” on page 540.)
Virtual Server Port Connection limit Specifies the maximum number of connections allowed on
any virtual service port that uses the template. (See “Con-
nection Limiting” on page 290.)
ing send to any virtual service port that uses the template. (See
“Connection Rate Limiting” on page 292.)
Default Server and Service Port Templates

The AX device has a default template for each of these template types. If
you do not explicitly bind a server or service port template to a server or ser-
vice port, the default template is automatically applied. For example, when
you create a real server, the parameter settings in the default real server tem-
plate are automatically applied to the new server, unless you bind a different
real server template to the server.
The default server and port templates are each named “default”. The default
settings in the templates are the same as the default settings for the parame-
ters that can be set in the templates.
If you are upgrading an AX device that has a configuration saved under a

previous release, the default server and port templates are automatically
bound (applied to) the servers and ports in the configuration. This does not
change the configuration or operation of the servers and ports themselves,
since the default server and port templates use the default settings for all
parameters, unless overridden by parameter settings on the individual serv-
ers and ports.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Server and Service Port Templates
Configuring Server and Service Port Templates

To configure a server or port template, use either of the following methods.
USING THE GUI

2. On the menu bar, select one of the following:

• Template > Server
• Template > Server Port
• Template > Virtual Server
• Template > Virtual Server Port
The list of configured templates of the selected type appears.
3. Click Add to create a new one or click on the name of a configured tem-
plate to edit it. The configuration tab for the template appears.
4. Enter a name for the template (if the template is new).
5. Enter or edit other settings. (See the descriptions in the sections below
for information.)
6. Click OK.
USING THE CLI

To configure server and service-port templates, use the following com-
mands at the global configuration level of the CLI:
[no] slb template server template-name
[no] slb template port template-name
[no] slb template virtual-server template-name
[no] slb template virtual-port template-name
The template name can be 1-31 characters. These commands change the
CLI to the configuration level for the template. To modify the default tem-
plate, specify the name “default” (without the quotation marks).
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Applying a Server or Service Port Template
To display the settings in a template, use one of the following commands:
show slb template server template-name
show slb template port template-name
show slb template virtual-server template-name
show slb template virtual-port template-name
CLI Example
The following commands configure a new real server template and bind the
template to two real servers:
AX(config)#slb template server rs-tmplt1
AX(config-rserver)#health-check ping2
AX(config-rserver)#conn-limit 500000
AX(config-rserver)#exit
AX(config-real server)#template server rs-tmplt1
This example includes the commands to bind the template to real servers.
For information about binding the templates, see “Applying a Server or Ser-
vice Port Template” on page 286.

If you modify a “default” server or port template, the changes are automati-
cally applied to any servers or ports that are not bound to another server or
port template.
If you create a new server or port template, the template takes effect only
after you bind it to servers or ports.
Table 6 lists the types of bindings that are supported for server and port tem-
plates.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 6 Server and Port Template Bindings

Template
Type Can Be Bound To...
Server Real servers
Port Real server ports
You can apply them to real server ports directly or in a service
group.
Note: Binding a server port template to a service port within a
service group provides a finer level of control than binding
the template directly to a port. When the template is bound to
the port only within a service group, and not bound to the port
directly, the template settings apply to the port only when the
port is used by the service group.
The settings do not apply to the same port if used in other ser-
vice groups.
Virtual Server Virtual servers
Virtual Server Virtual server ports
Port
The following subsections describe how to bind server and port templates to
servers, ports, and service group members. For configuration examples, see
the feature sections referred to in Table 5 on page 282.
Binding a Server Template to a Real Server
USING THE GUI

2. Click Server on the menu bar.
3. Click on the server name.
4. Select the template from the Server Template drop-down list. To create
one, click create.
5. When finished, click OK.
USING THE CLI
Enter the following command at the configuration level for the real server:
[no] template server template-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Binding a Server Port Template to a Real Server Port
USING THE GUI

2. Click Server on the menu bar.
3. Click on the server name.
4. On the Port tab, select the template from the Server Port Template drop-
down list. To create one, click create.
5. Click Update.
USING THE CLI
Enter the following command at the configuration level for the real port:
[no] template port template-name
Binding a Virtual Server Template to a Virtual Server
USING THE GUI

2. Click Virtual Server on the menu bar.
3. Click on the virtual server name.
4. Select the template from the Virtual Server Template drop-down list. To
create one, click create.
USING THE CLI
Enter the following command at the configuration level for the virtual
server:
[no] template virtual-server template-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Binding a Virtual Server Port Template to a Virtual Service Port
USING THE GUI

2. Click Virtual Server on the menu bar.
4. On the Port tab, select the port and click Edit.
5. Select the template from the Virtual Server Port Template drop-down
list.
6. Click OK.
USING THE CLI
Enter the following command at the configuration level for the virtual ser-
vice port:
[no] template virtual-port template-name
Binding a Server Port Template to a Service Group
USING THE GUI

2. Click Service Group on the menu bar.
3. On the Server tab, select the server port template from the Server Port
Template drop-down list.
4. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Connection Limiting
USING THE CLI
At the configuration level for the service group, use the template tem-
plate-name option with the member command:
[no] member server-name:portnum

[disable | enable]
[priority num]
[template port template-name]
Connection Limiting
By default, the AX device does not limit the number of concurrent connec-
tions on a server or service port. If certain servers or services are becoming
oversaturated, you can set a connection limit. The AX device stops sending
new connection requests to a server or port when that server or port reaches
its maximum allowed number of concurrent connections.
Connection Limit Parameters

To configure connection limits, you can set the following parameters :
• Connection limit – Specifies the maximum number of concurrent con-
nections allowed on a server or port. You can specify 0-1048575. By
default, the connection limit is not set.
• Connection resume threshold (real servers or ports only) – Specifies the
maximum number of connections the server or port can have before the
AX device resumes use of the server or port. You can specify 1-1048575
(1 million) connections.
• Reset or Drop (virtual servers or virtual server ports only) – Specifies
the action to take for connections after the connection limit is reached on
the virtual server or virtual server port. By default, excess connections
are dropped. If you change the action to reset, the connections are reset
instead. Excess connections are dropped by default.
Connection limiting can be set in real server templates, real port templates,
virtual server templates, and virtual port templates.
Setting a Connection Limit
To set a connection limit in a server or port template, use either of the fol-
lowing methods.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Connection Limiting
USING THE GUI
On the configuration tab for the template:
1. Select the Connection Limit Status checkbox to display the configura-
tion fields.
2. In the Connection Limit field, enter the maximum number of concurrent

connections to allow on the server or port.
3. (Server or Server Port Templates only) In the Connection Resume, enter

the maximum number of connections the server or port can have before
the AX device resumes use of the server or port.
4. (Virtual Server or Virtual Server Port Templates only) Select the action
to take for connections that occur after the limit is reached: Drop or
Reset.
5. Click OK.
USING THE CLI

To set a connection limit using a server or server port template, use the fol-
lowing command at the configuration level for the template:
[no] conn-limit max-connections
[resume connections]
To set a connection limit using a virtual server or virtual server port tem-
plate, use the following command at the configuration level for the tem-
plate:
[no] conn-limit max-connections [reset]
CLI Example
The following commands set the connection limit to 500,000 concurrent
connections in a real server template, then bind the template to real servers:
AX(config-rserver)#conn-limit 500000
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Connection Rate Limiting

You can limit the rate at which the AX device is allowed to send new con-
nections to servers or service ports.
Note: Connection rate limiting is different from slow-start, which temporarily

limits the number of new connections per second when TCP/UDP service
comes up on a service port. See “Slow-Start” on page 294.
Connection Rate Limiting Parameters

When you configure connection rate limiting, you can set the following
parameters:
• Connection rate limit – The connection rate limit specifies the maximum
of new connections allowed on a server or service port. You can specify
1-1048575 connections. By default, the connection rate limit is not set.
• Interval – The interval specifies whether the connection rate limit
applies to one-second intervals or 100-ms intervals. The default is one-
second intervals.
• Action for excess connections (virtual servers or virtual server ports
only) – The action specifies how the AX device responds to connection
requests after the connection rate has been exceeded. The action can be
to silently drop excess connections or to send a reset (RST) to client
requesting the connection. The default action is to silently drop the
excess connection requests.
When a server or service port reaches its connection limit, the AX device
stops using the server or service port.
USING THE GUI

On the configuration tab for the template:
1. Select the Connection Rate Limit checkbox to activate the configuration
fields.
2. Enter the connection rate limit in the field next to the checkbox.
3. Select the sampling interval: 100ms or 1 second.
4. Select the action to take for connections that exceed the limit: Drop or
Reset.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
5. (Virtual Server or Virtual Server Port Templates only) Select the action
to take for connections that occur after the limit is reached: Drop or
Reset.
6. Click OK.
USING THE CLI

To configure connection rate limiting for a real server or service port, use
the following command at the configuration level for a server or server port
template, and apply the template to the server or port:
[no] conn-rate-limit connections
[per {100ms | 1sec}]
The connections option specifies the maximum number of new connections
allowed per interval.
The per {100ms | 1sec} option specifies the interval.
If you configure a limit for a server and also for an individual port, the AX
device uses the lower limit. For example, if you limit new TCP connections
to a real server to 5000 per second and also limit new HTTP connections to
1200 per second, the AX device limits connections to TCP port HTTP to
1200 per second.
To configure connection rate limiting for a virtual server or service port, use
the following command at the configuration level for a virtual server or vir-
tual server port template, and apply the template to the virtual server or vir-
tual server port:
[no] conn-rate-limit connections
[per {100ms | 1sec}] [reset]
The reset option resets connections that occur after the limit is reached. By
default, excess connections are dropped.
To display connection rate limiting information, use the following com-
mands:
show slb server [server-name] detail
show slb virtual-server [server-name] detail
CLI Example
The following commands configure connection rate limiting in a real server
template, then bind the template to real servers.
AX(config-rserver)#conn-rate-limit 50000
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Slow-Start
Slow-Start
The slow-start feature allows time for a server or real service port to ramp
up after TCP/UDP service on a server is enabled, by temporarily limiting
the number of new connections on the server or port.
You can configure the slow-start parameters described in this section in real
server templates and real port templates.
Note: Alternatively, you can enable slow-start on individual real servers. How-
ever, the ramp-up settings on individual servers are not configurable. The
settings are the same as the default ramp-up settings in server and port
templates.
Ramp-Up Parameters
The default ramp-up is as follows: when enabled, the feature first limits the
server to 128 new connections per second for the first 10 seconds, then dou-
bles the number of new connections allowed in every subsequent 10-second
interval until 4096 new connections per second are allowed. The ramp up
continues for a total of 60 seconds.
You can configure the following ramp-up parameters:

• Starting connections per second – The starting connections per second is
the maximum number of new connections per second to allow on the
server or service port when it first comes up. You can specify from 1-
4095 new connections per second. The default is 128.
• Connection increment – The connection increment specifies the amount
by which to increase the number of new connections per second, using
one of the following parameters:
• Scale factor (This is the default.) – The scale factor is the number by
which to multiply the starting connections per second. For example,
if the scale factor is 2 and the starting connections per second is 128,
the AX device increases the number of new connections per second
to 256 after the first ramp-up interval. The scale factor can be 2-10.
The default is 2.
• Connection addition – As an alternative to specifying a scale factor,
you can instead specify how many new connections per second to
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Slow-Start
allow. The connection addition can be 1-4095 new connections per
second.
• Ramp-up interval – The ramp-up interval specifies the number of sec-
onds between each increase of the number of new connections allowed.
For example, if the ramp-up interval is 10 seconds, the number of new
connections per second to allow is increased every 10 seconds. The
ramp-up interval can be 1-60 seconds. The default is 10 seconds.
• Ending connections per second – The ending connections per second is
the number of new connections per second at which the ramp-up is com-
pleted. You can specify from 1-65535 new connections per second. The
default is 4096.
Note: For the connection increment, you can specify a scale factor or a connec-
tion addition. The ending connections per second must be higher than the
starting connections per second.
USING THE GUI
On the configuration tab for the real server template or real port template:
1. Select the Slow Start checkbox to activate the configuration fields.
2. Enter the starting number of connections per second in the field to the
right of "From".
3. Enter the connection increment method: Multiplying or Adding.
4. Enter the connection increment in the field next to the increment method
you selected.
5. Enter the ramp-up interval in the Every field.
6. Enter the ending connections per second in the Till field.
7. Click OK.
USING THE CLI
To configure slow-start, use the following command at the configuration

level for a real server or real service port:
[no] slow-start
[from starting-conn-per-second]
[times scale-factor | add conn-incr]
[every interval]
[till ending-conn-per-second]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Slow-Start
CLI Example
The following commands enable slow start in a real server template, using
the default settings, and bind the template to real servers.
AX(config-rserver)#slow-start
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Default Health Checks
Health Monitoring
AX Series devices can regularly check the health of real servers and service
ports. Health checks ensure that client requests go only to available servers.
Servers or ports that respond appropriately to health checks remain eligible
to serve client requests. A server or port that does not respond appropriately
to a health check is temporarily removed from service, until the server or
port is healthy again.
You can configure health methods on the AX device by configuring settings

for the type of service you are monitoring. You also can configure health
monitors externally using scripts and import the monitors for use by the AX
device.
Default Health Checks

The AX device performs the following types of health checks by default:
• Layer 3 ping – The AX device sends an ICMP echo request (ping)
addressed to the real server’s IP address. The server passes the health
check if it sends an echo reply to the AX device.
• Layer 4 TCP – Every 30 seconds, the AX device sends a connection
request (TCP SYN) to the specified TCP port on the server. The port
passes the health check if the server replies to the AX device by sending
a TCP SYN ACK.
• Layer 4 UDP – Every 30 seconds, the AX device sends a packet with a
valid UDP header and a garbage payload to the UDP port. The port
passes the health check if the server either does not reply, or replies with
any type of packet except an ICMP Error message.
The AX device always performs Layer 3 and Layer 4 health checks using
these methods, unless you disable them on the real server or service port or
configure other monitors for the same methods (ICMP, TCP, or UDP).
The ICMP, TCP, and UDP monitors are used even if you also apply addi-
tional configured monitors to a service port.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Health Method Timers
Health Method Timers

Health methods operate based on the following timers:
• Interval – Number of seconds between each check using the monitor. By
default, the AX device uses monitors every 30 seconds. If you need to
fine-tune this interval, you can change it to a value from 1-180 seconds.
• Timeout – Number of seconds the AX device waits for a reply to a
health check. If the AX device does not receive the expected reply by
the end of the timeout, the AX device either sends the health check
again (if there are retries left) or marks the server or service down. You
can specify 1-12 seconds. The default is 5 seconds.
The type of reply expected by the AX device depends on the monitor
type. (See “Health Method Types” on page 298.)
• Retries – Maximum number of times the AX device will send the same
health check to an unresponsive server or service before marking that
server or service as down. You can specify 1-4. The default is 3.
• Up-Retry – Number of consecutive times the device must pass the same
periodic health check, in order to be marked Up. You can specify 1-10.
The default is 1. (See “Consecutive Health Checks Within a Health
Check Period” on page 325.)
Note: The timeout does not apply to externally configured health monitors.
Health Method Types

Table 7 lists the internal health method types supported by the AX device.
The health methods use the well-known port numbers for each application
by default. You can change the port numbers and other options when you
define the health methods.
Multiple health method instances can be defined using the same method
type and different parameters. Likewise, multiple health monitors can use
the same health method to check different servers.
When a health monitor is in use by a server, the monitor cannot be removed.
Note: To configure a health monitor for Direct Server Return (DSR), see “Con-
figuring Health Monitoring of Virtual IP Addresses in DSR Deploy-
ments” on page 308.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Health Method Types
TABLE 7 Internal Health Method Types

Configuration Required
Type Description Successful If... on Target Server
DNS AX Series sends a lookup Server sends a reply with the Domain name in the lookup
request for the specified domain expected status code (0 by request must be in the server’s
name or server IP address. default) and record type (A by database.
By default, recursion is allowed. default).
The tested DNS server is You can configure the response
allowed to send the health code(s) and record type required
check’s request to another DNS for a successful health check.
server if the tested server can not You can require the server to
fulfill the request using its own reply with specific status codes
database. Optionally, you can within the range 0-15.
disable recursion.
For health checks sent to a
domain name, you can require
the server to reply with one of
the following record types:
• A – IPv4 address record (the
default)
• CNAME – Canonical name
record for a DNS alias
• SOA – Start of authority
record
• PTR – Pointer record for a
domain name
• MX – Mail Exchanger record
• TXT – Text string
• AAAA – IPv6 address record
(For more information, see

“Customizing DNS Health Mon-
itors” on page 312.)
FTP AX Series sends an FTP login Server replies with FTP OK Requested user name and
request to the specified port. message or Password message. password must be valid on the
If anonymous login is not used, If the server sends the Password server.
the username also must be speci- message, the AX Series sends
fied in the health check configu- the password specified in the
ration. health check configuration. In
this case, the AX Series expects
the server to reply with another
OK message.
D e s i g n 299 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Health Method Types
TABLE 7 Internal Health Method Types (Continued)
HTTP / AX Series sends an HTTP GET, Server replies with OK message Requested page (URL) must
HTTPS HEAD, or POST request to the (200), by default. You can con- be present on the server.
specified TCP port and URL. figure the response code(s) and For GET requests, the string
• GET requests the entire page. record type required for a suc- specified as the expected
cessful health check. reply must be present.
• HEAD requests only the
meta-information in the For GET requests, the server For POST operations, the
header. also must reply with the field names specified in the
requested content or meta-infor- health check must be present
• POST attempts to write infor-
mation in the page header. The on the requested page.
mation to the server. For
response must include the string
POST requests, you must For HTTPS health checks,
specified in the Expect field on
specify the target field names SSL support must be enabled
the AX Series.
and the values to post. (For on the server.
more information, see “Con- For HEAD requests, the
A certificate does not need to
figuring POST Requests in AX Series ignores the Expect
be installed on the AX device.
HTTP/HTTPS Health Moni- field and only checks for the
The AX device always
tors” on page 310.) server reply message.
accepts the server certificate
If a user name and password are For POST operations, the data presented by the server.
required to access the page, they must be posted without error.
also must be specified in the
health check configuration.
By default, the real server’s IP
address is placed in the request
header’s Host: field. You can
configure a different value if
needed.
The following types of authenti-
cation are supported: basic,
digest and NT LAN Manager
(NTLM) authentication. If you
specify a username and pass-
word, the health monitor will try
to use basic authentication first.
If this try succeeds, the authenti-
cation process is complete. Oth-
erwise, the health monitor will
negotiate with the server to
select another authentication
method, and retry the health
check using that authentication
method.
ICMP AX Series sends an ICMP echo Server replies with an ICMP Server must be configured to
request (ping) to the server. echo reply message. reply to ICMP echo requests.
Note: This is a Layer 3 health
check only. Use the other
method types to check the health
of a specific application.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Health Method Types
LDAP AX Series sends an LDAP Server sends a reply containing If a Distinguished Name and
request to the LDAP port. result code 0. password are sent in the
Optionally, the request can be health check, they must match
directed to a specific Distin- these values on the LDAP
guished Name. server.
Optionally, SSL can be enabled A certificate does not need to
for the health check. be installed on the AX Series.
The AX Series always accepts
The AX Series also must send a
the server certificate pre-
valid password, if one is required
sented by the server.
by the server.
NTP AX Series sends an NTP client Server sends a standard NTP NTP service must be running.
message to UDP port 123. 48-byte reply packet.
POP3 AX Series sends a POP3 user Server replies with an OK mes- Requested user name and
login request with the specified sage. password must be valid on the
user parameter. The AX Series then sends the server.
password specified in the health
check configuration. The
AX Series expects the server to
reply with another OK message.
RADIUS AX Series sends a Password Server sends Access Accepted Requested user name and
Authentication Protocol (PAP) message (reply code 2). password must be configured
request to authenticate the user in the server’s user database.
name and password specified in Likewise, the shared secret
the health check configuration. sent in the health check must
be valid on the server.
RTSP AX Series sends a request for Server replies with information The file must be present on
information about the file speci- about the specified file. the RTSP server.
fied in the health check configu-
ration.
SIP AX Series sends a SIP OPTION Server replies with 200 - OK. None.
request or REGISTER request.
SMTP AX Series sends an SMTP Hello Server sends an OK message Server recognizes and accepts
message. (reply code 250). the domain of sender. If
SMTP service is running and
can reply to Hello messages,
the server can pass the health
check.
SNMP AX Series sends an SNMP Get Server replies with the value of Requested OID and the
or Get Next request to the speci- the OID. SNMP community must both
fied OID, from the specified be valid on the server.
community.
D e s i g n 301 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Health Method Types
TCP AX Series sends a connection Server replies with a TCP SYN Destination TCP port of the
request (TCP SYN) to the speci- ACK. health check must be valid on
fied TCP port on the server. By default, the AX device com- the server.
pletes the TCP handshake with
the server:
AX -> Server
SYN ->
<- SYN-ACK
ACK ->
FIN-ACK ->
<- FIN-ACK
ACK ->
To configure the AX device to

send a RST (Reset) instead of
sending the first ACK, enable
the Halfopen option. In this case,
the health check is performed as
follows:
SYN ->
<- SYN-ACK
RST ->
UDP AX Series sends a packet with a Server does either of the follow- Destination UDP port of the
valid UDP header and a garbage ing: health check must be valid on
payload to the specified UDP • Replies from the specified the server.
port on the server. UDP port with any type of
packet.
• Does not reply at all.
The server fails the health check
only if the server replies with an
ICMP Error message.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring and Applying a Health Method
Protocol Port Numbers Tested by Health Checks

If you specify the protocol port number to test in a health monitor, the proto-
col port number configured in the health monitor is used if you send an on-
demand health check to a server without specifying the protocol port. (See
“On-Demand Health Checks” on page 326.)
After you bind the health monitor to a real server port, health checks using
the monitor are addressed to the real server port number instead of the port
number specified in the health monitor’s configuration. In this case, you can
override the IP address or port using the override options described in
“Overriding the Target IP Address or Protocol Port Number” on page 315.

1. Create a new health monitor and configure its settings for the type of
service you are monitoring. If you created the monitor externally with a
script, import the script.
2. Apply the monitor to the real server (for Layer 3 checks) or service port.
You can apply a health monitor to a server or port in either of the follow-
ing ways:
• Apply the health monitor to a server or port template, then bind the
template to the server or port.
• Apply the health monitor directly to the individual server or port.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
To configure an internal monitor

3. Click Add.
4. On the Health Monitor tab, enter a name for the monitor.
5. On the Method tab, select the monitor type from the Type drop-down
list. The rest of the configuration fields change depending on the moni-
tor type. (See “Health Method Types” on page 298.)
6. Enter or select settings for the monitor.
7. Click OK. The new monitor appears in the Health Monitor table.
To import an externally configured monitor

1. Create a script for the monitor. (For an example, see “External Health
Method Examples” on page 331.)
2. In the AX management GUI, select Config > Service > Health Monitor.
3. Select External Program on the menu bar.
4. Click Add.
5. Enter a name and description for the external health method.
6. Copy and paste the script into the Definition field.
7. Click OK. The method appears in the External Program table.
To apply a Layer 3 health monitor to a real server template

2. On the menu bar, select Template > Server.
3. To edit an existing template, click on the template name. To create a new

template, click Add.
The Server Template tab appears.
4. Select the health monitor from the Health Monitor drop-down list.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
5. Configure other settings if needed. (See “Server and Port Templates” on
page 281.)
6. Click OK.
To apply a health monitor to a real service port template

2. On the menu bar, select Template > Server Port.

The Server Port Template tab appears.
4. Select the health monitor from the Health Monitor drop-down list.
5. Configure other settings if needed. (See “Server and Port Templates” on

page 281.)
6. Click OK.
To apply the monitor to an individual real server or service port

2. On the menu bar, select Server.
3. Select the server or click Add to create a new one.
4. To apply a Layer 3 health monitor to the server, select the health monitor
from the Health Monitor drop-down list on the General tab.
5. To apply a health monitor to a service port:

a. On the Port tab, click the checkbox next to the service port to select
it.
b. Select the health monitor from the Health Monitor drop-down list
on the Port tab.
c. Click Update.
6. Enter or change other settings if needed.
7. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To apply a Layer 3 health monitor to a service group
2. On the menu bar, select Service Group.
3. Select the service group or click Add to create a new one.
4. Select the health monitor from the Health Monitor drop-down list on the
Service Group tab.
5. Enter or change other settings if needed.
6. Click OK.
(For more information about how health monitors are used when applied to
service groups, see “Service Group Health Checks” on page 318.)
USING THE CLI

To configure an internal monitor
1. Use the following command at the global configuration level of the
CLI:
[interval seconds | retry number |
timeout seconds]
If you enter the monitor-name without any of the timer options, the CLI
changes to the configuration level for the monitor. If you enter any of
the timer options, the timer value is changed instead.
2. At the configuration level for the monitor, use the following command
to specify the method to use:
[no] method method-name
The method-name can be one of the types listed in “Health Method
Types” on page 298. Also see that section for additional options you can
specify. For syntax information, see the “Config Commands: SLB
Health Monitors” chapter in the AX Series CLI Reference.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To import an externally configured monitor
1. Create a Tcl script for the monitor. (For an example, see “External
Health Method Examples” on page 331.)
2. At the global configuration level of the AX CLI, use the following com-
mand to import the monitor script:
health external import [description] url
The url specifies the file transfer protocol, username (if required), and
directory path.
tftp://host/program-name
ftp://[user@]host[:port]/program-name
scp://[user@]host/program-name
rcp://[user@]host/program-name
3. Create a new health monitor to use the script by entering the following
command at the global config level:
This command changes the CLI to the configuration level for the new
health monitor.
4. At the configuration level for the monitor, use the following command
to associate the script with the new monitor:
method external [port port-num] program program-
name [arguments argument-string]
For port-num, specify the service port number on the real server.
To apply the health monitor to a real server template or real ser-

vice port template
Use the following command at the configuration level for the server tem-
plate (if applying a monitor that uses the ping method) or at the configura-
tion level for the service port template (for all other method types).
health-check [monitor-name]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To apply the monitor to an individual real server or service port
Use the following command at the configuration level for the server (if
applying a monitor that uses the ping method) or at the configuration level
for the service port (for all other method types).
health-check [monitor-name]
Configuring Health Monitoring of Virtual IP Addresses in DSR

Deployments
Layer 3 and Layer 4-7 health checks are supported on DSR configurations.
The target of the Layer 3 health checks can be the real IP addresses of the
servers, or the virtual IP address, depending on your preference.
• To send the Layer 3 health checks to the real server IP addresses, you
can use the default Layer 3 health method (ICMP).
• To send the Layer 3 health checks to the virtual IP address instead:
• Configure an ICMP health method with the transparent option
enabled, and with the alias address set to the virtual IP address.
• Globally enable DSR health checking.
Layer 4-7 health checks are sent to the same IP address as the Layer 3 health
checks, and then addressed to the specific protocol port. You can use the
default TCP and UDP health monitors or configure new health monitors.
This example uses the default TCP health monitor.
Note: The following sections show how to configure Layer 3 health checking of
virtual IP addresses and how to globally enable DSR health checking of
virtual IP addresses. A complete DSR deployment requires additional
configuration. See the examples in “Network Setup” on page 49.
USING THE GUI
To configure a Layer 3 health method targeted to a virtual IP

address:
3. Click New. The Health Monitor tab appears.
4. Enter a name for the monitor.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
5. Click Method to display the tab.
6. In the Type drop-down list, select ICMP.
7. In the Mode drop-down list, select Transparent.
8. In the Alias Address field, enter the loopback address.
9. Click Apply or OK.
To globally enable DSR health checking of virtual IP addresses:

1. Select Config > Service > Server > Global > Settings.
2. Select Enabled next to DSR Health Check.
3. Click Apply.
USING THE CLI
To configure a Layer 3 health method targeted to a virtual IP

address:
Use the following commands:

[interval seconds | retry number | timeout seconds]
Enter this command at the global Config level of the CLI. The CLI changes
to the configuration level for the health method.
method icmp transparent ipaddr
For ipaddr, enter the virtual IP address.
To globally enable DSR health checking of virtual IP addresses:
Use the following command at the global Config level of the CLI:
slb dsr-health-check-enable
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring POST Requests in HTTP/HTTPS Health Monitors

You can specify a POST operation in an HTTP or HTTPS health monitor. A
POST operation attempts to post data into fields on the requested page.
USING THE GUI

2. Click Add.
3. On the Health Monitor tab, enter a name for the monitor in the Name
field.
4. On the Method tab, select HTTP or HTTPS from the Type drop-down
list. Configuration fields for HTTP or HTTPS health monitoring options
appear.
5. To configure an HTTP POST operation:

a. Next to URL, select POST from the drop-down list.
b. In the field next to the drop-down list, enter the URL path.
c. In the Post Data field, enter the field names and values to be posted.
In the postdata string, use “=” between a field name and the value
you are posting to it. If you post to multiple fields, use “&” between
the fields. For example: fieldname1=value&fieldname1=value
6. Configure other settings as needed.
7. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 109 HTTP Health Monitor with POST Operation
USING THE CLI
To configure an HTTP or HTTPS health monitor, use the following com-

mands:
[no] health monitor monitor-name
[interval seconds]
[retry number]
[timeout seconds]
[up-retry num]
This command creates the health monitor, but does not configure the health
method used by the monitor. If you enter the monitor-name without entering
any other options, the CLI changes to the configuration level for the moni-
tor. If you enter any of the timer options, the timer value is changed instead.
At the configuration level for the health monitor, enter one of the following
commands:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
[no] method http
[port port-num]
[url {GET | HEAD} url-path |
POST url-path postdata string]
[host {ipv4-addr | ipv6-addr | domain-name}
[:port-num]]
[expect {string | response-code code-list}]
[username name]
or
[no] method https
[port port-num]
[url {GET | HEAD} url-path |
POST url-path postdata string]
[host {ipv4-addr | ipv6-addr | domain-name}
[:port-num]]
[expect {string | response-code code-list}]
[username name]
In the postdata string, use “=” between a field name and the value you are
posting to it. If you post to multiple fields, use “&” between the fields. For
example: postdata fieldname1=value&fieldname1=value
CLI Example
The following commands configure an HTTP health method that uses a
POST operation to post firstname=abc and lastname=xyz to /postdata.asp
on the tested server:
AX(config)#health monitor http1
AX(config-health:monitor)#method http url POST /postdata.asp postdata first-
name=abc&lastname=xyz
Customizing DNS Health Monitors

The AX Series provides the following configurable options for DNS health
monitors
• Expected response codes – You can specify a list of response codes, in
the range 0-15, that are valid responses to a health check. If the tested
DNS server responds with any of the expected response codes, the
server passes the health check. By default, the expect list is empty, in
which case the AX device expects status code 0 (No error condition).
• Recursion setting (enabled or disabled) – Recursion specifies whether
the tested DNS server is allowed to send the health check’s request to
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
another DNS server if the tested server can not fulfill the request using
its own database. Recursion is enabled by default.
• Record type expected from the server – You can specify one of the fol-
lowing record types:
• A – IPv4 address record
• CNAME – Canonical name record for a DNS alias
• SOA – Start of authority record
• PTR – Pointer record for a domain name
• MX – Mail Exchanger record
• TXT – Text string
• AAAA – IPv6 address record
By default, the AX device expects the DNS server to respond to the
health check with an A record.
USING THE GUI

2. Click Add.
3. On the Health Monitor tab, enter a name for the monitor in the NAme
field.
4. On the Method tab, select DNS from the Type drop-down list. Configu-
ration fields for DNS health monitoring options appear.
5. If the DNS server to be tested does not listen for DNS traffic on the
default DNS port (53), edit the port number in the Port field.
6. To test a specific server, click IP Address and enter the address in the IP
Address field. Otherwise, to test based on a domain name sent in the
health check, leave Domain selected and enter the domain name in the
Domain field.
7. If you left Domain selected, select the record type the server is expected
to send in reply to health checks. Select the record type from the Type
drop-down list.
8. If you do not want to allows recursion, select Disabled next to Recur-

sion.
9. To specify the response codes that are valid for passing a health check,
enter the codes in the Expect field. To specify a range, use a dash. Sepa-
rate the codes (and code ranges) with commas.
10. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 110 DNS Health Monitor
USING THE CLI
To configure a DNS health monitor, use the following commands:

[interval seconds]
[retry number]
[timeout seconds]
[up-retry num]
This command creates the health monitor, but does not configure the health
method used by the monitor. If you enter the monitor-name without entering
any other options, the CLI changes to the configuration level for the moni-
tor. If you enter any of the timer options, the timer value is changed instead.
At the configuration level for the health monitor, enter the following com-
mand:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
[no] method dns {ipaddr | domain domain-name}
[
expect response-code code-list |
port port-num |
recurse {enabled | disabled} |
type {A | CNAME | SOA | PTR | MX | TXT | AAAA}
]
CLI Example
The following commands configure a DNS health monitor that sends a
query for www.example.com, and expects an Address record and any of the
following response codes in reply: 0, 1, 2, 3, or 5:
AX(config)#health monitor dnshm1
AX(config-health:monitor)#method dns domain www.example.com expect response-
code 0-3,5
Overriding the Target IP Address or Protocol Port Number

The AX device provides options to override the real server IP address or
protocol port number to which health checks are addressed.
By default, the AX device sends a Layer 3 health check to the IP address
used in the real server configuration. Likewise, the AX device sends Layer
4-7 health checks to the real port number in the real server’s configuration.
For GSLB service IPs, the AX device sends the health check to the service
IP address. For example, if the configuration has a Layer 3 health monitor
used by service IPs 192.168.100.100-102, the AX device addresses the
health checks those IP addresses.
You can specify an override IP address or protocol port number in the health
monitor. In this case, the AX device always addresses the health check to
the override address or port. This option is particularly useful for testing the
health of a remote link, as in the following example.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 111 Example of Health-check Address Override
In this example, the real servers managed by the site AX are configured as
service IPs 192.168.100.100-102 on the GSLB AX. The health-check met-
ric is enabled in the GSLB policy, so health checks are needed to verify that
the service IPs are healthy. One way to do so is to check the health of the
ISP link connected to the site AX device.
Because the GSLB AX device is deployed in route mode instead of trans-

parent mode, the transparent option for ICMP health monitors can not be
used to check the remote end of the path. In this case, the health monitor can
be configured with an override IP address, 192.168.1.1, to check the health
of the ISP link to the site where the servers are located. When the AX device
in this example uses the health monitor to check the health of a service IP,
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
the device addresses the health check to 192.168.1.1, the override address,
instead of addressing the health check to the service IP addresses.
Override Parameters
You can independently configure any of the following override parameters

for a health monitor:
• Target IPv4 address
• Target IPv6 address
• Target Layer 4 protocol port number
The override is used only if applicable to the method (health check type)
and the target. An IP address override is applicable only if the target has the
same address type (IPv4 or IPv6) as the override address.
A protocol port override is applicable to all health methods except ICMP. If

the protocol port number is explicitly configured for the method, the over-
ride port number is still used instead.
USING THE GUI

2. Click on the health monitor name or click Add to create a new one.
3. For an ICMP health monitor:

a. Leave ICMP selected in the Type drop-down list.
b. Enter the target IP address of the health monitor, in the Override
IPv4 or Override IPv6 field.
4. For other health methods, select the type, then enter the target protocol
port number in the Override Port field.
5. Click OK. The health monitor list re-appears.
USING THE CLI
Use one of the following commands at the configuration level for the health
monitor:
[no] override-ipv4 ipaddr
[no] override-ipv6 ipv6addr
[no] override-port portnum
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Service Group Health Checks
The following commands configure a health monitor for the service IPs
shown in Figure 111 on page 316, and apply the monitor to the service IPs.
AX(config)#health monitor site1-hm
AX(config-health:monitor)#method icmp
AX(config-health:monitor)#override-ipv4 192.168.1.1
AX(config)#gslb service-ip gslb-srvc1 192.168.100.100
AX(config-gslb service-ip)#health-check site1-hm
AX(config-gslb service-ip)#exit
AX(config-gslb service-ip)#exit

You can assign a health monitor to a service group. This feature is useful in
cases where the same server provides content for multiple, independent
sites. When you use this feature, if a site is unavailable (for example, is
taken down for maintenance), the server will fail the health check for that
site, and clients will not be sent to the site. However, other sites on the same
server will pass their health checks, and clients of those sites will be sent to
the server.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 112 Service Group Health Checks
In this example, a single server provides content for the following sites:
• www.media-rts.com
• www.media-tuv.com
• www.media-wxyz.com
All sites can be reached on HTTP port 80 on the server. The health check
configured on the port in the real server configuration results in the same
health status for all three sites. All of them either are up or are down.
In this case, if one of the sites is taken down for maintenance, the health sta-
tus of that site will still be up, since the real port still responds to the health
check configured on the port.
You can configure the AX device to separately test the health of each site,
by assigning each site to a separate service group, and assigning a separate
Layer 7 health monitor to each of the service groups. In this case, if a site is
taken down for maintenance, that site fails its health check while the other
sites still pass their health checks, on the same real port.
In this example, a separate HTTP health method is configured for each of

the services. The health monitors test the health of a site by sending an
HTTP request to a URL specific to the site. In this way, even though the
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
server’s HTTP port is up, a site will fail its health check if the URL
requested by its health check is unavailable.
Priority of Health Checks
Health checks can be applied to the same resource (real server or port) at the
following levels:
1. In a service group that contains the server and port as a member
2. In a server or server port configuration template that is bound to the

server or port
3. Directly on the individual server or port
In cases where health checks are applied at multiple levels, they have the
priority listed above. For example, if a service group health check is config-
ured, the health of a service is based on that health check, not on a health
check at the server port template or individual port configuration level.
Service group health status applies only within the context of the service
group. For example, a health check of the same port from another service
group can result in a different health status, depending on the resource
requested by the health check.
To assign a health monitor to a service group, use either of the following

methods.
USING THE GUI
On the Service Group configuration tab, select the monitor from the Health
Monitor list or click “create” to create a new one and select it.
USING THE CLI
Use the following command at the configuration level for the service group:
[no] health-check monitor-name
CLI Example
The commands in this section implement the configuration shown in
Figure 112.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the health monitors for each site on the
server:
AX(config)#health monitor qrs
AX(config-health:monitor)#method http url GET /media-qrs/index.html
AX(config)#health monitor tuv
AX(config-health:monitor)#method http url GET /media-tuv/index.html
AX(config)#health monitor wxyz
AX(config-health:monitor)#method http url GET /media-wxyz/index.html
The following commands configure the real server:

AX(config)#slb server media-rs 10.10.10.88

AX(config)#slb service-group qrs tcp
AX(config-slb svc group)#member media-rs:80
AX(config-slb svc group)#health-check qrs
AX(config)#slb service-group tuv tcp
AX(config-slb svc group)#health-check tuv
AX(config)#slb service-group wxyz tcp
AX(config-slb svc group)#health-check wxyz
The following commands configure the virtual servers:

AX(config)#slb virtual-server media-qrs 192.168.1.10
AX(config-slb vserver-vport)#service-group qrs
AX(config)#slb virtual-server media-tuv 192.168.1.11
AX(config-slb vserver-vport)#service-group tuv
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
In-Band Health Monitoring
AX(config)#slb virtual-server media-wxyz 192.168.1.12
AX(config-slb vserver-vport)#service-group wxyz

In-band health checks are an optional supplement to the standard Layer 4
health checks. In-band health checks assess service port health based on cli-
ent-server traffic, and can very quickly send a client’s traffic to another
server and port if necessary. An in-band health check can also mark a port
down.
In the current release, in-band health monitoring is supported for the follow-
ing service types:
• TCP
• HTTP
• HTTPS
Relationship To Standard Layer 4 Health Monitoring
The in-band health check works independently of and supplements the stan-
dard Layer 4 health check. For example, for TCP, the standard health check
works as follows by default:
Every 30 seconds, the AX device sends a connection request (TCP SYN) to

the specified TCP port on the server. The port passes the health check if the
server replies to the AX device by sending a TCP SYN ACK.
This is the same Layer 4 health check available in previous releases and has
the same defaults.
In-band health monitoring works as described below.
Note: A10 Networks recommends that you continue to use standard Layer 4
health monitoring even if you enable in-band health monitoring. Without
standard health monitoring, a server port marked down by an in-band
health check remains down.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
How In-Band Layer 4 Health Monitoring Works
In-band health monitoring for services on TCP watches client-server SYN

handshake traffic, and increments the following counters if the server does
not send a SYN ACK in reply to a SYN:
• Retry counter – Each client-server session has its own retry counter. The
AX device increments a session’s retry counter each time a SYN ACK is
late. If the retry counter exceeds the configured maximum number of
retries allowed, the AX device sends the next SYN for the session to a
different server. The AX device also resets the retry counter to 0.
You can set the retry counter to 0-7 retries. The default is 2 retries.
• Reassign counter – Each real port has its own reassign counter. Each
time the retry counter for any session is exceeded, the AX device incre-
ments the reassign counter for the server port. If the reassign counter
exceeds the configured maximum number of reassignments allowed, the
AX device marks the port DOWN.
In this case, the port remains DOWN until the next time the port suc-
cessfully passes a standard health check. Once the port passes a standard
health check, the AX device starts using the port again and resets the
reassign counter to 0.
You can set the reassign counter to 0-255 reassignments. The default is
25 reassignments.
In-band health monitoring is disabled by default.
Logging and Traps
When the AX device marks a server port down, the device generates a log
message and an SNMP trap, if logging or SNMP traps are enabled. The
message and trap are the same as those generated when a server port fails a
standard health check. However, you can discern whether the port was
marked down due to a failed in-band health check or standard health check,
based on the module name listed in the message.
• A10LB – The port was marked down by an in-band health check.
• A10HM – The port was marked down by a standard health check.
Here is an example of a log message generated from each module:

Sep 08 2008 17:15:04 Info A10LB SLB server s-3-2-1 (10.3.2.1) port 80 is
down.
Sep 08 2008 17:15:04 Info A10HM SLB server s-3-2-1 (10.3.2.1) port 80 is
down.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
In-band health monitoring does not mark ports up. Only standard health
monitoring marks ports up. So messages and traps for server ports coming
up are generated only by the A10HM module.
Configuring In-Band Health Monitoring

To configure in-band health monitoring:
1. Enable the feature in a server port template.
2. Bind the port template to real server ports, either directly or in a service
group.
USING THE GUI

To configure in-band health monitoring in server port template:
2. On the menu bar, select Template > Server Port.
3. Click on the template name or click Add to create a new one.
4. Select Inband Health Check on the Server Port tab.
5. In the Retry field, enter the number of retries allowed.
6. In the Reassign field, enter the number of reassignments allowed.
7. Enter other parameters as needed (for example, the template name, if

you are creating a new template).
8. Click OK.
To bind the template to a server port, see “Binding a Server Port Template to
a Real Server Port” on page 288.
USING THE CLI
To configure in-band health monitoring, use the following command at the

configuration level for the server port template:
[no] inband-health-check
[retry maximum-retries]
[reassign maximum-reassigns]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Consecutive Health Checks Within a Health Check Period
CLI Example
The following commands enable in-band health monitoring in a server port

template and bind the template to real ports on two real servers:
AX(config)#slb template port rp-tmplt2
AX(config-rport)#inband-health-check
AX(config-rport)#exit
AX(config-real server-node port)#template port rp-tmplt2
AX(config-real server-node port)#template port rp-tmplt2
Consecutive Health Checks Within a Health Check

Period
You can configure the number of times the target device must consecutively
reply to the same periodic health check in order to pass the health check.
By default, a server or port needs to successfully reply to a given health

check only one time in order to pass the health check. The server or port is
then considered to be up until the next periodic health check. You can set
the required number of consecutive passes to 1-10.
You can configure this parameter on an individual health monitor basis. The
setting applies to all health checks that are performed using the health mon-
itor.
USING THE GUI

3. Click on the monitor name or click Add to add a new one.
4. On the Health Monitor tab, enter a name for the monitor (if new).
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
On-Demand Health Checks
5. In the Consec Pass Req’d field, enter the number of consecutive times
the target must pass the same periodic health check.
6. If new, on the Method tab, select the monitor type from the Type drop-
down list, and enter or select settings for the monitor.
7. Click OK.
USING THE CLI
Use the up-retry number option with the health-monitor command.
On-Demand Health Checks

You can easily test the health of a server or individual service at any time,
using the default Layer 3 health monitor (ICMP ping) or a configured health
monitor.
USING THE GUI

1. Select Monitor > Service > Health Monitor.
2. Enter the IP address of the server to be tested in the IP Address field.
3. Select the health monitor to use from the Health Monitor drop-down list.
4. To test a specific service, enter the protocol port number for the service
in the Port field.
5. Click Start.
The status of the server or service appears in the Status message area.
Note: If an override IP address and protocol port are set in the health monitor
configuration, the AX device will use the override address and port, even
if you specify an address and port when you send the on-demand health
check.
USING THE CLI
To test the health of a server, use the following command at the EXEC,
Privileged EXEC, or global configuration level of the CLI:
health-test {ipaddr | ipv6 ipv6addr} [count num]
[monitorname monitor-name] [port portnum]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Displaying Health Status
The ipaddr | ipv6 ipv6addr option specifies the IPv4 or IPv6 address of the
device to test.
The count num option specifies the number of health checks to send to the
device. You can specify 1-65535. The default is 1.
The monitorname monitor-name option specifies the health monitor to use.
The health monitor must already be configured. By default, the default
Layer 3 health check (ICMP ping) is used.
The port portnum option specifies the protocol port to test, 1-65535. By
default, the protocol port number specified in the health monitor configura-
tion is used.
Note: If an override IP address and protocol port are set in the health monitor
configuration, the AX device will use the override address and port, even
if you specify an address and port when you send the on-demand health
check.
CLI Example
The following command tests port 80 on server 192.168.1.66, using config-
ured health monitor hm80:
AX#health-test 192.168.1.66 monitorname hm80
node status UP.

The AX device begins sending health checks to a real server’s IP address
and service ports as soon as you finish configuring the server. You can dis-
play health status for virtual servers and service ports, and for the real serv-
ers and service ports used by the virtual server.
To display health status, use either of the following methods.
USING THE GUI
To display the health of virtual servers and service ports:

1. Select Monitor > Overview > Status.
The virtual servers are listed at the top of the page. The state of health of
each virtual server is shown by an icon next to the virtual server name.
2. To display more specific health information for a virtual server’s service

ports, click on the virtual server name.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Virtual server health status is also displayed in the virtual server list dis-
played by Config > Service > SLB > Virtual Server.
For information about the virtual server health state icons, see the
“Monitor > Overview > Status” section in the “Monitor Mode” chapter of
the AX Series GUI Reference.
To display the health of real servers and service ports:

1. Select Monitor > Service > Server.
2. On the menu bar, select Server.

The state of health of each real server is shown by an icon next to the
server name.
3. To display more specific health information for a real server’s service

ports, click on the server name.
Real server health status is also displayed in the real server list displayed by
Config > Service > SLB > Server.
For information about the real server health state icons, see the
“Monitor > Service > Server” section in the “Monitor Mode” chapter of the
AX Series GUI Reference.
USING THE CLI
To display the health of virtual servers and service ports:
Use the following command. The health is shown in the State field. For
descriptions of each health state, see the AX Series CLI Reference.
show slb virtual-server virtual-server-name

[virtual-port-num service-type [group-name]]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Here is an example:
AX#show slb virtual-server "vs 1"
Virtual server: vs 1 State: Down IP: 1.1.1.201
Pri Port/State Curr-conn Total-conn Rx-Pkt Tx-Pkt
------------------------------------------------------------------------
Virtual Port:80 / service:svcgrp 1 / state:Down

port 80 tcp
1 server 1:80/Down 0 0 0 0
Virtual Port:1 / service: / state:Unkn

port 1 tcp
Persist Source IP:tmpl persist srcip 1

port 2 tcp
Persist SSL session ID:tmpl persist sslid 1

port 3 tcp
Template tcp tmpl tcp 1

...
To display the health of real servers and service ports:
Use the following command. The health is shown in the State field. For
descriptions of each health state, see the AX Series CLI Reference.
show slb server [server-name [port-num]]
D e s i g n 329 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Here is an example:
AX#show slb server
Total Number of Services configured: 5
Current = Current Connections, Total = Total Connections
Req-pkt = Request packets, Resp-pkt = Response packets
Service Current Total Req-pkt Resp-pkt State
------------------------------------------------------------------------------
s1:80/tcp 0 0 0 0 Down
s1:53/udp 0 0 0 0 Down
s1:85/udp 0 0 0 0 Down
s1: Total 0 0 0 0 Down
...
To display health monitoring statistics:
Use the following command:
show health stat
Here is an example:
AX#show health stat
Health monitor statistics
Total run time: : 2 hours 1345 seconds
Number of burst: : 0
Number of timer adjustment: : 0
Timer offset: : 0
Opened socket: : 1140
Open socket failed: : 0
Close socket: : 1136
Send packet: : 0
Send packet failed: : 259379
Receive packet: : 0
Receive packet failed : 0
Retry times: : 4270
Timeout: : 0
Unexpected error: : 0
IP address Port Health monitor Status Cause(Up/Down/Retry) PIN

--------------------------------------------------------------------------------
10.10.10.99 default Down 0 /48 /854 2 /0
4.4.4.4 default Down 0 /48 /854 2 /0
8.4.3.2 default Down 0 /48 /854 2 /0
99.99.99.99 default Down 0 /48 /854 2 /0
10.10.10.88 default Down 0 /48 /854 2 /0
10.10.10.88 80 qrs Down 0 /34 /0 2 /0
For more information, see the AX Series CLI Reference.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
External Health Method Examples

Besides internal health checks, which use a predefined health check
method, you can use external health checks with scripts. The following
types of scripts are supported:
• Perl
• Shell
• Tcl
Utility commands such as ping, ping6, wget, dig, and so on are supported.
TCL Script Example

For Tcl scripts, the health check parameters are transmitted to the script
through the predefined TCL array ax_env. The array variable ax_env(Serv-
erHost) is the server IP address and ax_env(ServerPort) is the server port
number. Set ax_env(Result) 0 as pass and set the others as fail. TCL script
filenames must use the “.tcl” extension.
To use the external method, you must import the program onto the
AX Series device. The script execution result indicates the server status,
which must be stored in ax_env(Result).
The following commands import external program “ext.tcl” from FTP

server 192.168.0.1, and configure external health method “hm3” to use the
imported program to check the health of port 80 on the real server:
AX(config)#health external import "checking HTTP server" ftp://192.168.0.1/
ext.tcl
AX(config)#health monitor hm3
AX(config-health:monitor)#method external port 80 program ext.tcl
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Here is the ext.tcl file:
# Init server status to "DOWN"
set ax_env(Result) 1
# Open a socket
if {[catch {socket $ax_env(ServerHost) $ax_env(ServerPort)} sock]} {
puts stderr "$ax_env(ServerHost): $sock"
} else {
fconfigure $sock -buffering none -eofchar {}
# Send the request

puts $sock "GET /1.html HTTP/1.0\n"
# Wait for the response from http server

set line [read $sock]
if { [ regexp "HTTP/1.. (\[0-9\]+) " $line match status] } {

puts "server $ax_env(ServerHost) response : $status"
# Check exit code

if { $status == 200 } {
# Set server to be "UP"
set ax_env(Result) 0
}
}
close $sock
}
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Perl Script Example

For other external scripts (non-Tcl), environment variables are used to pass
the server IP address (HM_SRV_IPADDR) and the port number
(HM_SRV_PORT). The script returns 0 as pass and returns others as fail.
For Perl scripts, use #! /usr/bin/perl at the beginning of the script.
Here is an example using the Perl scripting language:

#!/usr/bin/perl -w
# Sample script for checking Web server
my $host = $ENV{'HM_SRV_IPADDR'};
my $port = 80;
if (defined($ENV{'HM_SRV_PORT'})) {
$port = $ENV{'HM_SRV_PORT'};
}
# Use wget, exit code is zero if wget was successful.

my @args = qw(-O /dev/null -o /dev/null);
exec "wget", "http://$host:$port", @args;
# vim: tw=78:sw=3:tabstop=3:autoindent:expandtab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Shell Script Example

For Shell scripts, use #! /bin/bash at the beginning of the script.
Here is an example using the Shell scripting language:

#! /bin/bash
if test "$HM_SRV_IPADDR" == "" ; then
echo "Please check ENV Var 'HM_SRV_IPADDR'"
exit 1
fi
echo -n "Test $HM_SRV_IPADDR ...."

wget $HM_SRV_IPADDR --delete-after --timeout=2 --tries=1 > /dev/null 2>&1
ret=$?
if test $ret == 0 ; then
echo "OK"
exit 0
else
echo "Fail"
exit 1
fi
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
This chapter describes Global Server Load Balancing (GSLB). GSLB pro-
vides SLB service across multiple sites.
Overview
Global Server Load Balancing (GSLB) extends load balancing to global
geographic scale. AX Series GSLB uses the DNS proxy method to add
intelligence to DNS. GSLB evaluates the server IP addresses in DNS replies
and changes the order of the addresses in the replies so that the best avail-
able host IP address is the preferred choice.
AX Series GSLB provides the following key advantages:
• Protects businesses from down time due to site failures
• Ensures business continuity and applications availability
• Provides faster performance and improved user experience by directing

users to the nearest site
• Increases data center efficiency and better return on investment by dis-
tributing load to multiple sites
• Provides flexible policies for selecting fairness and distribution to multi-
ple sites
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Figure 113 shows an example of a GSLB configuration.
FIGURE 113 GSLB Example
In this example, the GSLB AX device (the GSLB controller) globally load
balances client requests for “www.a10.com”.
The a10.com services reside on real servers at two sites. At each site, an AX
device provides SLB for the real servers. On the GSLB AX device, the sites
are grouped into a zone for the service.
When a client sends a DNS lookup request for the IP address of

“www.a10.com”, the GSLB AX device intercepts the request and sends the
same request to the DNS server on behalf of the client.
When the GSLB AX device receives the DNS reply, the device re-orders the
IP addresses in the reply based on the results of site evaluation using the
configured GSLB metrics. The GSLB AX device also makes other changes
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
to the DNS reply, such as shortening the TTL of the IP Address records, if
specified by the GSLB configuration. The GSLB AX device then sends the
modified DNS reply to the client.
When the client receives the DNS reply, the client then sends the HTTP
request to the IP address that the GSLB AX device placed at the top of the
IP address list in the DNS reply.
Note: Here and elsewhere in A10 Networks user documentation, the IP

addresses shown in figures and configuration examples are for illustration
purposes only. When you configure a feature for your network, you will
need to use the IP addresses that apply to your network.
Note: An AX device becomes a GSLB AX device when you configure GSLB

on the device and enable the GSLB protocol, for the controller function.
The A10 Networks GSLB protocol uses port 4149. The protocol is regis-
tered on this port for both TCP and UDP.
Advantages of GSLB
In standard DNS, when a client wants to connect to a host and has the host-
name but not the IP address, the client sends a lookup request to its local
DNS server. The local DNS server checks its local database.
• If the database contains an Address record for the requested host name,
the DNS server sends the IP address for the host name back to the client.
The client can then access the host.
• If the local DNS server does not have an Address record for the
requested server, the local DNS server makes recursive queries to the
root and intermediate DNS servers, which results in authoritative DNS
server addresses. When a request reaches an authoritative DNS server,
that DNS server sends a reply to the DNS query. The client’s local DNS
server then sends the reply to the client. The client now can access the
requested host.
In today’s redundant data centers and multiple service provider sites, a host
name can reside at multiple data centers or sites, with different IP addresses.
When this is the case, the authoritative DNS server for the host sends multi-
ple IP addresses in its replies to DNS queries. Standard DNS servers can
provide only rudimentary load sharing for the addresses, using a simple
round-robin algorithm to rotate the list of addresses for each query. Thus,
the address that is listed first in the last reply sent by the DNS server is
rotated to be the last address listed in the next reply, and so on.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Zones, Services, and Sites

GSLB operates on zones, services, and sites.
• Zones – A zone is a GSLB domain. An AX device can be configured
with one or more GSLB zones. Each zone can contain one or more
GSLB sites.
• Services – A service is an application; for example, HTTP or FTP. Each
zone can be configured with one or more services.
• Sites – A site is a server farm that is locally managed by an AX device
that performs Server Load Balancing (SLB) for the site.
GSLB Policy
GSLB evaluates the service IP addresses listed in replies from DNS servers
to clients, re-orders the addresses based on that evaluation, and sends the
DNS replies to clients with the re-ordered IP address lists. As a result of this
process, each client receives a DNS reply that has the best service IP
address listed first.
GSLB selects the best site IP address using a GSLB policy. A GSLB policy
consists of one or more of the following metrics:
1. health-check – Services that pass health checks are preferred.
2. weighted-ip – Service IP addresses with higher administratively
assigned weights are used more often than service IP addresses with
lower weights. (See “Weighted-IP and Weighted-Site” on page 339.)
3. weighted-site – Sites with higher administratively assigned weights are
preferred. Sites with higher administratively assigned weights are used
more often than sites with lower weights. (See “Weighted-IP and
Weighted-Site” on page 339.)
4. session capacity – Sites with more available sessions based on respec-
tive maximum session capacity are preferred.
5. active-servers – Sites with the most currently active servers are pre-
ferred.
6. active-rtt – Sites with faster round-trip-times for DNS queries and
replies between a site AX device and the GSLB local DNS are pre-
ferred.
7. passive-rtt – Services with faster response times to clients are preferred.
8. geographic – Services located within the client’s geographic region are
preferred.
9. connection-load – Sites that are not exceeding their thresholds for new
connections are preferred.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
10. num-session – Sites that are not exceeding available session capacity
threshold compared to other sites are treated as having the same prefer-
ence.
11. admin-preference – The site with the highest administratively set prefer-
ence is selected.
12. bw-cost – Selects sites based on bandwidth utilization on the site AX
links.
13. least-response – Service IP addresses with the fewest hits are preferred.
14. ordered-ip – Service IP addresses are administratively prioritized. The
prioritized list is sent to the next metric for further evaluation. If
ordered-ip is the last metric, the prioritized list is sent to the client. (See
“Ordered-IP” on page 340.)
15. round-robin – Sites are selected in sequential order. (See “Tie-Breaker”
on page 340.)
The health-check, geographic, and round-robin metrics are enabled by

default. All other metrics are disabled by default.
The GSLB AX device uses each enabled GSLB metric to select or eliminate
service IP addresses, then passes the subset of addresses that pass the met-
ric’s criteria to the next metric, and so on, to sort (re-order) the list of
addresses. The GSLB AX device then replaces the IP address list in the
DNS reply with the re-ordered list before sending the reply to the client.
The metric order and the configuration of each metric are specified in a
GSLB policy. Policies can be applied to GSLB zones and to individual ser-
vices. The GSLB AX device has a default GSLB policy, named “default”,
that is automatically applied to a zone or service, unless you configure and
assign a different policy to the zone or service.
Weighted-IP and Weighted-Site

The weighted-ip and weighted-site metrics allow you to bias selection
toward specific sites or IP addresses. GSLB selects higher-weighted sites or
IP addresses more often than lower-weighted sites or IP addresses.
For example, if there are two sites (A and B), and A has weight 2 whereas B
has weight 4, GSLB will select site B twice as often as site A. Specifically,
GSLB will select site B the first 4 times, and will then select site A the next
2 times. This cycle then repeats: B is chosen 4 times, then A is chosen the
next 2 times, then B is chosen the next 4 times, and so on.
Note: If DNS caching is used, the cycle starts over if the cache aging timer
expires.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Ordered-IP
Most metrics select a site or IP address as the best address. However, the
ordered-ip metric does not select or eliminate sites or IP addresses. Instead,
the ordered-ip metric re-orders the IP addresses based on the metric’s con-
figuration in the GSLB policy.
If there are any more metrics after ordered-ip, the re-ordered list is sent to
the next metric.
If you plan to use the ordered-ip metric, you need to disable the round-robin
metric. Otherwise, round-robin will be used as the tie-breaker and the
ordered IP list will be ignored.
Tie-Breaker
If all the enabled metrics in the policy result in a tie (do not definitively
select a single site as the best site), the AX device uses round-robin to select
a site. This is true even if the round-robin metric is disabled in the GSLB
policy.
Note: If the last metric is ordered-ip, and round-robin is disabled, the prioritized
list of IP addresses is sent to the client. Round-robin is not used.
Health Checks
The health-check metric checks the availability (health) of the real servers
and service ports. Sites whose real servers and service ports respond to the
health checks are preferred over sites in which servers or service ports are
unresponsive to the health checks.
GSLB supports health check methods for the following services:
ICMP (Layer 3 health check), TCP, UDP, HTTP, HTTPS, FTP, SMTP,
POP3, SNMP, DNS, RADIUS, LDAP, RTSP, SIP
You can use the default health methods or configure new methods for any of
these services.
Note: The default health monitor for a service is the default Layer 3 health mon-
itor (ICMP ping). The default health monitor for a service port is the
default TCP or UDP monitor, depending on the transport protocol.
If you leave the health monitor for a service left at its default setting (the
default ICMP ping health check), the health checks are performed within
the GSLB protocol. This requires the GSLB protocol to be enabled on the
site AX devices as well as the GSLB controller.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
If you use a custom health monitor, or you explicitly apply the default
Layer 3 health monitor to the service, the GSLB protocol is not used for
any of the health checks. In this case, the GSLB protocol is not required to
be enabled on the site AX devices, although use of the protocol is still rec-
ommended.
If you use a custom health monitor for a service port, the port number
specified in the service configuration is used instead of the port number
specified in the health monitor configuration.
(For more information about health monitoring, see “Health Monitoring” on

page 297.)
Geo-Location
You can configure GSLB to prefer site VIPs for DNS replies that are geo-
graphically closer to the clients. For example, if a domain is served by sites
in both the USA and Asia, you can configure GSLB to favor the USA site
for USA clients while preferring the Asian site for Asian clients.
To configure geo-location:
• Leave the geographic GSLB metric enabled.
• Load geo-location data. You can load geo-location data from a file or
manually configure individual geo-location mappings.
Loading geo-location data from a file is simpler than manually configuring

geo-location mappings, especially if you have more than a few GSLB sites.
For more information, see “Loading or Configuring Geo-Location Map-
pings” on page 363.
CNAME Support
As an extension to geo-location support, you can configure GSLB to send a
Canonical Name (CNAME) record instead of an Address record in DNS
replies to clients. A CNAME record maps a domain name to an alias for that
domain. For example, you can configure aliases such as the following for
domain “a10.com”, and associate the aliases with different geo-locations:
• www.a10.co.cn
• www.1.a10.com
• ftp.a10.com
If a client’s IP address is within a geo-location associated with

www.1.a10.com, GSLB places a CNAME record for www.1.a10.com in the
DNS reply to the client.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
To configure CNAME support:
• Configure geo-location as described above.
• In the GSLB policy, enable the following DNS options:

• dns cname-detect (enabled by default)
• dns geoloc-alias
• For individual services in the zone, configure the aliases and associate
them with geo-locations.
DNS Options
DNS options provide additional control over the IP addresses listed in DNS
replies to clients. After the GSLB AX device uses the metrics to select and
prioritize the IP addresses for the DNS reply, the AX device applies the
enabled DNS options to the list.
The following DNS options can be set in GSLB policies:

• dns action – Enable GSLB to perform DNS actions specified in the serv-
ice configurations.
• dns active-only – Removes IP addresses for services that did not pass
their health checks.
• dns addition-mx – Appends MX records in the Additional section in
replies for A records, when the device is configured for DNS proxy or
cache mode.
• dns best-only – Removes all IP addresses from DNS replies except for
the address selected as the best address by the GSLB policy metrics.
• dns cache – Caches DNS replies and uses them when replying to clients,
instead of sending a new DNS request for every client query.
• dns cname-detect – For IP addresses that have Canonical Name
(CNAME) records, applies the GSLB policy to the CNAME record
instead of the Address record. (This applies only if the CNAME records
are for the zone and application requested by the DNS proxy on the
GSLB AX device.)
• dns external-ip – Returns the external IP address configured for a ser-
vice IP. If this option is disabled, the internal address is returned instead.
• dns geoloc-action – Performs the DNS traffic handling action specified
for the client’s geo-location. The action is specified as part of service
configuration in a zone.
• dns geoloc-alias – Replaces the IP address with its alias configured on
the GSLB AX Series.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
• dns geoloc-policy – Returns the alias name configured for the client’s
geo-location.
• dns ip-replace – Replaces the IP addresses with the set of addresses
administratively assigned to the service in the zone configuration.
• dns server – Enables the GSLB AX device to act as a DNS server, for
specific service IPs in the GSLB zone.
• dns sticky – Sends the same service IP address to a client for all requests
from that client for the service address.
• dns ttl – Overrides the TTL set in the DNS reply. (For more information
about this option, see “TTL Override” on page 343.)
The cname-detect and external-ip options are enabled by default. All the
other DNS options are disabled by default.
Order in Which Sticky, Server, Cache, and Proxy Options Are

Used
If more than one of the following options are enabled, GSLB uses them in
the order listed, beginning with sticky:
1. sticky
2. server
3. cache
4. proxy
Note: GSLB does not have a separately configurable “proxy” option. The proxy
option is automatically enabled when you configure the DNS proxy as
part of GSLB configuration.
The site address selected by the first option that is applicable to the client
and requested service is used.
TTL Override
GSLB ensures that DNS replies to clients contain the optimal set of IP
addresses based on current network conditions. However, if the DNS TTL
value assigned to the Address records is long, the local DNS servers used by
clients might cache the replies for a long time, and send those stale replies to
clients. Thus, even though the GSLB AX device has current information,
clients might receive outdated information.
To ensure that the clients’ local DNS servers do not cache the DNS replies
for too long, you can configure the GSLB AX device to override the TTL
values of the Address records in the DNS replies before sending the replies
to clients.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
The TTL of the DNS reply can be overridden in two different places in the
GSLB configuration:
1. If a GSLB policy is assigned to the individual service, the TTL set in
that policy is used.
2. If no policy is assigned to the individual service, but the TTL is set in

the zone, then the zone’s TTL setting is used.
By default, the TTL override is not set in either of these places.
Metrics That Require the GSLB Protocol on Site AX Devices
AX devices use the GSLB protocol for GSLB management traffic. The pro-
tocol is required to be enabled on the GSLB controller. The protocol is rec-
ommended on site AX devices but is not required. However, some GSLB
policy metrics require the protocol to be enabled on the site AX devices as
well as the GSLB controller:
• session-capacity
• active-rtt
• passive-rtt
• connection-load
• num-session
• least-response
The GSLB protocol is required in order to collect the site information pro-
vided for these metrics.
Note: The GSLB protocol is also required for the health-check metric, if the
default health checks are used. If you modify the health checks, the GSLB
protocol is not required. (See “Health Checks” on page 340.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration Overview
Configuration is required on the GSLB AX device (GSLB controller) and
the site AX devices.
Configuration on GSLB Controller
Configuration is required on the GSLB AX device and the site AX devices.

To configure GSLB on the GSLB AX device:
1. Configure health monitors for the DNS server to be proxied and for the
GSLB services to be load balanced.
2. Configure a DNS proxy.
3. Configure a GSLB policy (unless you plan to use the default policy set-
tings, described in “GSLB Policy” on page 338).
4. Configure services.
5. Configure sites.
6. Configure a zone.
7. Enable the GSLB protocol for the GSLB controller function.
Note: If you plan to run GSLB in server mode, the proxy DNS server does not
require configuration of a real server or service group. Only the VIP is
required. However, if you plan to run GSLB in proxy mode, the real
server and service group are required along with the VIP. (Server and
proxy mode are configured as DNS options. See “DNS Options” on
page 342.)
Configuration on Site AX Device
To configure GSLB on the site AX devices:

1. Configure SLB, if not already configured.
2. Enable the GSLB protocol for the GSLB site device function.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration takes place at the following levels:
Global (system-wide on the GSLB AX device)
Zone
Service IP
Site
SLB device
The parameters you can configure at each level are described in “GSLB
Parameters” on page 378.
The following sections describe the GSLB configuration steps in the GUI
and in the CLI. Required commands and commonly used options are listed.
For advanced commands and options, see “GSLB Parameters” on page 378.
Note: Each of the following configuration sections shows the CLI and GUI
methods for configuration. For complete configuration examples, see
“Configuration Examples” on page 397.
Configure Health Monitors

A10 Networks recommends that you configure health monitors for the local
DNS server to be proxied, and also for the GSLB services to be load bal-
anced.
Use a DNS health monitor for the local DNS server. You also can use a
Layer 3 health monitor to check the IP reachability of the server.
For the GSLB service, use health monitors for the application types of the
services. For example, for an HTTP service, use an HTTP health monitor. If
the health-check metric is enabled in the GSLB policy, the metric will use
the results of service health checks to select sites.
To monitor the health of the real servers providing the services, configure
health monitors on the site SLB devices.
Configure the health monitors for the proxied DNS server and the GSLB
services on the GSLB AX device. Configure the health monitors for real
servers and their services on the site AX devices.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration of health monitors is the same as for standard SLB. There are
no special health monitoring options or requirements for GSLB. For config-
uration information, see “Health Monitoring” on page 257.
Configure the DNS Proxy

The DNS proxy is a DNS virtual service, and its configuration is therefore
similar to the configuration of an SLB service.
To configure the GSLB DNS proxy, use either of the following methods.
USING THE GUI

1. Select Config > Service > GSLB.
2. Click DNS Proxy, then click Add.
3. Enter a name for the DNS proxy.
4. Enter the IP address that will be advertised as the authoritative DNS

server for the GSLB zone.
Note: The GUI will not accept the configuration if the IP address you enter here
is the same as the real DNS server IP address you enter when configuring
the service group for this proxy (below).
5. (Optional) To add this proxy configuration of the DNS server to a High

Availability (HA) group, select the group.
6. On the GSLB Port tab, click Add.
7. In the Port field, enter the DNS port number, if not already filled in.
8. In the Service Group field, select “create”. The Service Group and
Server tabs appear.
9. In the Name field, enter a name for the service group.
10. In the Type drop-down list, select UDP.
11. On the Server tab, in the Server drop-down list, enter the IP address of
the DNS server. Enter the real IP address of the DNS server, not the IP
address you are assigning to the DNS proxy.
12. Enter the DNS port number in the Port field and click Add. The server
information appears on the tab.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
13. Click OK. The GSLB Port tab re-appears.
14. Click OK. The Proxy tab re-appears.
15. Click OK. The DNS proxy appears in the DNS proxy table.
USING THE CLI

1. To configure a real server for the DNS server to be proxied, use the fol-
lowing commands:
Use this command at the global configuration level of the CLI. The
command creates the proxy and changes the CLI to the configuration
level for it.
To configure the DNS port on the server, use the following command to
change the CLI to the configuration level for the port:
port port-num udp
To enable health monitoring of the DNS service, use the following com-
mand:
(Layer 3 health monitoring using the default Layer 3 health monitor is
already enabled by default.)
2. To configure a service group and add the DNS proxy (real server) to it,
slb service-group group-name udp
command creates the service group and changes the CLI to the configu-
ration level for it. To add the DNS server to the service group, use the
following command:
member server-name:port-num
3. To configure a virtual server for the DNS proxy and bind it to the real
server and service group, use the following commands:
command creates the virtual server changes the CLI to the configuration
level for it. To add the DNS port, use the following command:
port port-number udp
This command changes the CLI to the configuration level for the DNS
port. To bind the DNS port to the DNS proxy service group and enable
GSLB on the port, use the following commands:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
gslb-enable
Configure a GSLB Policy

The GSLB policy contains the metrics used to evaluate each site and select
the best site for a client request.
Configuring a GSLB policy is optional. By default, the “default” policy is

used unless you configure and apply a different policy.
In the “default” GSLB policy, the following metrics are enabled by default:
• health-check
• geographic
• round-robin
The other metrics are disabled. (For detailed information about policy
parameters and their defaults, see “GSLB Parameters” on page 378.)
Note: Although the geographic metric is enabled by default, there are no default
geo-location mappings. To use the geographic metric, you must load or
manually configure geo-location mappings. (See “Loading or Configur-
ing Geo-Location Mappings” on page 363 later in this section.)
Enabling / Disabling Metrics
To enable or disable a metric, use either of the following methods.
Using the GUI

2. On the menu bar, select Policy.
3. Click on the policy name or click Add to create a new policy.
4. If you are configuring a new policy, enter a name in the Name field on
the General tab.
5. On the Metrics tab, drag-and-drop the metric from one column to the
other. For example, to disable the health-check metric, drag-and-drop it
from the In Use column to the Not In Use column.
If you are enabling a metric, drag it to the position you want it to be used
in the processing order. For example, if you are enabling the Admin
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Preference metric and you want this metric to be used first, drag-and-
drop the metric to the top of the In Use column.
6. On the DNS Options tab, configure the DNS options, if applicable to

your deployment. (For descriptions, see “DNS Options” on page 342
and Table 9, “GSLB Policy Parameters,” on page 387.)
7. Click OK.
Using the CLI
To enable a metric, enter the metric name at the configuration level for the
policy. For example, to enable the admin-preference metric, enter the fol-
lowing command:
AX(config gslb-policy)#admin-preference
To disable a GSLB metric, use the “no” form of the command for the met-
ric, at the configuration level for the policy. For example, to disable the
health-check metric, enter the following command at the configuration level
for the policy:
AX(config gslb-policy)#no health-check
To set DNS options, use the following command at the configuration level
for the policy. (For descriptions, see “DNS Options” on page 342 and
Table 9, “GSLB Policy Parameters,” on page 387.)
[no] dns
{
action |
active-only |
addition-mx |
best-only |
cache [aging-time {seconds | ttl}] |
cname-detect |
external-ip |
geoloc-action |
geoloc-alias |
geoloc-policy |
ip-replace |
server [authoritative] |
sticky [/prefix-length] [aging-time minutes] |
ttl num
}
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Changing the Metric Order
To change the metric order, use either of the following methods.
Using the GUI

3. Click on the policy name or click Add to create a new policy.
4. If you are configuring a new policy, enter a name in the Name field on
the General tab.
5. On the Parameters tab, drag-and-drop the metric to the position in which

you want it to be used in the processing order. For example, if you want
the admin-preference metric to be used first, drop the metric to the top
of the In Use column.
6. Click OK.
Using the CLI
To change the positions of metrics in a GSLB policy, use the following

command at the configuration level for the policy:
[no] metric-order metric [metric ...]
The metric option specifies a metric and can be one of the following:
• active-rtt
• active-servers
• admin-preference
• bw-cost
• capacity
• connection-load
• geographic
• health-check
• least-response
• num-session
• ordered-ip
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• passive-rtt
• weighted-ip
• weighted-site
Configuring RTT Settings
If you are planning to use the active-RTT or passive-RTT metric, read this
section. Otherwise, you can skip the section. Both these metrics are disabled
by default.
Active RTT
Active RTT measures the round-trip-time for a DNS query and reply
between a site AX device and the GSLB local DNS.
The active RTT metric is disabled by default. You can enable it to take
either a single sample (single shot) or multiple samples at regular intervals.
You can configure active RTT to take a single sample or periodic samples.
Default Settings
When you enable Active RTT, a site AX device sends 5 DNS requests to the
GSLB domain’s local DNS. The GSLB AX device averages the RTT times
of the 5 samples.
Single Sample (Single Shot)

To take a single sample and use that sample indefinitely, use the single-shot
option. This option instructs each site AX device to send a single DNS
query to the GSLB local DNS.
The single-shot option is useful if you do not want to frequently update the
active RTT measurements. For example, if the GSLB domain's clients tend
to remain logged on for long periods of time, using the single-shot option
ensures that clients are not frequently sent to differing sites based on active
RTT measurements.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The single-shot has the following additional options:
• timeout – Specifies the number of seconds each site AX device should
wait for the DNS reply. If the reply does not arrive within the specified
timeout, the site becomes ineligible for selection, in cases where selec-
tion is based on the active RTT metric. You can specify 1-255 seconds.
The default is 3 seconds.
• skip – Specifies the number of site AX devices that can exceed their sin-
gle-shot timeouts, without the active RTT metric itself being skipped by
the GSLB AX device during site selection. You can skip from 1-31 sites.
The default is 3.
Multiple Samples
To periodically retake active RTT samples, do not use the single-shot
option. In this case, the AX device uses the averaged RTT based on the
number of samples measured for the intervals.
For example, if you set active RTT to use 3 samples with an interval of 5
seconds, the RTT is the average RTT for the last 3 samples, collected in 5-
second intervals. If you configure single-shot instead, a single sample is
taken.
The number of samples can be 1-8. The default is 5 samples.
Store-By
By default, the GSLB AX device stores one active RTT measurement per
site SLB device. Optionally, you can configure the GSLB AX device to
store one measurement per geo-location instead. This option is configurable
on individual GSLB sites. (See “Changing Active RTT Settings for a Site”
on page 355.)
Tolerance
The default measurement tolerance is 10 percent. If the RTT measurements
for more than one site are within 10 percent, the GSLB AX device considers
the sites to be equal in terms of active RTT. You can adjust the tolerance to
any value from 0-100 percent.
Enabling Active RTT

To enable active RTT, use either of the following methods.
USING THE GUI

Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. Click on the policy name or click Add to create a new one.
4. Drag-and-drop Active RTT from the Not In Use column to the In Use
column.
5. Click the plus sign to display the Active RTT configuration fields.
6. To use single-shot RTT, select the Single-shot checkbox. To collect mul-

tiple samples, do not select the Single-shot checkbox.
7. To change settings for single-shot, edit the values in the Timeout and
Skip fields.
8. To change settings for multiple samples, edit the values in the Samples
and Tolerance fields.
9. Click OK.
USING THE CLI

Enter the following command at the configuration level for the GSLB pol-
icy:
[no] active-rtt
[samples num-samples]
[single-shot] [skip count]
[timeout seconds]
[tolerance num-percentage]
If you omit all the options, the site AX device send 5 DNS requests to the
GSLB domain’s local DNS. The GSLB AX device averages the RTT times
of the 5 samples. The active RTT measurements are regularly updated. You
can use the samples option to change the number of samples to 1-8.
To enable single-shot RTT instead, use the single-shot option. For singe-
shot, you also can use the skip and timeout options. (See the descriptions
above, in “Single Sample (Single Shot)” on page 352)
For descriptions of the store-by and tolerance options, see “Store-By” on
page 353 and “Tolerance” on page 353.
CLI Examples
The following commands access the configuration level for GSLB policy
“gslbp2” and enable the active RTT metric, using all the default settings:
AX(config)#gslb policy gslbp2
AX(config gslb-policy)#active-rtt
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands access the configuration level for GSLB policy
“gslbp3” and enable the active RTT metric, using single-shot settings:
AX(config)#gslb policy gslbp3
AX(config gslb-policy)#active-rtt single-shot
AX(config gslb-policy)#active-rtt skip 3
In this example, each site AX device will send a single DNS query to the
GSLB domain’s local DNS, and wait 3 seconds (the default) for a reply. The
site AX devices will then send their RTT measurements to the GSLB AX
device. However, if more than 3 site AX devices fail to send their RTT mea-
surements to the GSLB AX device, the AX device will not use the active
RTT metric.
Changing Active RTT Settings for a Site

You can adjust the following Active RTT settings on individual sites:
• aging-time – Specifies the maximum amount of time a stored active-
RTT result can be used. You can specify 1-60 minutes. The default is 10
minutes.
• bind-geoloc – Stores the active-RTT measurements on a per geo-loca-
tion basis. Without this option, the measurements are stored on a per
site-SLB device basis.
• range-factor – Specifies the maximum percentage a new active-RTT
measurement can differ from the previous measurement. If the new
measurement differs from the previous measurement by more than the
allowed percentage, the new measurement is discarded and the previous
measurement is used again.
For example, if the range-factor is set to 25 (the default), a new mea-
surement that has a value from 75% to 125% of the previous value can
be used. A measurement that is less than 75% or more than 125% of the
previous measurement can not be used.
You can specify 1-1000. The default is 25.
• smooth-factor – Blends the new measurement with the previous one, to
smoothen the measurements.
For example, if the smooth-factor is set to 10 (the default), 10% of the
new measurement is used, along with 90% of the previous measure-
ment. Similarly, if the smooth-factor is set to 50, 50% of the new mea-
surement is used, along with 50% of the previous measurement.
You can specify 1-100. The default is 10.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
Note: Active RTT settings for a site cannot be changed using the GUI.
USING THE CLI
Use the following command at the configuration level for the site:
[no] active-rtt
aging-time minutes |
bind-geoloc |
range-factor num |
smooth-factor num
Passive RTT
Passive RTT measures the round-trip-time between when the site AX
device receives a client’s TCP connection (SYN) and the time when the site
AX device receives acknowledgement (ACK) back from the client for the
connection.
Enabling Passive RTT

To enable passive RTT, use either of the following methods.
USING THE GUI

3. Click on the policy name or click Add to create a new one.
4. Drag-and-drop Passive RTT from the Not In Use column to the In Use
column.
5. Click the plus sign to display the Passive RTT configuration fields.
6. To change sample settings, edit the values in the Samples and Tolerance
fields. (These parameters work the same as they do for active RTT. See
“Multiple Samples” on page 353 and “Tolerance” on page 353.)
7. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
Enter the following command at the configuration level for the GSLB pol-
icy:
[no] passive-rtt
Changing Passive RTT Settings for a Site

You can adjust Passive RTT settings on individual sites. The types of set-
tings used by Passive RTT settings are the same as those used for Active
RTT. See “Changing Active RTT Settings for a Site” on page 355.
USING THE GUI

Note: Passive RTT settings for a site cannot be changed using the GUI.
USING THE CLI

[no] passive-rtt
bind-geoloc |
range-factor num |
smooth-factor num
Configuring BW-Cost Settings
If you are planning to use the bw-cost metric, read this section. Otherwise,
you can skip the section. The bw-cost metric is disabled by default.
The bw-cost metric selects sites based on bandwidth utilization on the site
AX links.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
How Bandwidth Cost Is Measured
To compare sites based on bandwidth utilization, the GSLB AX device

sends SNMP GET requests for a specified MIB interface object, such as
ifInOctets, to each site.
• If the SNMP object value has incremented less than or equal to the
bandwidth limit configured for the site, the site is eligible to be selected
as the best site.
• If the SNMP object value has incremented more than the bandwidth
limit configured for the site, the site is ineligible.
The GSLB AX device sends the SNMP requests at regular intervals. Once a
site is ineligible, the site can become eligible again at the next interval if the
utilization incrementation is below the configured limit minus the threshold
percentage. (See below.)
Configuration Requirements
To use the bw-cost metric, an SNMP template must be configured and

bound to each site. The GSLB SNMP template specifies the SNMP version
and other information necessary to access the SNMP agent on the site AX
device, and the Object Identifier (OID) of the MIB object to request.
In addition, the following bw-cost parameters must be configured on each

site:
• Bandwidth limit – The bandwidth limit specifies the maximum value by
which the requested MIB object can increment, for the site to be eligible
for selection as the best site.
• Bandwidth threshold – For a site to regain eligibility when bw-cost is
being compared, the SNMP object’s incremental value must be below
the threshold-percentage of the limit value.
For example, if the limit value is 80000 and the threshold is 90, the limit
value must increment by 72000 or less, in order for the site to become
eligible again based on bandwidth cost. Once a site again becomes eligi-
ble, the SNMP object’s value is again allowed to increment by as much
as the bandwidth limit value (80000, in this example).
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Bandwidth Cost
To use the bw-cost metric:

1. On the site AX devices, configure and enable SNMP.
2. On the GSLB AX device:

a. Configure a GSLB SNMP template.
b. Add the template to the GSLB site configuration.
c. Optionally, set the bandwidth limit and threshold on the site. By
default, the bandwidth limit is not set (unlimited).
d. Enable the bw-cost metric in the GSLB policy. By default, the bw-
cost metric is disabled.
USING THE GUI
Note: SNMP template configuration is not supported in the GUI. Use the CLI to
configure the template, then use the following GUI procedures.
USING THE CLI

To Configure a GSLB SNMP Template
Use the following commands:
[no] gslb template snmp template-name
This command adds the template and changes the CLI to the configuration
level for the template, where the following template-related commands are
available:
[no] version {v1 | v2c | v3}

The version command specifies the SNMP version running on the site AX
device.
[no] host ipaddr
[no] oid oid-value
The host command specifies the IP address of the site AX device.
The oid command specifies the interface MIB object to query on the site
AX device.
Note: If the object is part of a table, make sure to append the table index to the
end of the OID. Otherwise, the AX device will return an error.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SNMPv1 / v2c Commands:
[no] community community-string
The community command specifies the community string required for
authentication.
SNMPv3 Commands:
[no] username name
This command specifies the SNMPv3 username required for access to the
SNMP agent on the site AX device.
[no] security-level
{no-auth | auth-no-priv | auth-priv}
This command specifies the SNMPv3 security level:
• no-auth – Authentication is not used and encryption (privacy) is not
used. This is the default.
• auth-no-priv – Authentication is used but encryption is not used.
• auth-priv – Both authentication and encryption are used.
[no] auth-proto {sha | md5}

[no] auth-key string
These commands are applicable if the security level is auth-no-priv or
auth-priv. The auth-proto command specifies the authentication protocol.
The auth-key command specifies the authentication key. The key string can
be 1-127 characters long.
[no] priv-proto {aes | des}

[no] priv-key string
These commands are applicable only if the security level is auth-priv. The
priv-proto command specifies the privacy protocol used for encryption.
The priv-key command specifies the encryption key. The key string can be
1-127 characters long.
[no] context-engine-id id
[no] context-name id
[no] security-engine-id id
The context-engine-id command specifies the ID of the SNMPv3 protocol
engine running on the site AX device. The context-name command speci-
fies an SNMPv3 collection of management information objects accessible
by an SNMP entity. The security-engine-id command specifies the ID of
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
the SNMPv3 security engine running on the site AX device. For each com-
mand, the ID is a string 1-127 characters long.
[no] interface id
The interface command specifies the SNMP interface ID.
Additional Commands:
[no] interval seconds
[no] port port-num
The interval command specifies the amount of time between each SNMP
GET to the site AX devices. You can specify 1-999 seconds. The default
is 3.
The port command specifies the protocol port on which the site AX devices
listen for the SNMP requests from the GSLB AX device. You can specify 1-
65535. The default is 161.
To Apply a GSLB SNMP Template to a GSLB Site

[no] template template-name
To Configure the Bandwidth Limit and Threshold on a Site

[no] bw-cost limit limit threshold percentage
The limit specifies the maximum amount the SNMP object queried by the
GSLB AX device can increment since the previous query, in order for the
site to remain eligible for selection as the best site. You can specify 0-
2147483647. There is no default.
If a site becomes ineligible due to being over the limit, the percentage
parameter is used. In order to become eligible for selection again, the site’s
limit value must not increment more than
limit*threshold-percentage.
You can specify 0-100. There is no default.
To Enable the Bandwidth Cost Metric in a GSLB Policy

Use the following command at the configuration level for the policy:
[no] bw-cost
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To display bw-cost data for a site
Use the following command:
show gslb site [site-name] bw-cost
CLI Example – SNMPv2c

The following commands configure a GSLB SNMP template for
SNMPv2c:
AX(config)#gslb template snmp snmp-1
AX(config-gslb template snmp)#version v2c
AX(config-gslb template snmp)#host 192.168.214.124
AX(config-gslb template snmp)#oid .1.3.6.1.2.1.2.2.1.16.12
AX(config-gslb template snmp)#community public
AX(config-gslb template snmp)#exit
The following commands apply the SNMP template to a site and set the
bandwidth increment limit and threshold:
AX(config)#gslb site usa
AX(config gslb-site)#template snmp-1
AX(config gslb-site)#bw-cost limit 100000 threshold 90
AX(config gslb-site)#exit
The following commands enable the bw-cost metric in the GSLB policy:
AX(config)#gslb policy pol1
AX(config-gslb policy)#bw-cost
AX(config-gslb policy)#exit
The following command displays bw-cost data for the site:

AX-1(config)#show gslb site usa bw-cost
U = Usable, TI = Time Interval
USGN = Unsigned, SN64 = Unsigned 64
CNTR = Counter, CT64 = Counter 64
Site Template Current Highest Limit U Type Len Value TI
--------------------------------------------------------------------------------
usa snmp-1 31091 142596 100000 Y CNTR 4 3355957308 3
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI Example – SNMPv3
The following commands configure a GSLB SNMP template for SNMPv3.
In this example, authentication and encryption are both used.
AX(config)#gslb template snmp snmp-2
AX(config-gslb template snmp)#security-level auth-priv
AX(config-gslb template snmp)#host 192.168.214.124
AX(config-gslb template snmp)#username read
AX(config-gslb template snmp)#oid .1.3.6.1.2.1.2.2.1.16.12
AX(config-gslb template snmp)#priv-proto des
AX(config-gslb template snmp)#auth-key 12345678
AX(config-gslb template snmp)#priv-key 12345678
The other commands are the same as those shown in “CLI Example –
SNMPv2c” on page 362.
Loading or Configuring Geo-Location Mappings
You can configure geo-location mappings manually or by loading the map-

pings from a file. Unless you have only a few sites, configuring the geo-
location mappings manually might not be practical. A10 Networks recom-
mends that you load the mappings from a file.
The geo-location configuration options are described in detail below. To

skip the descriptions and go directly to configuration instructions, see one of
the following sections. Each section provides the procedure for one of the
methods to configure geo-location mappings.
• “Loading the IANA Database” on page 366
• “Creating and Loading a Custom Geo-Location Database” on page 366
• “Manually Configuring Geo-Location Mappings” on page 369
Geo-Location Database Files
You can load the geo-location database from one of the following types of
files:
• Internet Assigned Numbers Authority (IANA) database – The IANA
database contains the geographic locations of the IP address ranges and
subnets assigned by the IANA. The IANA database is included in the
AX system software. However, it is unloaded (not used) by default.
• Custom database in CSV format – You can load a custom geo-location
database from a file in comma-separated-values (CSV) format. This
option requires configuration of a CSV template on the AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
When you load the CSV file, the data is formatted based on the tem-
plate.
Geo-Location Mappings
A geo-location mapping consists of a geo-location name and an IP address

or IP range.
• If you manually map a geo-location to an GSLB site, GSLB uses the
mapping.
• If no geo-location is configured for a GSLB site, GSLB automatically
maps the service-ip to a geo-location in the loaded geo-location data-
base.
• If a service-ip cannot be mapped to a geo-location, GSLB maps the site
AX device to a geo-location.
If more than one geo-location matches a client’s IP address, the most spe-
cific match is used. For example, if a client is in the same city as a site AX,
that site will be preferred. If the client and site are in the same state but in
different cities, the site in that state will be preferred.
Only one database can be active. If you load more than one database, the
most-recently loaded one becomes the active one. The older database is no
longer used. Data from the older database is not merged into the new data-
base.
Example Database File
An example of a database file is shown below. Each paragraph is actually a

single line in the file, but they are displayed here in multiple lines due to the
limited width of the page.
"1159363840","1159364095","US","UNITED STATES","NA","NORTH AMERICA","EST","MA","MASSA-
CHUSETTS", "COMMRAIL INC","MARLBOROUGH","MIDDLESEX","42.3495","-71.5482"
"1159364096","1159364351","US","UNITED STATES","NA","NORTH AMERICA","","","","ENVIRON-
MENTAL COMPLIANCE SERVICE","SILVER","","32.0708","-100.682"
CHUSETTS", "MLS PROPERTY INFORMATION NETWORK","SHREWSBURY","WORCESTER","42.2959","-
71.7134"
...
The example above shows the file displayed in a text editor. The same file
looks like the example in Figure 114 if displayed in a spreadsheet applica-
tion. However, when the file is saved to CSV format, the file is essentially
as shown above.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 114 CSV File in Spreadsheet Application
The database file can contain more types of information (fields) than are
required for the GSLB database. When you load the file into the geo-loca-
tion database, the CSV template on the AX device is used to filter the file to
extract the required data. In this example, only the fields shown in bold type
will be extracted and placed into the geo-location database:
CHUSETTS","COMMRAIL INC","MARLBOROUGH","MIDDLESEX","42.3495","-71.5482"
These fields contain the following information:

From IP address (starting IP address in range), To IP address (ending IP address in
range, or subnet mask), Continent, Country
The IP addresses in this example are in bin4 format. Dotted decimal format
(for example: 69.26.125.0) is also supported. If you use bin4 format, the AX
device automatically converts the addresses into dotted decimal format
when you load the database into GSLB.
Converting IP Addresses into bin4 Format
If you want to use bin4 format in the CSV file, here is how to convert an IP
address from dotted-decimal format to bin4 format:
1. Convert each node into Hex.
2. Convert the resulting Hex number into decimal.
3. Enter the decimal number into the database file.
Here is an example for IP address 69.26.125.0, the first IP address in the

example CSV file:
Dotted Decimal Hex of Each Node Combined Decimal

Hex Number
69.26.125.0 45.1a.7d.00 451a7d00 1159363840
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CSV File Field Delimiters
The fields in the CSV file must be separated by a delimiter. By default, the
AX device interprets commas as delimiters. When you configure the CSV
template on the AX device, you can set the delimiter to any valid ASCII
character.
Loading the IANA Database

The AX system software already contains the IANA database. However, the
database does not become active until you load it.
USING THE GUI

2. On the menu bar. select Geo-location > Import.
3. On the Load/Unload tab, enter “iana” in the File field. Leave the Tem-
plate field blank.
4. Click Add.
USING THE CLI

Use the following command at the global configuration level of the CLI:
[no] gslb geo-location load iana
Creating and Loading a Custom Geo-Location Database

To create and load a custom geo-location database:
1. Prepare the database file. (This step requires an application that can
save to text for CSV format, and can not be performed on the AX
device.)
2. Configure a CSV template for the file. The CSV template specifies the
field positions for IP address and location information.
3. Import the CSV file onto the AX device.
4. Load the CSV file.
5. Display the geo-location database.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
Configuring the CSV Template

2. On the menu bar, select Geo-location > Import.
3. On the Template tab, enter name for the template.
4. If the CSV file uses a character other than a comma to delimit fields,
enter the delimiter character in the Delimiter field.
5. In each data field, indicate the field’s position in the CSV file. For exam-
ple, if the destination IP address or subnet is listed in the CSV file in
data field 4, enter “4” in the IP-To field.
6. Click Add.
Importing the CSV File

1. Select Config > Service > GSLB, if not already selected.
2. On the menu bar, select Geo-location > Import, if not already selected..
3. On the File tab, select the file transfer protocol.
4. Enter the filename and the access parameters required to copy the file
from the remote server.
5. Click Add.
Loading the CSV File Data into the Geo-Location Database

1. Select Config > Service > GSLB, if not already selected.
2. On the menu bar, select Geo-location > Import, if not already selected..
3. On the Load/Unload tab, enter the name of the geo-location database in

the file field.
4. In the Template field, enter the name of the template to use for format-
ting the data.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
Configuring the CSV Template
On the AX device, you must configure a CSV template for the database file.
When you load the file into GSLB, the AX device uses the template to
extract the data and load it into the GSLB database.
1. Use the following command at the global configuration level of the
CLI:
[no] gslb template csv template-name
This command creates the template and changes the CLI to the configu-
ration level for it.
2. Use the following command to identify the field positions for the geo-
location data:
[no] field num {ip-from | ip-to-mask |
continent | country | state | city}
The num option specifies the field position within the CSV file. You can
specify 1-64. The following options specify the type of geo-location
data that is located in the field position:
• ip-from – Specifies the beginning IP address in the range or subnet.
• ip-to-mask – Specifies the ending IP address in the range, or the
subnet mask.
• continent – Specifies the continent where the IP address range or
subnet is located.
• country – Specifies the country where the IP address range or subnet
is located.
• state – Specifies the state where the IP address range or subnet is
located.
• city – Specifies the city where the IP address range or subnet is
located.
3. If the CSV file uses a character other than a comma to delimit fields, use
the following command to specify the character used in the file:
[no] delimiter {character | ASCII-code}
You can type the character or enter its decimal ASCII code (0-255).
Importing the CSV File
To import the CSV file onto the AX device, use the following command at
the Privileged EXEC or global configuration level of the CLI:
import geo-location file-name [use-mgmt-port] url
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
You can enter the entire URL on the command line or press Enter to display
a prompt for each part of the URL. If you enter the entire URL and a pass-
word is required, you will still be prompted for the password. To enter the
entire URL:
(For information about the use-mgmt-port option, see “Using the Manage-
ment Interface as the Source for Management Traffic” on page 669.)
Loading the CSV File Data into the Geo-Location Database
To load the CSV file, use the following command at the global configura-
tion level of the CLI:
[no] gslb geo-location load file-name

csv-template-name
Use the file name you specified when you imported the CSV file, and the
name of the CSV template to be used for extracting data from the file.
Note: The file-name option is available only if you have already imported a geo-
location database file.
To display information about CSV files that have been loaded are currently
being loaded, use the following command:
show gslb geo-location file [file-name]
Manually Configuring Geo-Location Mappings
USING THE GUI
In the GUI, this is part of site configuration. See “Configure Sites” on

page 374.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI

To manually configure a geo-location mapping:
1. Configure each geographic location (geo-location) as a named range of
client IP addresses. You can configure geo-locations globally and
within individual GSLB policies.
To configure a geo-location, use the following command at the global
configuration level or at the configuration level for the GSLB policy:
[no] gslb geo-location location-name
start-ip-addr [mask ip-mask] [end-ip-addr]
2. Associate a site with a geo-location name, using the following command

at the configuration level for the site:
[no] geo-location location-name
Note: If you configure geo-locations globally and at the configuration level for
individual sites, and a client IP address matches both a globally config-
ured geo-location and a geo-location configured on a site, the globally
configured geo-location is used by default. To configure the GSLB AX
device to use geo-locations configured on individual sites instead, use the
geo-location match-first policy command at the configuration level for
the policy.
Displaying the Geo-Location Database
USING THE GUI

2. On the menu bar, select Geo-location > Find.
The geo-location database appears. You can use the find options to display
database entries or statistics for specific geo-locations or IP addresses.
USING THE CLI
To display the geo-location database, use the following command:
show gslb geo-location db [geo-location-name]

[[statistics] ip-range range-start range-end]
[[statistics] depth num]
[statistics]]
The geo-location-name option displays the database entry for the specified
location.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The ip-range option displays entries for the specified IP address range.
The depth num option filters the display to show only the location entries at
the specified depth or higher. For example, to display only continent and
country entries and hide individual state and city entries, specify depth 2.
To search for an entry in the geo-location database based on client IP

address, use the following command:
show gslb geo-location ip ipaddr
CLI Example
The commands in this example load a custom geo-location database from a

CSV file called “test.csv”, and display the database. The test.csv file is
shown in “Example Database File” on page 364.
First, the following commands configure the CSV template:

AX(config)#gslb template csv test1-tmplte
AX(config-gslb template csv)#field 1 ip-from
AX(config-gslb template csv)#field 2 ip-to-mask
AX(config-gslb template csv)#field 5 continent
AX(config-gslb template csv)#field 3 country
AX(config-gslb template csv)#exit
The following command imports the file onto the AX device:

AX(config)#import geo-location test1.csv ftp:
User name []?admin2
Password []?*********
File name [/]?test1.csv
The following commands initiate loading the data from the CSV file into
the geo-location database, and display the status of the load operation:
AX(config)#gslb geo-location load test1.csv test1-tmplte
AX(config)#show gslb geo-location file
T = T(Template)/B(Built-in), Per = Percentage of loading
Filename T Template Per Lines Success Error
------------------------------------------------------------------------------
test1 T t1 98% 11 10 0
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following command displays the geo-location database. The data that
was extracted from the CSV file is shown here in bold type.
AX(config)#show gslb geo-location db
Last = Last Matched Client, Hits = Count of Client matched

T = Type, Sub = Count of Sub Geo-location
G(global)/P(policy), S(sub)/R(sub range)
M(manually config)
Global
Name From To Last Hits Sub T
------------------------------------------------------------------------------
NA (empty) (empty) (empty) 0 1 G
Geo-location: NA, Global

------------------------------------------------------------------------------
US (empty) (empty) (empty) 0 10 GS
Geo-location: NA.US, Global

------------------------------------------------------------------------------
69.26.125.0 69.26.125.255 (empty) 0 0 GR
69.26.126.0 69.26.126.255 (empty) 0 0 GR
69.26.127.0 69.26.127.255 (empty) 0 0 GR
69.26.128.0 69.26.136.135 (empty) 0 0 GR
69.26.136.136 69.26.136.143 (empty) 0 0 GR
69.26.136.144 69.26.140.255 (empty) 0 0 GR
69.26.141.0 69.26.141.255 (empty) 0 0 GR
69.26.142.0 69.26.159.255 (empty) 0 0 GR
69.26.160.0 69.26.160.255 (empty) 0 0 GR
69.26.161.0 69.26.161.7 (empty) 0 0 GR
Configure Services
To configure GSLB services, use either of the following methods.
USING THE GUI

2. On the menu bar, select Service IP.
3. Click Add.
4. Enter the service name and IP address.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
5. If needed, assign an external IP address to the service IP. The external IP
address allows a service IP that has an internal IP address to be reached
from outside the internal network.
6. Add the service port(s):

a. Enter the port number and select the protocol (TCP or UDP).
b. Optionally, select a health monitor.
c. Click Add. The service port appears in the service port list.
7. Click OK.
8. Repeat for each service IP.
USING THE CLI

To configure service VIPs, use the following command at the global config-
uration level of the CLI:
gslb vip-name ipaddr
This command changes the CLI to the configuration level for the service.
To assign an external IP address to the service, use the following command.

An external IP address is needed if the service IP address is an internal IP
address that can not be reached from outside the internal network.
external-ip ipaddr
To configure a service port on the service, use the following command to

change the CLI to the configuration level for the port:
To enable health monitoring of the service, use the following command:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configure Sites
To configure GSLB sites, use either of the following methods.
USING THE GUI

2. On the menu bar, select Site.
3. Click Add.
4. Enter the site name.
5. On the SLB-Device tab, enter information about the AX devices that

provide SLB for the site:
a. Click Add.
b. Enter a name for the device.
c. Enter the IP address at which the GSLB AX device will be able to
reach the site AX device.
d. To add a service to this SLB device, select it from the drop-down list
in the VIP server section and click Add. Repeat for each service.
6. On the IP-Server tab, add services to the site. Select a service from the
drop-down list and click Add. Repeat for each service.
7. To manually map a geo-location name to the site, enter the geo-location

name on the Geo-location tab and click Add.
8. Click OK. The site appears in the Site table.
USING THE CLI
To configure the GSLB sites, use the following commands:
gslb site site-name
This command changes the CLI to the configuration level for the site. To
associate an IP service with this site, use the following command:
ip-server service-ip
The ipaddr is the IP address of a real server load balanced by the site.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To specify the AX device that provides SLB at the site, use the following
command:
slb-dev device-name ip-addr
To add the GSLB VIP server to the SLB device, use the following com-
mand:
vip-server gslb service-name
The service-name is the GSLB service specified by the gslb vip-name

ipaddr command in “Configure Services” on page 372.
Configure a Zone
To configure a GSLB zone, use either of the following methods.
USING THE GUI

2. On the menu bar, select Zone.
3. Click Add.
4. Enter the zone name in the Name field.
5. On the Service tab, click Add. (See Figure 123 on page 408.)
The service configuration tabs appear.
6. In the Service field, enter the service name.
7. Select the service type from the Port drop-down list.
8. Add the services:

a. On the Service tab, click Add.
b. Enter name for the service (for example, “www”).
c. Select the service type from the Port drop-down list.
d. Configure additional options, if applicable to your deployment. (See
Table 8, “GSLB Parameters,” on page 378.)
e. Click OK.
f. Repeat for each service.
9. Click OK. The zone appears in the GSLB zone list.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
To configure the GSLB zone, use the following commands:
gslb zone zone-url
The zone-url is the URL that clients will send in DNS queries.
This command changes the CLI to the configuration level for the zone. To
add a service to the zone, use the following command:
service port service-name
The port is the application port for the server and must be the same port
name or number specified on the service VIP.
Enable the GSLB Protocol

To enable the GSLB protocol, use either of the following methods.
USING THE GUI

2. On the menu bar, select Global.

The Global tab appears.
3. Select Enabled next to one of the following options, depending on the

AX device’s function in the GSLB configuration:
• Run GSLB as Controller
• Run GSLB as Site SLB Device
If you are planning to use the Passive RTT metric, select the Passive
RTT checkbox to enable collection of passive RTT data on this site
AX device.
4. Click OK.
USING THE CLI
To enable the GSLB protocol on the GSLB AX device, use the following
command at the global configuration level of the CLI:
gslb protocol enable controller
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To enable the GSLB protocol on a site AX device, use the following com-
mand at the global configuration level of the CLI:
gslb protocol enable device [no-passive-rtt]
The no-passive-rtt option disables collection of passive RTT data on this

site AX device. If you are planning to use the Passive RTT metric, do not
use this option.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
GSLB Parameters
Table 8 lists the GSLB parameters.
TABLE 8 GSLB Parameters

Global GSLB Parameters
protocol enable Enables the GSLB protocol. The protocol must be Controller or device.
(Required) enabled on the GSLB AX device and on the site AX Default: Disabled
devices.
When you enable the GSLB protocol,
[no] gslb protocol the default status interval is 30 sec-
{enable {controller | onds.
device [no-passive-rtt]} |
status-interval seconds}
On the GSLB AX device, use the controller option.
On the site AX devices, use the device option.
The status-interval option sets the number of sec-
onds between GSLB status messages.
Config > Service > GSLB > Global
geo-location Maps geographic locations to IP address ranges. For geo-location mappings loaded
(Optional) GSLB forwards client requests from addresses from a database, the mappings must be
within the range to the GSLB site that serves the in the AX device’s IANA database or
location. in a comma-separated values (CSV)
To load the IANA database: file.
[no] gslb geo-location load iana For individual mappings, the location-
name can be up to 127 alphanumeric
Config > Service > GSLB > Geo-location > Import
characters. Specify either the begin-
To load a custom database: ning and ending addresses of the
[no] gslb template csv template- range, or the beginning address and the
name network mask.
[no] gslb geo-location load Default: No geo-location database is
file-name csv-template-name loaded and no individual mappings are
Config > Service > GSLB > Geo-location > Import configured.
To configure individual mappings:
[no] gslb geo-location
location-name
start-ip-addr [mask ip-mask]
[end-ip-addr]
Config > Service > GSLB > Site - Geo-location tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
TABLE 8 GSLB Parameters (Continued)
policy Configures a GSLB policy. GSLB policies config- Default: The “default” GSLB policy is
(Optional) ure the GSLB metrics used to select the best sites used, unless you configure another
and site IP addresses to return in DNS replies to cli- policy and apply it to the zone.
ents.
[no] gslb policy
{default | policy-name}
Config > Service > GSLB > Policy
service-ip Configures a virtual IP address (VIP) for a service. The vip-name can be up to 31 alphanu-
(Required) In GSLB, service IP addresses are VIPs that repre- meric characters.
sent services that are provided by servers connected
to the site AX devices.
[no] gslb service-ip vip-name
[ipaddr]
Config > Service > GSLB > Service IP
site Configures a site. A GSLB zone can contain one or The site-name can be up to 31 alpha-
(Required) more sites. Each site has at least one AX device pro- numeric characters.
viding load balancing for the site’s services. Default: None
[no] gslb site site-name
Config > Service > GSLB > Site
See “Site Parameters” below.
zone Configures a zone. The zone identifies the top-level The zone-url is the URL of the zone
(Required) URL for the services load balanced by GSLB. and can be up to 127 alphanumeric
[no] gslb zone zone-url characters.
Config > Service > GSLB > Zone Default: None
See “Zone Parameters” below. Note: You can use lower case charac-
ters and upper case characters. How-
ever, since Internet domain names are
case-insensitive, the AX device inter-
nally converts all upper case characters
in GSLB zone names to lower case.
Service-IP Parameters
service-ip status Enables or disables the service-ip. Default: Enabled
(Required) disable | enable
Config > Service > GSLB > Service-IP
external IP Assigns an external IP address to the service IP. The Default: None
address external IP address allows a service IP that has an
internal IP address to be reached from outside the
internal network.
[no] external-ip ipaddr
D e s i g n 379 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
health check Enables or disables monitoring for the service IP Default: The default Layer 3 health
address. You can specify any health monitor (Layer monitor (ICMP ping) is used.
3, 4 or 7).
[no] health-check [monitor-name]
service port Adds a service port to the service IP address. The Valid protocol port number and service
command also changes the CLI to the configuration type
level for the specified service port, where the fol- Default: None
lowing service port-related commands are available:
port num {tcp | udp}
Site Parameters
active-rtt Configures options for the Active RTT metric. aging-time – Specifies the maximum
(Optional) [no] active-rtt amount of time a stored active-RTT
aging-time minutes | result can be used. You can specify 1-
bind-geoloc | 60 minutes. The default is 10 minutes.
range-factor num | bind-geoloc – Stores the active-RTT
smooth-factor num measurements on a per geo-location
Note: Configuration of these parameters is not sup- basis. Without this option, the mea-
ported in the GUI. surements are stored on a per site-SLB
device basis.
range-factor – Specifies the maximum
percentage a new active-RTT measure-
ment can differ from the previous mea-
surement. If the new measurement
differs from the previous measurement
by more than the allowed percentage,
the new measurement is discarded and
the previous measurement is used
again.
For example, if the range-factor is set
to 25 (the default), a new measurement
that has a value from 75% to 125% of
the previous value can be used. A mea-
surement that is less than 75% or more
than 125% of the previous measure-
ment can not be used.
You can specify 1-1000. The default is
25.
smooth-factor – Blends the new mea-
surement with the previous one, to
smoothen the measurements. You can
specify 1-100. The default is 10.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
bw-cost Configures options for the bw-cost metric: limit – Specifies the maximum amount
(Optional) [no] bw-cost limit limit the SNMP object queried by the GSLB
threshold percentage AX device can increment since the
previous query, in order for the site to
Note: Configuration of these parameters is not sup-
remain eligible for selection as the best
ported in the GUI.
site. You can specify 0-2147483647.
There is no default.
If a site becomes ineligible due to
being over the limit, the percentage
parameter is used. In order to become
eligible for selection again, the site’s
limit value must not increment more
than limit*threshold-per-
centage.
You can specify 0-100. There is no
default.
threshold percentage – For a site to
regain eligibility when bw-cost is
being compared, the SNMP object’s
incremental value must be below the
threshold-percentage of the limit
value.
For example, if the limit value is
80000 and the threshold is 90, the limit
value must increment by 72000 or less,
in order for the site to become eligible
again based on bandwidth cost. Once a
site again becomes eligible, the SNMP
object’s value is again allowed to
increment by as much as the band-
width limit value (80000, in this exam-
ple).
geo-location Associates the site with a specific geographic loca- The location-name can be up to 127
(Optional) tion. alphanumeric characters.
[no] geo-location location-name Default: None
Config > Service > GSLB > Site - Geo-location tab
Note: This option is applicable only for manually
configuring geo-location mappings. If you plan to
load geo-location mappings from a file instead, you
do not need to use this option.
D e s i g n 381 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
ip-server Associates a real server with this site. Default: None
(Optional) [no] ip-server service-name
Config > Service > GSLB > Site - IP Server tab
Note: Generally, virtual servers rather than real
servers are associated with a site. To associate a vir-
tual server with a site, use the vip-server option at
the SLB device configuration level. (See “SLB
device parameters”.)
passive-rtt Configures options for the passive RTT metric. The See the description for active-rtt,
(Optional) options are the same as those for active-rtt. (See above.
above.)
[no] passive-rtt
bind-geoloc |
range-factor num |
smooth-factor num
Note: Configuration of these parameters is not sup-
ported in the GUI.
slb-device Specifies the AX device that provides SLB for the The device-name can be up to 31
(Required) site. alphanumeric characters. The IP
[no] slb-dev device-name ipaddr address must be an address that can be
reached by the GSLB AX device.
Config > Service > GSLB > Site - SLB Device tab
Default: None
template Binds a template to the site. To use the bw-cost met- Name of configured SNMP template.
(Optional) ric, use this option to bind a GSLB SNMP template Default: None
to the site.
[no] template template-name
Note: Configuration of this parameter is not sup-
ported in the GUI.
weight Assigns a weight to the site. If the weighted-site The weight can be from 1 – 100.
(Optional) metric is enabled in the policy and all metrics before Default: 1
weighted-site result in a tie, the site with the highest
weight is preferred.
[no] weight num
Config > Service > GSLB > Site - General tab
SLB Device Parameters
admin-prefer- Assigns a preference value to the SLB device. If the You can specify from 0 – 255.
ence admin-preference metric is enabled in the policy Default: 100
(Optional) and all metrics before this one result in a tie, the
SLB device with the highest admin-preference
value is preferred.
[no] admin-preference num
Config > Service > GSLB > Site - SLB-Device tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
passive-rtt-timer For passive RTT, specifies the number of seconds 1-255
(Optional) during which samples are collected during each Default: 3
sampling period. You can specify 1-255. The
default is 3.
[no] passive-rtt-timer num
To prevent samples from being taken for this
device, use the no passive-rtt-timer command.
Note: Configuration of this parameter is not sup-
ported in the GUI.
vip-server Maps this SLB site to a globally configured GSLB The name must be the name of a con-
(Required) service IP address (configured by the service-ip figured service IP. (To configure the
option). service IP, use the gslb service-ip
[no] vip-server name command.)
Config > Service > GSLB > Site - SLB-Device tab Default: None
Zone Parameters
dns-mx-record Configures a DNS Mail Exchange (MX) record for The name is the fully-qualified domain
(Optional) the zone. The name is the fully-qualified domain name of the mail server for the zone.
name of the mail server for the zone. The priority can be 0-65535. There is
If more than MX record is configured for the same no default preference.
zone, the priority specifies the order in which the Default: None
mail server should attempt to deliver mail to the MX
hosts. The MX with the lowest preference value has
the highest priority and is tried first. The priority
can be 0-65535. There is no default.
MX records configured on a zone are used only for
services on which MX records are not configured.
[no] dns-mx-record name
priority
Config > Service > GSLB > Zone - Click Add on
the Service tab to display the DNS MX Record tab.
policy Applies a GSLB policy to the zone. The policy-name can be up to 31
(Optional) [no] policy policy-name alphanumeric characters.
Config > Service > GSLB > Zone Default: The “default” GSLB policy is
used, unless you configure another
See “Policy Parameters” on page 387.
policy and apply it to the zone.
service Adds a service to the zone. The GSLB AX Series The port can be a well-known name
(Required) verifies the availability of the service by sending a recognized by the CLI or a port num-
health check to the specified service port. ber from 1 to 65535.
[no] service port service-name The service-name can be up to 31
Config > Service > GSLB > Zone - Service tab alphanumeric characters. (For the
same reason described for zone names,
The health check must be assigned to the individual
the AX device converts all upper case
service. See “Service Parameters” below.
characters in GSLB service names to
lower case.)
Default: None
D e s i g n 383 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
ttl Changes the TTL of each DNS record contained in You can specify from 0 to 1000000
(Optional) DNS replies received from the DNS for which the (1,000,000) seconds.
AX Series is a proxy, for this zone. Default: 10 seconds
TTL can be set at different levels of the GSLB con-
figuration; however, only one of the TTL settings is
used. (See “DNS Options” on page 342.)
ttl seconds [no]
Config > Service > GSLB > Zone
The health check must be assigned to the individual
service. See “Service Parameters” below.
Service Parameters
action Specifies the action to perform for DNS traffic. You can specify one of the following:
(Optional) Note: Use of the actions configured for services • Drop – Drops DNS queries from the
also must be enabled in the GSLB policy, using the local DNS server.
DNS action option. See Table 9, “GSLB Policy • Reject – Rejects DNS queries from
Parameters,” on page 387. the local DNS server and returns the
[no] action {drop | reject | “Refused” message in replies.
forward {both | query | response}} • Forward – Forwards requests or
Config > Service > GSLB > Zone - Click Add on queries, as follows:
the Service tab to display the Service tab. • Forward both – Forwards queries
to the Authoritative DNS server,
and forwards responses to the
local DNS server.
• Forward query – Forwards que-
ries to the Authoritative DNS
server, but does not forward
responses to the local DNS
server.
• Forward response – Forwards
responses to the local DNS
server, but does not forward que-
ries to the Authoritative DNS
server.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
dns-a-record Configures a DNS Address (A) record for the ser- weight – Assigns a weight to the ser-
(Optional) vice, for use with the DNS replace-ip option in the vice. If the weighted-ip metric is
GSLB policy. enabled in the policy and all metrics
dns-a-record before weighted-ip result in a tie, the
{service-name | service-ipaddr} service on the site with the highest
{weight num | static | weight is selected. The weight can be
as-replace | no-resp} 1-100. By default, the weight is not
Config > Service > GSLB > Zone - Click Add on set.
the Service tab to display the DNS Address Record static – This option is used with the
tab. dns server option in the policy. When
Note: The no-resp option is not valid with the static both options are set (static here and
or as-replace option. If you use no-resp, you cannot dns server in the policy), the GSLB
use static or as-replace. AX device acts as the DNS server for
the IP address set here by service-ip.
This option is disabled by default.
as-replace – This option is used with
the ip-replace option in the policy.
When both options are set (as-replace
here and ip-replace in the policy), the
client receives only the IP address set
here by service-ip. This option is dis-
abled by default.
no-resp – Prevents the IP address for
this site from being included in DNS
replies to clients. This option is dis-
abled by default.
dns-cname- Configures DNS Canonical Name (CNAME) Default: None
record records for the service.
(Optional) dns-cname-record alias
[alias ...]
the Service tab to display the DNS CName Record
tab.
D e s i g n 385 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
dns-mx-record Configures a DNS Mail Exchange (MX) record for The name is the fully-qualified domain
(Optional) the service. name of the mail server for the service.
If more than MX record is configured for the same The priority can be 0-65535. There is
service, the priority specifies the order in which the no default.
mail server should attempt to deliver mail to the MX
hosts. The MX record with the lowest priority num-
ber has the highest priority and is tried first.
dns-mx-record name priority
the Service tab to display the DNS MX Record tab.
Note: If you want the GSLB AX device to return
the IP address of the mail service in response to MX
requests, you must configure A records for the mail
service.
geo-location Maps an alias to the specified geographic location The location-name is a global GSLB
(Optional) for this service. parameter and must already be config-
[no] geo-location location-name ured. (See “Global GSLB parameters”
alias url and “Site parameters” above.)
Config > Service > GSLB > Zone - Click Add on The alias is a service parameter and
the Service tab to display the Geo-location tab. must already be configured. (See
above.)
This CNAME overrides any CNAME globally con-
figured for the zone. Default: None
ip-order Specifies the order in which to list the service IP Each service-ipaddr is a virtual IP
(Optional) addresses (VIPs) for this service in the DNS replies address assigned to the service at this
to clients. site.
The ip-order is one of the metrics used to select the Generally, each service will have a dif-
best IP address for a service. ferent virtual IP address for each real
[no] ip-order server that provides the service at the
{service-name | service-ipaddr} site.
[service-ipaddr ...]
the Service tab to display the DNS Address Record
tab.
policy Applies the specified GSLB policy to the service. The policy-name can be up to 31
(Optional) [no] policy policy-name alphanumeric characters.
Config > Service > GSLB > Zone - Click Add on You must configure the policy before
the Service tab to display the Service tab. you apply it.
Default: The GSLB policy applied to
the zone is also applied to the services
in that zone. If no policy is applied to
the zone, the “default” GSLB policy is
applied.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
Policy Parameters
Table 9 lists the GSLB policy parameters.
TABLE 9 GSLB Policy Parameters

Load Balancing Metrics
active-rtt Load balancing metric that selects the site with the The state is one of the following:
fastest round-trip-time for a DNS query and reply • Enabled
between a site AX device and the GSLB local DNS.
• Disabled – This is the default.
The active RTT metric is disabled by default. You
When you enable the active-rtt metric,
can enable it to take either a single sample (single
the default number of samples is 5.
shot) or multiple samples at regular intervals.
The default store-by is slb-device. The
[no] active-rtt default tolerance is 10 percent.
[single-shot] [skip count]
[timeout seconds]
[store-by {geo-location |
slb-device}]
Config > Service > GSLB > Policy - Metrics tab
Note: This metric requires the GSLB protocol to be

enabled on the site AX devices. (See “Metrics That
Require the GSLB Protocol on Site AX Devices” on
page 344.)
active-servers Load balancing metric that selects the site that has The state is one of the following:
the most active servers for the requested service. • Enabled
[no] active-servers • Disabled – This is the default.
admin-prefer- Load balancing metric that selects the service with The state is one of the following:
ence the highest administratively set preference. • Enabled
[no] admin-preference • Disabled – This is the default.
Config > Service > GSLB > Policy - Metrics tab The preference can be from 0 to 255.
The default is 100 for each site.
bw-cost Load balancing metric that selects sites based on The state is one of the following:
bandwidth utilization on the site AX links. • Enabled
[no] bw-cost • Disabled – This is the default.
D e s i g n 387 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
TABLE 9 GSLB Policy Parameters (Continued)
connection-load Sites that are at or below their thresholds of average The state is one of the following:
new connections per second are preferred over sites • Enabled
that are above their thresholds.
[no] connection-load
The limit can be from 1 to 999999999
[limit average-load] |
(999,999,999). The default is not set
[samples num interval seconds]
(unlimited).
The samples can be from 1 to 8. The
default is 5.
Note: This metric requires the GSLB protocol to be The interval can be from 1 to 60 sec-
enabled on the site AX devices. (See “Metrics That onds. The default is 5 seconds.
page 344.)
geographic Service IP addresses for the geographic region The state is one of the following:
where the client is located are preferred over • Enabled – This is the default.
addresses from other regions.
• Disabled
The GSLB AX Series selects the geographic region
by matching the client’s IP address with the GSLB
address ranges configured using geo-location
options.
[no] geographic
health-check Service IP addresses that pass their health checks The state is one of the following:
are preferred over addresses that do not pass their • Enabled – This is the default.
health checks.
• Disabled
An IP address that fails its health check is not auto-
matically ineligible to be included in the DNS reply
to a client.
[no] health-check

enabled on the site AX devices, if the default health
checks are used on the service IPs. (See “Health
Checks” on page 340.)
least-response Service IP addresses with the fewest hits are pre- The state is one of the following:
ferred over addresses with more hits. • Enabled
[no] least-response • Disabled – This is the default.

page 344.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
num-session Sites that are at or below their thresholds of current The state is one of the following:
available sessions are preferred over sites that are • Enabled
above their thresholds.
The tolerance specifies the percentage by which the
When you enable the num-session
number of available sessions on site SLB devices
metric, the default tolerance is 10 per-
can differ without causing the num-session metric to
cent.
select one SLB device over another. Thus, minor
differences among SLB devices do not cause fre-
quent, unnecessary changes in site preference.
Example:
Site A has 800,000 sessions available and Site B has
600,000 sessions available. The difference between
the two sites is 200,000 available sessions. If num-
session is set to 10, then Site A is preferred because
200,000 is larger than 10% of 800,000, which is
80,000.
[no] num-session [tolerance num]

page 344.)
ordered-ip Service IP addresses are re-ordered in DNS replies The state is one of the following:
to match the order administratively configured for • Enabled
the service.
The prioritized list is sent to the next metric for fur-
ther evaluation. If ordered-ip is the last metric, the
prioritized list is sent to the client.
The ordered list of IP addresses must be configured
for the service.
[no] ordered-ip
D e s i g n 389 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
passive-rtt Sites with faster round-trip times (RTTs) between a The state is one of the following:
client and the site are preferred over sites with • Enabled
slower times. The passive RTT is the time between
when the site AX device receives a client’s TCP
connection (SYN) and the time when the site AX When you enable the passive-rtt met-
device receives acknowledgement (ACK) back ric, the default number of samples is 5.
from the client for the connection. Passive RTT The default store-by is slb-device. The
measurements are taken for client addresses in each default tolerance is 10 percent.
/24 subnet range.
Passive RTT tolerance is a percentage from 0 to
100. It specifies how much the RTT values of sites
must differ in order for GSLB to prefer one site over
the other based on RTT.
Example:
Site A’s RTT value is 0.3 seconds and Site B’s RTT
value is 0.32 seconds. If the passive RTT tolerance
is 10% then the two sites are treated as having the
same passive RTT preference.
[no] passive-rtt
[store-by {geo-location |
slb-device}]

page 344.)
round-robin Each service IP address is used sequentially, in rota- The state is one of the following:
tion. The first service IP address is selected for the • Enabled – This is the default.
first new connection, the second address is selected
• Disabled
for the second new connection, and so on until all
service IP addresses have been selected. Then selec-
tion starts over again with the first service IP
address.
[no] round-robin
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
session-capacity Sites that have not exceeded their thresholds for The state is one of the following:
their respective maximum TCP/UDP sessions are • Enabled
preferred over sites that have exceeded their thresh-
olds.
The threshold can be from 0 to 100
Example:
percent. The default is 90.
Site A’s maximum session capacity is 800,000 and
Site B’s maximum session capacity is 500,000. If
the session-capacity threshold is set to 90, then for
Site A the capacity threshold is 90% of 800,000,
which is 720,000. Likewise, the capacity threshold
for Site B is 90% of 500,000, which is 450,000.
[no] capacity [threshold num]

page 344.)
weighted-ip Service IP addresses with higher weight values are The state is one of the following:
used more often than addresses with lower weight • Enabled
values.
[no] weighted-ip
weighted-site Sites with higher weight values are used more often The state is one of the following:
than sites with lower weight values. • Enabled
[no] weighted-site • Disabled – This is the default.
D e s i g n 391 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
metric-order Assigns a geographic location to an IP address You can specify one or more of the fol-
range. GSLB forwards client requests from lowing metrics (listed alphabetically):
addresses within the range to the GSLB site that • active-rtt
serves the location.
• active-servers
[no] metric-order metric
• admin-preference
[metric ...]
Config > Service > GSLB > Policy - Metrics tab • bw-cost
• capacity
• connection-load
The first metric you specify becomes the primary
metric. If you specify additional parameters, they • geographic
are used in the priority you specify. All remaining • health-check
metrics are prioritized to follow the metrics you • least-response
specify.
• num-session
For example, if you specify only the ordered-ip met-
• ordered-ip
ric with the command, and the metric order in the
policy has not been changed previously, the • passive-rtt
ordered-ip metric becomes the first metric. The • weighted-ip
health-check metric becomes the second metric, the • weighted-site
weighted-ip metric becomes the third metric, and so
on. Default metric order: See “GSLB Pol-
icy” on page 338.
DNS Parameters
action Enable GSLB to perform the DNS actions specified The state is one of the following:
in the service configurations. • Enabled
[no] dns action
Config > Service > GSLB > Policy - DNS Options
tab
Note: To configure the DNS action for a service,
use the action option at the configuration level
for the service. See Table 8, “GSLB Parameters,” on
page 378.
active-only Removes IP addresses from DNS replies when The state is one of the following:
those addresses fail a health check. • Enabled
Note: If none of the IP addresses in the DNS reply • Disabled – This is the default.
pass the health check, the GSLB AX Series does not
use this metric, since it would result in an empty IP
address list.
[no] dns active-only
tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
addition-mx Appends MX records in the Additional section in The state is one of the following:
replies for A records, when the device is configured • Enabled
for DNS proxy or cache mode.
[no] dns addition-mx
tab
best-only Removes all IP addresses from DNS replies except The state is one of the following:
for the address selected as the best address by the • Enabled
GSLB policy metrics.
[no] dns best-only
tab
cache Caches DNS replies and uses them when replying to The state is one of the following:
clients, instead of sending a new DNS request for • Enabled
every client query.
[no] dns cache
The aging time can be
[aging-time seconds | ttl]
1-1,000,000,000 seconds (nearly 32
Config > Service > GSLB > Policy - DNS Options years).
tab
Default: TTL set by the DNS server in
For more information on this option, see “Order in the reply
Which Sticky, Server, Cache, and Proxy Options
Note: If you change the value and later
Are Used” on page 343.
want to restore it to the default, use the
ttl option.
cname-detect Applies GSLB to CNAME records. The state is one of the following:
[no] dns cname-detect • Enabled – This is the default.
Config > Service > GSLB > Policy - DNS Options • Disabled
tab
external-ip Returns the external IP address configured for a ser- The state is one of the following:
vice IP. If this option is disabled, the internal • Enabled – This is the default.
address is returned instead.
• Disabled
[no] dns external-ip
tab
Note: The external IP address must be configured
on the service IP. Use the external-ip option at the
configuration level for the service IP. See Table 8,
“GSLB Parameters,” on page 378.
D e s i g n 393 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
geoloc-action Performs the DNS traffic handling action specified The state is one of the following:
for the client’s geo-location. The action is specified • Enabled
as part of service configuration in a zone.
[no] dns geoloc-action
tab
Note: To configure the DNS action for a service,
use the geo-location action option at the configura-
tion level for the service. See Table 8, “GSLB
Parameters,” on page 378.
geoloc-alias Returns the alias name configured for the client’s The state is one of the following:
geo-location. • Enabled
[no] dns geoloc-alias
tab
geoloc-policy Uses the GSLB policy assigned to the client’s geo- The state is one of the following:
location. • Enabled
[no] dns geoloc-policy
tab
ip-replace Replaces the IP addresses in the DNS reply with the The state is one of the following:
service IP addresses configured for the service. • Enabled
[no] dns ip-replace • Disabled – This is the default.
tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
server Directly responds to Address queries for specific The state is one of the following:
service IP addresses in the GSLB zone. (The AX • Enabled
device still forwards other types of queries to the
DNS server.)
Other defaults:
If you use this option, you do not need to use the
cname-detect option. When a client requests a con- • addition-mx – Disabled
figured alias name, GSLB applies the policy to the • authoritative – The AX device is a
CNAME records. non-authoritative DNS server for
• addition-mx – enables the GSLB AX device to the zone domain.
provide the A record containing the mail server’s • mx – Disabled
IP address in the Additional section, when the
device is configured for DNS server mode.
• authoritative – makes the AX device the authori-
tative DNS server for the GSLB zone, for the
service IPs in which you enable the static option.
If you omit the authoritative option, the AX
device is a non-authoritative DNS server for the
zone domain. The full-list option appends all A
records in the Authoritative section of DNS
replies.
• mx – Provides the MX record in the Answer sec-
tion, and the A record for the mail server in the
Additional section, when the device is configured
for DNS server mode.
To place the server option into effect, you also must
enable the static option on the individual service IP.
[no] dns server addition-mx
[no] dns server authoritative
[full-list]
[no] dns server mx
tab
For more information on this option, see “Order in
Which Sticky, Server, Cache, and Proxy Options
D e s i g n 395 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
GSLB Parameters
sticky Sends the same service IP address to a client for all The state is one of the following:
requests from that client for the service address. • Enabled
[no] dns sticky [/prefix-length] • Disabled – This is the default.
[aging-time minutes]
The default prefix is /32, which causes
The /prefix-length option adjusts the granularity of
the AX device to maintain separate
the feature.
stickiness information for each local
Config > Service > GSLB > Policy - DNS Options DNS server. For example, if two cli-
tab ents use DNS 10.10.10.25 as their
The aging-time option specifies how many minutes local DNS server, and two other clients
a DNS reply remains sticky. You can specify 1- use DNS 10.20.20.99 as their local
65535 minutes. DNS server, the AX maintains sepa-
Note: If you enable the sticky option, the sticky rate stickiness information for each set
time must be as long or longer than the zone TTL. of clients, by maintaining separate
(Use the ttl command at the configuration level for stickiness information for each of the
the zone.) local DNS servers.
For more information on this option, see “Order in The aging time can be 1-65535 min-
Which Sticky, Server, Cache, and Proxy Options utes. Default: 5 minutes
ttl Specifies the value to which the AX Series changes You can specify from 0 to 1000000
the TTL of each DNS record contained in DNS (1,000,000) seconds.
replies received from the DNS for which the Default: 10 seconds
AX Series is a proxy.
[no] dns ttl num
tab
Geo-location Parameters
geo-location Assigns a geographic location to an IP address The location-name can be up to 127
range. GSLB forwards client requests from alphanumeric characters.
addresses within the range to the GSLB site that Default location: None
serves the location. This is an alternative to loading
Default match-first: global
a geo-location database.
[no] geo-location location-name
start-ip-addr [mask ip-mask]
[end-ip-addr]
[no] geo-location match-first
{global | policy}
The match-first parameter specifies whether to
match the requested IP address with the global geo-
location table or with the geo-location table config-
ured in the policy.
The geo-location mapping cannot be configured
using the GUI. To configure the match-first parame-
ter, select Config > Service > GSLB > Policy - Geo-
location tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
These examples implement the GSLB configuration shown in Figure 113
on page 336. The examples assume that the default GSLB policy is used,
without any changes to the policy settings.
CLI Example
Configuration on the GSLB AX Device (GSLB Controller)
The following commands configure a health monitor for the local DNS
server to be proxied:
AX-Controller(config)#health monitor dns-53
AX-Controller(config-health:monitor)#method dns domain example.com
AX-Controller(config-real server)#exit
The following commands configure the DNS proxy:

AX-Controller(config)#slb server dns-1 10.10.10.53
AX-Controller(config-real server)#port 53 udp
AX-Controller(config-real server-node port)#health-check dns-53
AX-Controller(config-real server-node port)#exit
AX-Controller(config-real server)#exit
AX-Controller(config)#slb service-group sg-1 udp
AX-Controller(config-slb service group)#member dns-1:53
AX-Controller(config-slb service group)#exit
AX-Controller(config)#slb virtual-server DNS_SrvA 10.10.10.100
AX-Controller(config-slb virtual-server)#port 53 udp
AX-Controller(config-slb virtual server-slb virtua...)#gslb-enable
AX-Controller(config-slb virtual server-slb virtua...)#service-group sg-1
AX-Controller(config-slb virtual server-slb virtua...)#exit
AX-Controller(config-slb virtual server)#exit
The following commands configure the service IP addresses. The VIP

address and virtual port number of the virtual server in the site AX Series
device’s SLB configuration are used as the service IP address and port num-
ber on the GSLB AX Series device.
AX-Controller(config)#gslb service-ip servicevip1 2.1.1.10
AX-Controller(config-gslb service ip)#port 80 tcp
AX-Controller(config-gslb service ip)#exit
AX-Controller(config)#gslb service-ip servicevip2 3.1.1.10
AX-Controller(config-gslb service ip)#port 80 tcp
AX-Controller(config-gslb service ip)#exit
The following command loads the IANA file into the geo-location database:
AX-Controller(config)#gslb geo-location load iana
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the sites. For each site SLB device,
enter the IP address of the AX Series device that provides SLB at the site.
For the VIP server names, enter the service IP name specified above.
AX-Controller(config)#gslb site usa
AX-Controller(config-gslb site)#slb-dev ax-a 2.1.1.1
AX-Controller(config-gslb site-slb dev)#vip-server servicevip1
AX-Controller(config-gslb site-slb dev)#exit
AX-Controller(config-gslb site)#exit
AX-Controller(config)#gslb site asia
AX-Controller(config-gslb site)#slb-dev ax-b 3.1.1.1
AX-Controller(config-gslb site-slb dev)#vip-server servicevip2
AX-Controller(config-gslb site-slb dev)#exit
AX-Controller(config-gslb site)#exit
The following commands configure the GSLB zone:

AX-Controller(config)#gslb zone a10.com
AX-Controller(config-gslb zone)#service http www
AX-Controller(config-gslb zone-gslb service)#cname www.a10.co.cn
AX-Controller(config-gslb zone-gslb service)#geo-location China www.a10.co.cn
AX-Controller(config-gslb zone-gslb service)#exit
AX-Controller(config-gslb zone)#exit
At the configuration level for the service (www), the CNAME

www.a10.co.cn is configured, and the CNAME is associated with geo-loca-
tion China. If a client’s IP address is in the range for the China geo-location,
GSLB sends the CNAME www.a10.co.cn in the DNS reply.
The following command enables the GSLB protocol:

AX-Controller(config)#gslb protocol enable controller
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration on Site AX Device AX-A
The following commands configure SLB on site AX device AX-A in
Figure 113 on page 336:
Site-AX-A(config)#slb server www 2.1.1.2
Site-AX-A(config-real server)#port 80 tcp
Site-AX-A(config-real server-node port)#exit
Site-AX-A(config-real server)#exit
Site-AX-A(config)#slb server www2 2.1.1.3
Site-AX-A(config-real server)#port 80 tcp
Site-AX-A(config-real server-node port)#exit
Site-AX-A(config-real server)#exit
Site-AX-A(config)#slb service-group www tcp
Site-AX-A(config-slb service group)#member www:80
Site-AX-A(config-slb service group)#member www2:80
Site-AX-A(config-slb service group)#exit
Site-AX-A(config)#slb virtual-server www 2.1.1.10
Site-AX-A(config-slb virtual server)#port 80 http
Site-AX-A(config-slb virtual server-slb virtua...)#service-group www
Site-AX-A(config-slb virtual server-slb virtua...)#exit
Site-AX-A(config-slb virtual server)#exit
Note: The virtual server IP address must be the same as the GSLB service IP
address configured on the GSLB AX device.
The following command enables the GSLB protocol:

Site-AX-A(config)#gslb protocol enable device
Configuration on Site AX Device AX-B

The following commands configure SLB and enable the GSLB protocol on
site AX device AX-B:
Site-AX-B(config)#slb server www 3.1.1.2
Site-AX-B(config-real server)#port 80 tcp
Site-AX-B(config-real server-node port)#exit
Site-AX-B(config-real server)#exit
Site-AX-B(config)#slb server www2 3.1.1.3
Site-AX-B(config-real server)#port 80 tcp
Site-AX-B(config-real server-node port)#exit
Site-AX-B(config-real server)#exit
Site-AX-B(config)#slb service-group www tcp
Site-AX-B(config-slb service group)#member www:80
Site-AX-B(config-slb service group)#member www2:80
Site-AX-B(config-slb service group)#exit
Site-AX-B(config)#slb virtual-server www 3.1.1.10
Site-AX-B(config-slb virtual server)#port 80 http
Site-AX-B(config-slb virtual server-slb virtua...)#service-group www
Site-AX-B(config-slb virtual server-slb virtua...)#exit
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Site-AX-B(config-slb virtual server)#exit
Site-AX-B(config)#gslb protocol enable device
GUI Example
Configuration on the GSLB AX Device (GSLB Controller)
Configure a Health Monitor for the DNS Proxy

2. On the menu bar, select Health Monitor.
3. Click Add.
4. Enter a name for the monitor in the Name field.
5. On the Method tab, select DNS from the Type drop-down list.
6. In the Domain field, enter the domain name. (Generally, this is the same
as the GSLB zone name you will configure.)
Configure the DNS Proxy

1. Begin configuring the proxy:
a. Select Config > Service > GSLB.
b. On the menu bar, select DNS Proxy.
c. Click Add.
d. Enter a name for the proxy in the Name field.
e. In the IP Address field, enter the IP address that will be advertised
as the authoritative DNS server for GSLB zone.
Note: The GUI will not accept the configuration if the IP address you enter here
is the same as the real DNS server IP address you enter when configuring
the service group for this proxy. (below).
f. On the GSLB Port tab, click Add. The GSLB Port tab appears.
2. Configure the service group:

a. In the Service Group drop-down list, select “create” to create a ser-
vice group. (See Figure 115 on page 401.)
The Service Group tab appears.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
b. Enter the service group information. For this example, enter the fol-
lowing:
• Name – gslb-proxy-sg-1
• Port type – UDP
• Load-balancing metric (algorithm) – Round-Robin
• Health Monitor – “default”
c. On the Server tab, enter the DNS server’s real IP address in the
Server field, and enter the DNS port number in the port field.
d. Click Add. The DNS port appears in the list. (See Figure 116 on
page 402.)
e. Click OK. The GSLB Port tab reappears. In the service drop-down
list, the service group you just configured is selected. (See
Figure 117 on page 402.)
3. Finish configuration of the proxy:

a. Click OK. The Proxy tab reappears. (See Figure 118 on page 403.)
b. Click OK. The DNS proxy appears in the DNS Proxy table. (See
Figure 119 on page 403.)
FIGURE 115 Configure > Service > GSLB > DNS Proxy
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 116 Configure > Service > GSLB > DNS Proxy - service group
configuration
FIGURE 117 Configure > Service > GSLB > DNS Proxy - service group
selected
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 118 Configure > Service > GSLB > DNS Proxy - GSLB port
configured
FIGURE 119 Configure > Service > GSLB > DNS Proxy - DNS proxy
configured
Load the IANA Geo-location Database

2. On the menu bar. select Geo-location > Import.
3. On the Load/Unload tab, enter “iana” in the File field. Leave the Tem-
plate field blank.
4. Click Add.
Configure Services
2. On the menu bar, select Service IP.
3. Click Add.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
4. Enter the service name and IP address. For this example, enter the fol-
lowing:
• Name – servicevip1
• IP Address – 2.1.1.10 (This is the VIP address of a site. Configure a
separate GSLB service IP for each SLB VIP.)
5. If needed, assign an external IP address to the service IP. The external IP

address allows a service IP that has an internal IP address to be reached
from outside the internal network.
6. Add the service port(s):

a. Enter the port number and select the protocol (TCP or UDP).
b. Optionally, select a health monitor.
c. Click Add. The service port appears in the service port list.
For this example, add TCP port 80 and leave the health monitor unse-
lected.
(See Figure 120 on page 404.)
7. Click OK.
8. Repeat for each service IP.
FIGURE 120 Config > Service > GSLB > Service IP
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configure Sites
2. On the menu bar, select Site.
3. Click Add.
4. Enter the site name.
5. On the SLB-Device tab, enter information about the AX devices that

provide SLB for the site:
a. Click Add.
b. Enter a name for the device.
c. Enter the IP address at which the GSLB AX device will be able to
reach the site AX device.
d. To add a service to this SLB device, select it from the drop-down list
in the VIP server section and click Add. Repeat for each service.
For this example, enter the following:
• Name – AX-A
• IP Address – 2.1.1.1 (This is the IP address of the site AX device
that provides SLB for the site.)
• GSLB Service – Add a service IP by selecting it from the drop-
down list and clicking Add. For this example, add “servicevip1”
to site “usa”.
6. On the IP-Server tab, add services to the site. Select a service from the
drop-down list and click Add. Repeat for each service.
7. To manually map a geo-location name to the site, enter the geo-location

name on the Geo-location tab and click Add.
8. Click OK. The site appears in the Site table.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 121 Configure > Service > GSLB > Site - SLB Device
FIGURE 122 Configure > Service > GSLB > Site - site parameters selected
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configure a Zone
2. On the menu bar, select Zone.
3. Click Add.
4. Enter the zone name in the Name field.
5. On the Service tab, click Add. (See Figure 123 on page 408.)
The service configuration tabs appear.
6. In the Service field, enter the service name.
7. Select the service type from the Port drop-down list.
8. Add the services:

a. On the Service tab, click Add.
b. Enter name for the service (for example, “www”).
c. Select the service type from the Port drop-down list.
d. Configure additional options, if applicable to your deployment. (See
Table 8, “GSLB Parameters,” on page 378.)
e. Click OK.
f. Repeat for each service.
9. Click OK. The zone appears in the GSLB zone list.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 123 Configure > Service > GSLB > Zone
FIGURE 124 Configure > Service > GSLB > Zone
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Enable the GSLB Protocol
3. Select Enabled next to Run GSLB as Controller.
4. Click OK.
Configuration on Site AX Devices
SLB configuration is the same with or without GSLB, and is not described
here.
To enable the AX device to run GSLB as a site AX device, perform the fol-
lowing steps on each site AX device:
3. Select Enabled next to Run GSLB as Site SLB Device.
4. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
RAM Caching
You can use the AX device as a transparent cache server, along with the
device’s many other uses.
Overview
The RAM Cache is a high-performance, in-memory Web cache that by
default caches HTTP responses (RFC 2616 compliant). The RAM Cache
can store a variety of static and dynamic content and serve this content
instantly and efficiently to a large number of users.
Caching of HTTP content reduces the number of Web server transactions

and hence the load on the servers. Caching of dynamic content reduces the
latency and the computation cost of generating dynamic pages by applica-
tion servers and database servers. Caching can also result in significant
reduction in page download time and in bandwidth utilization.
RAM caching is especially useful for high-demand objects on a website, for

static content such as images, and when used in conjunction with compres-
sion to store compressed responses, eliminating unnecessary overhead.
RFC 2616 Support

In general, AX RAM caching conforms with the cache requirements
described in RFC 2616, “Hypertext Transfer Protocol -- HTTP/1.1”, in sec-
tions 13 and 14.
AX RAM caching considers HTTP responses with the following status

codes to be cacheable:
• 200 – OK
• 203 – Non-Authoritative Response
• 300 – Multiple Choices
• 301 – Moved Permanently
• 302 – Found (Only if Expires header is also present)
• 410 – Gone
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
However, if there is no Content-Length header, the response will not be
cached.
Warning headers are not supported.
Dynamic Caching
You can enhance RAM caching performance with dynamic RAM caching.
Dynamic RAM caching is useful in situations where the response to a client
request can be used multiple times before the response expires. Here are
some examples where dynamic RAM caching is beneficial:
• The same response is usable by multiple users within a certain period of
time. In this case, dynamic RAM caching is useful even if the cache
expiration period is very small, if enough users access the response
within that period. For example, dynamic RAM caching is beneficial for
a hierarchical directory that is generated dynamically but presents the
same view to all users that request it.
• The response is usable by only a single user but the user accesses it mul-
tiple times. For example, if the response generated in one session can be
used unchanged in a second session.
Host Verification
RAM caching has an optional host verification feature. Host verification
supports multiple name-based virtual hosts. Name-based virtual hosts are
host names that share the same IP address. For example, the real server IP
address 192.168.209.34 could be shared by the following virtual hosts:
• www.abc.com
• www.xyz.com
By default, host verification is disabled. When the AX device receives the

server response for cacheable content, the AX device caches the content
along with the URI, but not the host name. For example, if a client requests
http://www.abc.com/index.html, the AX device caches the content and
“/index.html” but does not cache “abc.com”. If another request is received,
for http://www.xyz.com/index.html, the AX device serves the same content.
If you enable host verification, the AX device caches the host name along
with the URI. For example, for http://www.abc.com/index.html, the AX
device caches the content, “/index.html”, and “abc.com”. If a new request is
received, for http://www.xyz.com/index.html, the AX device checks the
cache for content indexed by both “/index.html” and “xyz.com”. The AX
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
device serves the content to the client only if the content was cached for
“xyz.com”.
Support for no-cache and max-age=0 Cache-Control Headers

According to RFC 2616, either of the following Cache-Control headers in a
request should make the cache (the AX device) reload the cached object
from the origin server:
• Cache-Control: no-cache
• Cache-Control: max-age=0
However, for security, support for these headers is disabled by default. Thee
headers can make the AX device vulnerable to Denial of Service (DoS)
attacks.
To enforce strict RFC compliance, you can enable support for the headers.
RAM Caching Notes

• In the current release, compressed responses from real servers are not
supported.
• In the current release, sessions served from the RAM cache increment
the TCP Half Open counter in show session command output. This can
cause the dynamic Syn-Cookie feature (on models AX 2200, AX 3100,
and AX 3200) to be activated prematurely.
• The AX device does not support the HTTP header
“Cache-Control: only-if-cached” directive.
• The AX device caches responses that contain the “Vary: Accept-Encod-
ing” header. However, the AX device will cache a response that has a
Vary header only if the header’s value is Accept-Encoding
(“Vary: Accept-Encoding”). Responses that have a Vary header with any
other value are considered to be non-cacheable and therefore are not
cached.
• RAM caching can be used with compression on the same virtual port. In
this case, compressed objects are cached and served to clients. The AX
device will serve compressed objects from the cache even if a client
request does not contain the “Accept-Encoding” HTTP header to indi-
cate willingness to accept compressed content. This should not affect
current Web browsers, since they accept compressed content by default.
However, if a client is running an old browser that does not accept com-
pressed content, the AX device will send compressed content anyway.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring RAM Caching

To configure RAM caching:
1. Add the real servers that serve the content to be cached, if not already
configured.
2. Configure a service group and add the real servers to it, if not already
configured.
3. Configure a cache template with settings for the type and size of content
to be cached. Optionally, configure dynamic caching policies.
4. Configure the virtual server, and bind the service group and cache tem-
plate to the service ports for which caching will be provided.
USING THE GUI
To Configure RAM Caching

2. On the menu bar, select Application > RAM Caching.
3. Click on the template name or click Add to create a new one.
4. Enter a name for the template, if you are creating a new one.
5. Enter or change any settings for which you do not want to use the
default settings.
6. To configure dynamic caching polices, use the applicable set of steps

below.
To configure a cache policy:
a. In the URI field, enter the portion of the URI string to match on.
b. Select Cache from the Action drop-down list. The Duration field
appears.
c. By default, the content is cached for the number of seconds speci-
fied in the Age field of the RAM Caching tab. To override the aging
period, specify the number of seconds in the Duration field.
d. Click Add.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure a no-cache policy:
b. Select No Cache from the Action drop-down list.
c. Click Add.
To configure an invalidate policy:
b. Select Invalidate from the Action drop-down list. The Pattern field
appears. Enter the portion of the URL string on which to match. For
example, to invalidate “/list” objects when the URL contains “/add”,
enter “/add” (without the quotation marks).
7. Click OK.
To Monitor RAM Caching

Use the following options:
• Monitor > Service > Application > RAM Caching > Details
• Monitor > Service > Application > RAM Caching > Objects
• Monitor > Service > Application > RAM Caching > Replacement
The Details menu option displays RAM caching statistics. The Objects
option displays cached entries. The Replacement option shows entry
replacement information.
To Export Web Log Archives

1. Select Monitor > Service > Application.
2. On the menu bar, select RAM Caching > Logs.

The list of log archive files appears.
3. Click on the checkbox next to the filename of each log file you want to
export.
4. Click Export.
To delete log archive files, click the checkbox next to each file you want to
delete, and click Delete.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
The commands for configuring the real servers, service group, and virtual
server are the same as those used for configuring other types of SLB. These
configuration items have no commands or options specific to RAM caching.
To configure a RAM caching template, use the following commands:
[no] slb template cache template-name

mand changes the CLI to the configuration level for the template, where the
following commands specific to RAM caching are available:
[no] accept-reload-req
This command enables support for the following Cache-Control headers:
When support for these headers is enabled, either header causes the AX
device to reload the cached object from the origin server.
[no] age seconds

This command specifies how long a cached object can remain in the AX
RAM cache without being requested. You can specify 1-999999 seconds
(about 11-1/2 days). The default is 3600 seconds (1 hour).
[no] default-policy-nocache
This command changes the default cache policy in the template from cache
to nocache. This option gives you tighter control over content caching.
When you use the default no-cache policy, the only content that is cached is
cacheable content whose URI matches an explicit cache policy.
[no] max-cache-size MB
This command specifies the size of the AX RAM cache. You can specify
1-512 MB. The default is 10 MB.
The total size of all RAM caches combined can be 512 MB on systems with
2 GB of memory and 1024 MB on systems with 4 GB of memory. (To dis-
play the amount of memory your system has, enter the show version com-
mand.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
[no] max-content-size bytes
This command specifies the maximum object size that can be cached. The
AX device will not cache objects larger than this size. You can specify
1-8000000 bytes (8 MB). The default is 50000 bytes (50 Kbytes).
[no] min-content-size bytes

This command specifies the minimum object size that can be cached. The
AX device will not cache objects smaller than this size. You can specify
1-8000000 bytes (8 MB). The default is 500 bytes (1/2 Kbyte).
[no] replacement-policy LFU

This command specifies the policy used to make room for new objects
when the RAM cache is full. The policy supported in the current release is
Least Frequently Used (LFU). When the RAM cache becomes more than
90% full, the AX device discards the least-frequently used objects to ensure
there is sufficient room for new objects. This is the default behavior and is
the only supported option in the current release.
Dynamic Caching Command

Dynamic caching is performed using caching policies. To configure a cach-
ing policy, use the following command at the configuration level for a RAM
caching template:
[no] policy uri pattern
{cache [seconds] | nocache |
invalidate inv-pattern}
The pattern option specifies the portion of the URI string to match on.
The other options specify the action to take for URIs that match the pattern:
• cache [seconds] – Caches the content. By default, the content is cached
for the number of seconds configured in the template (set by the age
command). To override the aging period set in the template, specify the
number of seconds with the cache command.
• nocache – Does not cache the content.
• invalidate inv-pattern – Invalidates the content that has been cached for
inv-pattern.
If a URI matches the pattern in more than one policy command, the policy
command with the most specific match is used.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Host Verification Command
[no] verify-host
This command enables the AX device to cache the host name in addition to
the URI for cached content. Use this command if a real server that contains
cacheable content will host more than one host name (for example,
www.abc.com and www.xyz.com).
Show Commands
To display client sessions that are using cached content, use the following
command:
show session
To display RAM caching statistics, use the following command:
show slb cache
To display cached objects, use the following command:
show slb cache entries vip-name port-num
To clear RAM caching statistics counters, use the following command:
clear slb cache stats [vip-name port-num]
To clear cached objects, use the following command:
clear slb cache entries vip-name port-num
To display RAM caching memory usage, use the following command:
show slb cache memory-usage
CLI CONFIGURATION EXAMPLES
Basic Configuration
The commands in this example enable RAM caching for virtual service port
TCP 80 on VIP “cached-vip”.
The following commands add a RAM caching template. In this example,

the default template settings are used.
AX(config)#slb template cache ramcache
AX(config-RAM caching template)#exit
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure the real servers.
AX(config)#slb server 192.168.90.34
AX(config)#slb server 192.168.90.35
The following commands configure the service group.

AX(config)#slb service-group cached-group
AX(config-slb service group)#member 192.168.90.34:80
The following commands configure the virtual server and bind the RAM
caching template and the service group to virtual HTTP service port 80.
AX(config)#slb virtual-server cached-vip 10.10.10.101
AX(config-slb virtual server-slb virtua...)#service-group cached-group
AX(config-slb virtual server-slb virtua...)#template cache ramcache
The following command shows client sessions. Asterisks ( * ) in the Reverse

Source and Reverse Dest fields indicate that the AX device directly served the
requested content to the client from the AX RAM cache. In this case, the session is
actually between the client and the AX device rather than the real server.
AX(config-slb virtual server-slb virtua...)#show session
Traffic Type Total
--------------------------------------------
TCP Established 4328
TCP Half Open 39026
UDP 0
Non TCP/UDP IP sessions 0
Other 0
Reverse NAT TCP 0
Reverse NAT UDP 0
Free Buff Count 0
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Curr Free Conn 1923655
Conn Count 5287134
Conn Freed 5113720
tcp syn half open 0
Prot Forward Source Forward Dest Reverse Source Reverse Dest Age
---------------------------------------------------------------------------------------
Tcp 10.10.10.61:25058 10.10.10.10:80 * * 600
Tcp 10.10.10.60:9239 10.10.10.11:80 * * 600
Tcp 10.10.10.61:1838 10.10.10.10:80 * * 600
Tcp 10.10.10.65:47834 10.10.10.11:80 * * 600
Tcp 10.10.10.62:55613 10.10.10.11:80 * * 600
Tcp 10.10.10.57:9233 10.10.10.11:80 * * 600
The following command shows RAM caching statistics.

AX(config-slb virtual server-slb virtua...)#show slb cache
Total
---------------------------------------------------------------
Cache Hits 0
Cache Misses 6
Memory Used 27648
Entries Cached 6
Entries Replaced 0
Entries Aged Out 0
Entries Cleaned 0
Total Requests 6
Cacheable Requests 6
No-cache Requests 0
No-cache Responses 0
Revalidation Successes 0
Revalidation Failures 0
Content Too Big 0
Content Too Small 0
Cache add skips 0
Entry create failures 0
Double enqueues 0
Double deletes (hlist) 0
Double deletes (list) 0
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following command shows cached objects.
AX#show slb cache entries cached-vip 80
cahed-vip:80
Host Object URL Bytes Status Expires in
---------------------------------------------------------------------------------------
10.20.0.120 /static4K/4K8663.txt 4310 FR 2968 s
10.20.0.120 /static4K/4K8662.txt 4325 FR 2968 s
10.20.0.120 /static4K/4K8661.txt 4325 FR 2968 s
The Status column indicates the status. In this example, all entries are fresh
(FR). For more information, see the AX Series CLI Reference.
Dynamic Caching Configuration

Here is an example application of dynamic RAM caching. Web site x.y.com
displays a frequently requested list page, and also serves private pages to
individual clients based on additional requests from clients. Clients also can
add or delete content on the list page.
http://x.y.com/list
http://x.y.com/private?user=u1
http://x.y.com/add?a=p1&b=p2
http://x.y.com/del?c=p3
Dynamic RAM caching policies can be used to effectively manage caching

for this site.
The /list URI is visited by many users and therefore should be cached, so
long as the content is current. However, the /private URI contain private
data for a specific user, and should not be cached.
The /add and /del URLs modify the content of the list page. When either
type of URI is observed by the AX device, the currently cached content for
the /list URI should be invalidated, so that new requests for the URI are not
served with a stale page.
The following commands implement the dynamic RAM caching configura-

tion described above.
AX(config)#slb template cache ram-cache
AX(config-RAM caching template)#policy uri /list cache 3000
AX(config-RAM caching template)#policy uri /private nocache
AX(config-RAM caching template)#policy uri /add invalidate /list
AX(config-RAM caching template)#policy uri /del invalidate /list
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The policy that matches on “/list” caches content for 50 minutes. The policy
that matches on “/private” does not cache content. The policies that match
on “/add” and “/del” invalidate the cached “/list” content.
Configuration To Flush Specific Cache Entries

If you need to flush specific entries from the RAM cache, you can do so
using an invalidate policy. Here is an example:
AX(config)#slb template cache ram-cache
AX(config-RAM caching template)#policy uri /story cache 3600
AX(config-RAM caching template)#policy uri /flush invalidate /story
This policy is configured to flush (invalidate) all cached entries that have “/
story” in the URI. The policy is activated when a request is received with
the URI “/flush”.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
High Availability
This chapter describes High Availability (HA) and how to configure it.
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 config-
ured 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: Both AX devices in an HA pair should be the same model and should be
running the same software version. Using different AX models or differ-
ent software versions in an HA pair is not supported.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Layer 3 Active-Standby HA
Figure 125 shows an example of an Active-Standby configuration.
FIGURE 125 Active-Standby HA
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 AX ID of AX2 is 2. An AX
device must have an HA ID, which can be 1 or 2. The ID must be differ-
ent 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 440.)
• 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.
• 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 main-
tained without interruption.
(For a complete list of configurable HA parameters, see “HA Configuration

Parameters” on page 445.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Layer 3 Active-Active HA
Figure 126 shows an example of an Active-Active configuration.
FIGURE 126 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 con-
figuration, 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
This configuration is similar to the configuration for Active-Standby shown
in Figure 125, 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Layer 2 Active-Standby HA (Inline Deployment)

AX devices support Layer 2 hot standby inline deployment. Inline deploy-
ment 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 127 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Each real server is connected to the router pair through a Layer 2 switch.
Neither the Layer 2 switches nor the routers are running Spanning Tree Pro-
tocol (STP). The network does not have any Layer 2 loops because the
Layer 2 switches are not connected directly together, and the routers do not
forward Layer 2 traffic.
If a pair of 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
FIGURE 128 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
• IPv6 traffic is not supported.
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. Like-
wise, 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 128 on page 430, 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 pre-
ferred HA port.
3. If the preferred HA port selected by 1. or 2. above goes down, the HA

interface with the lowest port number is used. If that port also goes
down, the HA interface with the next-lowest port number is used, and so
on.
HA heartbeat messages are not restricted to the preferred HA port. Heart-

beat messages are sent out all HA interfaces unless you disable the mes-
sages on specific interfaces.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Note: The preferred port must be added as an HA interface and heartbeat mes-
sages must be enabled on the interface.
Port Restart
When a transition from Standby to Active occurs because the formerly

Active 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 128 on page 430, 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. How-
ever, if the transition from Active to Standby does not involve failure of the
router's link with AX1, the router does not flush its learned MAC entries on
the link. As a result, the router might continue to send traffic for down-
stream devices through the router's link with AX1. Since AX1 is now the
Standby, it drops the traffic, thereby causing reachability issues.
For example, if you administratively force a failover by changing the HA

configurations of the 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.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 129 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 traf-

fic. 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.
• IPv6 traffic is not supported.
HA Messages
The AX devices in an HA pair communicate their HA status with the fol-
lowing types of messages:
• HA heartbeat messages
• Gratuitous ARP requests and replies
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 net-
working 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 Configu-
ration Parameters” on page 445.)
Gratuitous ARPs
When an AX transitions from Standby to Active, the newly Active AX

device sends gratuitous ARP requests and replies (ARPs) for the IP address
under HA control. Gratuitous ARPs 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 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 immediately upon becom-
ing the Active AX device. To make sure ARPs are being received by the tar-
get addresses, the AX device re-sends the ARPs 4 additional times, at 500-
millisecond intervals.
After this, the AX device sends gratuitous ARPs every 30 seconds to keep
its IP information current.
The ARP retry count is configurable. (See “HA Configuration Parameters”

on page 445.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
HA Interfaces
When configuring HA, you specify each of the interfaces that are HA inter-
faces. An HA interface is an interface that is connected to an upstream
router, a real server, or the other 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: A maximum of 16 HA interfaces are supported on an 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 multi-
cast packets.
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:
• 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 con-
figured, the HA interfaces for which a type has not been configured are not
included in the HA interface status determination.
During selection of the active AX, the AX with the highest state becomes
the active AX and all HA interfaces on that AX become active. For exam-
ple, if one AX is UP and the other AX is only Partially Up, the AX that is
UP becomes the active AX.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
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 main-
tained 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 syn-

chronization does not apply to DNS sessions. Since these sessions are typi-
cally very short lived, there is no benefit to synchronizing them. Likewise,
session synchronization does not apply to static NAT sessions. Synchroniza-
tion of these sessions is not needed since the newly Active AX device will
create a new flow for the session following failover.
To enable session synchronization, see “Enabling Session Synchronization”

on page 476.
Session synchronization is required for config sync. Config sync uses the
session synchronization link. (For more information, “Synchronizing Con-
figuration Information” on page 477.)
Note: Session synchronization is also called “connection mirroring”.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
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 dura-
tion 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 time-
out expires, a failover occurs. The timeout can be 2-600 seconds. You must
specify the timeout. Although there is no default, A10 recommends trying
30 seconds.
This HA checking method provides a passive means to detect network

health, whereas heartbeat messages are an active mechanism. You can use
either or both methods to check VLAN health. If you use both methods on a
VLAN, A10 recommends that you specify an HA checking interval (time-
out) that is much longer than the heartbeat interval.
For a configuration example, see “VLAN-Based Failover Example” on

page 471.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
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 472.
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
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 sub-
tracted from the HA group’s priority is re-added. If this results in the prior-
ity value being higher than on the other 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 vir-
tual server to HA group 31, also assign any floating IP addresses and IP
Source NAT pools used by the virtual server to HA group 31.
For a configuration example, see “VIP-Based Failover Example” on

page 474.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 130.
FIGURE 130 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 131 shows the events that can cause an HA failover.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
FIGURE 131 HA Failover
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 436.)
• VLAN-based failover is configured and the VLAN becomes inactive.
(See “VLAN-based Failover” on page 438.)
• Gateway-based failover is configured and the gateway becomes unavail-
able. (See “Gateway-based Failover” on page 438.)
• 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 439.)
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
HA Sets
Optionally, you can provide even more redundancy by configuring multiple
sets of HA pairs.
FIGURE 132 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 10 on page 445.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
HA Configuration Parameters
Table 10 lists the HA parameters.
TABLE 10 HA Parameters
Global HA Parameters
HA ID HA ID of the AX device, and HA set to which the HA ID: 1 or 2
and AX device belongs. HA set ID: 1-7
HA set ID The HA ID uniquely identifies the AX device Default: Neither parameter is set
within the HA pair.
The HA set ID specifies the HA set to which the AX
device belongs. This parameter is applicable to con-
figurations that use multiple AX pairs.
[no] ha id {1 | 2} [set-id num]
Config > HA > Setting > HA Global - General tab
HA group ID Uniquely identifies the HA group on an individual HA group ID: 1-31
AX device. Priority: 1 (low priority) to 255 (high
The priority value can be used during selection of priority
the Active AX device. (See“How the Active AX Default: not set
Device Is Selected” on page 440.)
[no] ha group group-id priority num
Config > HA > Setting > HA Global - Group tab
Floating IP IP address that downstream devices should use as Default: not set
address 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.
[no] floating-ip ipaddr
ha-group group-id
Config > HA > Setting > HA Global - Floating IP
Address tab
D e s i g n 445 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
TABLE 10 HA Parameters (Continued)
HA interfaces Interfaces used for HA management. AX Ethernet interfaces
HA heartbeat messages are sent on HA interfaces, Default: not set
unless you use the option to disable the messages.
At least one HA interface must be specified. If the
interface is tagged, then a VLAN ID must be speci-
fied if heartbeat messages are enabled on the inter-
face.
If you specify the interface type (server, router, or
both), changes to the interface state can control
failover. (See “HA Interfaces” on page 436 and
“How the Active AX Device Is Selected” on
page 440.)
[no] ha interface ethernet port-num
[router-interface |
server-interface | both]
Config > Network > Interface > LAN - Select the
interface and then click the HA tab.
VLAN-based Enables the AX device to change its HA status Valid VLAN ID
HA based on the health of a VLAN. Default: not set
When HA checking is enabled for a VLAN, the The timeout can be 2-600 seconds.
active AX device in the HA pair monitors traffic
Although there is no default timeout,
activity on the VLAN. If there is no traffic on the
A10 recommends trying 30 seconds.
VLAN for half the duration of a configurable time-
out, the 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.
[no] ha check vlan vlan-id timeout
seconds
Config > HA > Setting > HA Global - Status Check
tab
Gateway-based Enables the AX device to change its HA status IP address of the gateway
HA based on the health of a gateway router. Default: not set
If the gateway fails a Layer 3 (ICMP) health check, Additional configuration is required.
the AX device changes its HA status to Down. If the (See “Gateway-based Failover” on
HA status of the other AX device is higher than page 438.)
Down, a failover occurs.
[no] ha check gateway ipaddr
Config > HA > Setting > HA Global - Status Check
tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Session synchro- Enables the AX devices to share information about IP address of the other AX device
nization active client sessions. If a failover occurs, client ses- Default: not set
(Also called sions continue uninterrupted. The Standby AX
“connection mir- device, when it becomes Active, uses the session
roring”) information it received from the Active AX device
before the failover to continue the sessions without
terminating them.
To enable session synchronization, specify the IP
address of the other AX device in the HA pair.
Session synchronization does not apply to DNS ses-
sions. Since these sessions are typically very short
lived, there is no benefit to synchronizing them.
Note: This option also requires session synchroni-
zation to be enabled on the individual virtual service
ports. (See “HA Parameters for Virtual Service
Ports” below.)
[no] ha conn-mirror ip ipaddr
Pre-emption Controls whether failovers can be caused by config- Enabled or disabled
uration changes to HA priority or HA ID. Default: disabled
[no] ha preemption-enable
HA heartbeat Interval at which the AX device sends HA heartbeat 1-255 units of 100 milliseconds
interval messages on its HA interfaces. (ms) each
[no] ha time-interval Default: 200 ms
100-msec-units
Retry count Number of HA heartbeat intervals the Standby 2-255
device will wait for a heartbeat message from the Default: 5
Active AX device before failing over to become the
Active AX device.
[no] ha timeout-retry-count num
ARP repeat Number of additional gratuitous ARPs, in addition 1-255
count to the first ones, an AX sends after transitioning Default: 4 additional gratuitous
from Standby to Active in an HA configuration.
ARPs, for a total of 5
[no] ha arp-retry num
D e s i g n 447 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Global HA Parameters for Layer 2 Inline Mode
Inline mode state Enables Layer 2 inline mode and, optionally, speci- Enabled or disabled
fies the HA interface to use for session synchroniza- Default: disabled
tion and for management traffic between the AX
When inline mode is enabled, the pre-
devices.
ferred port is selected as described in
[no] ha inline-mode “Preferred HA Port” on page 431.
[preferred-port port-num]
Config > HA > Setting - HA Inline Mode tab
Restart port list List of Ethernet interfaces on the previously Active AX Ethernet interfaces
AX device to toggle (shut down and restart) follow- Default: not set
ing HA failover.
[no] ha restart-port-list ethernet
port-list
Port restart time Amount of time interfaces in the restart port list 1-100 units of 100 milliseconds (ms)
remain disabled following a failover. Default: 20 units of 100 ms (2 sec-
[no] ha restart-time 100-msec-units onds)
Global HA Parameters for Layer 3 Inline Mode
Inline mode state Enables Layer 3 inline mode. Enabled or disabled
[no] ha l3-inline-mode Default: disabled
Note: This option is not configurable using the
GUI.
HA Parameters for Virtual Servers
HA group ID HA group ID for a virtual server. 1-31
This is required to enable HA for the VIP. Default: not set
[no] ha-group group-id
Config > Service > SLB > Virtual Server
Server weight Weight value assigned to real servers bound to the 1-255
virtual server. Not set
The weight is used for VIP-based failover. (See
“VIP-based Failover” on page 439.)
[no] ha-dynamic server-weight
Config > Service > SLB > Virtual Server - Select
the HA group, then select the Dynamic Server
Weight.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
HA Parameters for Virtual Service Ports
Session Enables active client sessions on this virtual port to Enabled or disabled
synchronization continue uninterrupted following a failover. Default: disabled
(Also called Note: This option also requires session synchroni-
“connection mir- zation to be enabled globally. (See “Global HA
roring”) Parameters” above.)
[no] ha-conn-mirror
Config > Service > SLB > Virtual Server - Port tab
HA Parameters for Firewall Load Balancing (FWLB)
Note: For an example of an FWLB HA configuration, see “Firewall Load Balancing” on page 255.
HA group ID HA group ID for a virtual firewall or virtual firewall 1-31
port. Default: not set
Server (for virtual firewall)
Server - Port tab (for virtual firewall port)
Session Enables active client sessions on this virtual firewall Enabled or disabled
synchronization port to continue uninterrupted following a failover. Default: disabled
Note: This option also requires session synchroni-
zation to be enabled globally. (See “Global HA
Parameters” above.)
[no] ha-conn-mirror
Server (for virtual firewall)
Server - Port tab (for virtual firewall port)
HA Parameters for IP Network Address Translation (NAT) Pools
HA group ID HA group ID for IP NAT. 1-31
Option with ip nat pool, ipv6 nat pool, or ip nat Default: not set
inside command: ha-group group-id
Config > Service > IP Source NAT > IPv4 Pool
Config > Service > IP Source NAT > IPv6 Pool
Config > Service > IP Source NAT > NAT Range
D e s i g n 449 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Layer 3 HA
To configure Layer 3 HA:
1. Configure the following global HA parameters:
• HA ID
• HA group ID and priority. For an Active-Standby configuration,
configure one group ID. For Active-Active, configure multiple HA
group IDs.
• Floating IP address (optional)
• Session synchronization (optional)
• HA pre-emption (optional)
2. Configure the HA interfaces.
3. Add each virtual server to an HA group.
4. If session synchronization is globally enabled, enable it on the individ-

ual virtual ports whose client sessions you want to synchronize.
5. If IP NAT pools are configured, add each pool to an HA group.
USING THE GUI
Configuring Global HA Parameters

1. Select Config > 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. On the Group tab, 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
3. On the Floating IP Address tab, configure the floating IP addresses for
the HA groups.
a. Select an HA group from the Group Name drop-down list.
b. Select the address type (IPv4 or IPv6).
c. Enter the floating IP address for the group.
d. Click Add.
e. If you are configuring Active-Active, select the next HA group from
the Group Name drop-down list, and repeat the previous steps.
4. Click OK.
Configuring HA Interfaces
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 436.)
a. Click on the interface number.
b. On the HA tab, select Enabled next to HA Enabled.
c. To specify the interface type, select one of the following or leave the
setting None:
• Router-Interface
• Server-Interface
• Both
d. To enable HA heartbeat messages, select Enabled next to Heartbeat.
e. To restrict the HA heartbeat messages to a specific VLAN, enter the
VLAN ID in the VLAN field.
f. Click OK.
Configuring HA Parameters on a Virtual Server

2. On the menu bar, select Virtual Server.
3. Click on the virtual server name or click Add to add a new one.
4. On the General tab, select the HA group ID from the HA Group drop-
down list.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Note: The Dynamic Server Weight option is used for VIP-based failover. For
information, see “VIP-based Failover” on page 439.
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. On the Port tab, click Add to add a new virtual service port or select
an existing port and click Edit. The Virtual Server Port tab appears.
b. Select enabled next to HA Connection Mirror.
c. Click OK. The service port list re-appears.
Note: The GUI does not support enabling connection mirroring on some types
of service ports. However, you can enable connection mirroring for these
service types using the CLI.
7. Click OK to complete configuration of the virtual server.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
HA Configuration of AX1
FIGURE 133 Config > HA > Setting > HA Global
FIGURE 134 Config > Service > SLB > Virtual Server (VIP1)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
HA Configuration of AX2
FIGURE 136 Config > HA > Setting
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI

1. To configure the global HA parameters, use the following commands at
the global configuration level of the CLI:
ha id {1 | 2} [set-id num]
ha group group-id priority num
floating-ip ipaddr ha-group group-id
ha interface ethernet port-num
[router-interface | server-interface | both]
ha conn-mirror ip ipaddr
ha preemption-enable
2. To add a virtual server to an HA group, use the following command at

the configuration level for the virtual server:
ha-group group-id
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 com-

mand at the configuration level for the virtual port to enable session syn-
chronization for the port:
ha-conn-mirror
4. If IP NAT pools are configured, use the following option with the ip nat
pool or ipv6 nat pool command.
ha-group group-id
(For the complete command syntax, see Table 10 on page 445.)
Commands on AX1
This examples shows the CLI commands to implement the Active-Active
configuration shown in Figure 126 on page 426.
The following commands configure the HA ID and HA groups. Since this is

an Active-Active configuration, both HA groups are configured. The prior-
ity for group 1 is set to a low value. The same group will be set to a higher
priority value on the other 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
The following commands configure the floating IP addresses for each HA

group. The real servers and the Layer 2 switches connected to them will
need to be configured to use the floating IP addresses as their default gate-
ways.
AX1(config)#floating-ip 10.10.10.1 ha-group 1
The following commands configure the HA interfaces. The interface types

are specified, so that the HA state of the AX device can be more precisely
calculated based on HA interface state. (See “HA Interfaces” on page 436.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 3 server-interface no-heartbeat
AX1(config)#ha interface ethernet 5
The following command enables session synchronization (connection mir-

roring). The feature also will need to be enabled on individual virtual ports,
later in the configuration. The IP address is the real address of the other 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-slb virtua...)#ha-conn-mirror
AX(config-slb virtual server)#exit
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Commands on AX2
Here are the commands for AX2. The priority values for the groups are dif-
ferent from the values set on AX1, so that group 1 has higher priority on this
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
The floating IP addresses must be the same as the ones set on AX1.
The IP address for session synchronization is the address of AX1.

The HA configuration for virtual servers and virtual ports is identical to the
configuration on AX1.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Layer 2 HA (Inline Mode)

• HA ID
• HA group ID and priority. Configure only one group ID. Configure
the same ID on both AX devices.
• Inline mode and optional preferred port
• Restart port list and time (optional)
• HA interfaces
2. Add each virtual server to the HA group.

4. If IP NAT pools are configured, add each pool to the HA group.
Layer 2 Inline HA Configuration Example

The following configuration examples implement the deployment shown in
Figure 128 on page 430. 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 436.)
• 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
Configuring Global HA Parameters

a. On the General tab, 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.
2. On the Group tab, 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. On the Floating IP Address tab, 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

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 436.)
a. Click on the interface number.
b. On the HA tab, select Enabled next to HA Enabled.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 Inline Parameters

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 128 on

page 430.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 139 Config > HA > Setting
FIGURE 140 Config > HA > Setting > HA Inline Mode
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
Commands on AX1
The following commands configure the HA ID and set the HA priority. HA

priority is associated with an HA group. Since inline mode is supported only
in Active-Standby configurations, only one HA group is used. Later in the
configuration, the VIP is assigned to this HA group.
AX1(config)#ha id 1
The following command enables inline HA mode and specifies the pre-
ferred HA port.
AX1(config)#ha inline-mode preferred-port 5
The following commands configure the HA interfaces. Each interface that is

connected to a server, a router, or the other AX can be configured as an HA
interface. Make sure to add the preferred HA port as one of the HA inter-
faces.
AX1(config)#ha interface ethernet 3 server-interface
The following command enables restart of the HA ports connected to the

routers, to occur if the 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 configura-
tion. (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.)
The following command specifies the IP address of the other AX, to use for
session synchronization.
The following command configures the floating IP address for the real serv-
ers to use as their default gateway address.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The following commands configure a health method, real servers, a server
group, and a VIP for an HTTP service.
AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3
AX1(config-health:monitor)#method http url HEAD /index.html
AX1(config-health:monitor)#exit
AX1(config)#slb server s1 172.168.10.30
AX1(config-real server)#port 80 tcp
AX1(config-real server-node port)#health-check myHttp
AX1(config-real server-node port)#exit
AX1(config-real server)#exit
AX1(config)#slb service-group g80 tcp
AX1(config-slb service group)#member s1:80
AX1(config-slb service group)#exit
AX1(config)#slb virtual-server v1 172.168.10.80
AX1(config-slb virtual server)#ha-group 1
AX1(config-slb virtual server-slb virtua...)#service-group g80
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
AX2(config)#ha inline-mode preferred-port 5
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009

• HA ID
• HA group ID and priority. Configure only one group ID. Configure
the same ID on both AX devices.
• Inline mode
• HA interfaces
2. Enable CPU processing on the Ethernet interfaces that will receive

server replies to client requests.
3. Add each virtual server to the HA group.

5. If IP NAT pools are configured, add each pool to the HA group.
Layer 3 Inline HA Configuration Example

The following configuration example implements the deployment shown in
Figure 129 on page 433.
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 glo-
bal 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 on the lead interface
of the trunk. (The lead interface of a trunk is the lowest-numbered inter-
face in the trunk.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Commands on AX1
The following commands configure the interfaces. Since Ethernet interfaces

3 and 4 will receive server replies to client requests, CPU processing is
enabled on those interfaces.
AX1(config)#interface ethernet 1
AX1(config-if:ethernet1)#enable
AX1(config-if:ethernet1)#interface ethernet 2
AX1(config-if:ethernet3)#cpu-process
AX1(config-if:ethernet5)#exit
AX1(config)#vlan 100
AX1(config-vlan:100)#untagged ethernet 1 to 4
AX1(config-vlan:100)#router-interface ve 1
AX1(config-vlan:100)#exit
AX1(config)#vlan 5
AX1(config-vlan:5)#untagged ethernet 5
AX1(config)#interface ve1
AX1(config-if:ve1)#ip address 172.168.10.2 /24
AX1(config-if:ve1)#interface ve5
AX1(config-if:ve5)#exit
The following commands configure the HA ID and set the HA priority. HA

priority is associated with an HA group. Later in the configuration, the VIP
is assigned to this HA group.
AX1(config)#ha id 1
The following command enables Layer 3 inline HA mode.

AX1(config)#ha l3-inline-mode
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.)
The following command enables restart of the HA ports connected to the

routers, to occur if the AX transitions to Standby.
The following command enables HA pre-emption mode, which causes

failover to occur in response to administrative changes to the HA configura-
tion. (For example, if you change the HA priority so that the other AX has
higher priority, this will trigger a failover, but only if pre-emption mode is
enabled.)
The following command specifies the IP address of the other AX, to use for
session synchronization.
The following command configures the floating IP address for the real serv-
ers to use as their default gateway address.
The following commands configure a health method, real servers, a server

group, and a VIP for an HTTP service.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Commands on AX2
Here are the commands for implementing HA on AX2. Most of the com-
mands are the same as those on AX1, with the following exceptions:
• The IP interfaces are different.
• The HA ID is 2.
• The HA priority is 1.
The session synchronization (conn-mirror) IP address is the address of

AX1. (On AX1, the session synchronization IP address is the address of
AX2.)
AX2(config)#interface ethernet 1
AX2(config-if:ethernet5)#exit
AX2(config)#vlan 100
AX2(config-vlan:100)#untagged ethernet 1 to 4
AX2(config)#vlan 5
AX2(config-vlan:5)#untagged ethernet 5
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
AX2(config)#interface ve1
AX2(config-if:ve1)#interface ve5
AX2(config-if:ve5)#exit
AX2(config)#ha id 2
AX2(config)#ha l3-inline-mode
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Optional Failover Triggers

The following sections show how to configure the following optional
failover triggers:
• VLAN-based failover
• Gateway-based failover
• VIP-based failover
Only the configuration relevant to the triggers is shown. A complete HA

configuration also includes the configuration items described in the previ-
ous sections.
Note: Failover based on HA interface state is also optional, and is described in

other sections in this chapter.
VLAN-Based Failover Example

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

1. Select Config > HA > Setting > HA Global.
2. On the Status Check tab, 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 glo-
[no] ha check vlan vlan-id timeout seconds
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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
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 438.)
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. On the Health Monitor tab, enter a name for the monitor.
e. On the Method tab, 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:
d. On the General tab, 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 moni-
tor you configured in step 1.
g. Click OK.
3. Enable gateway-based failover:

a. Select Config > HA > Setting > HA Global.
b. On the Status Check tab, enter the IP address of the gateway in the
IP Address field.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
c. Click Add.
d. Repeat step b and step c for each gateway to be monitored for HA.
e. Click OK.
USING THE CLI

1. To configure a health monitor for a gateway, use the following com-
mands.
[no] 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
3. To enable HA health checking for the gateway, use the following com-
mand at the global configuration level.
[no] ha check gateway ipaddr
CLI Example
The following commands configure an ICMP health method:

AX(config)#health monitor gatewayhm1
AX(config-health:monitor)#method icmp
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
The following command enables HA health checking for the gateway:

AX(config)#ha check gateway 10.10.10.1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
VIP-Based Failover Example

To configure VIP-based failover, use either of the following methods.
These procedures apply specifically to the VIP-based failover parameters.

You also need to configure HA global and interface parameters. See “Con-
figuring Global HA Parameters” on page 450 and “Configuring HA Inter-
faces” on page 451.
(For a description of the feature, see “VIP-based Failover” on page 439.)
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.
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 450.
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:
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Enter this command at the configuration level for the virtual server to
enable VIP-based failover. The server-weight specifies the amount to sub-
tract from the HA group's priority value for each real server that becomes
unavailable. The weight can be 1-255. The default is 1.
CLI Example
The following command configures HA group 6 on AX-1 and assigns prior-

ity 100 to the group:
AX-1(config)#ha group 6 priority 100
The following command enables HA pre-emption. HA pre-emption must be

enabled in order for failover to occur based on HA group priority changes.
AX-1(config)#ha preemption-enable
The following command configures a floating IP address and assigns it to

HA group 6:
AX-1(config)#floating-ip 192.168.10.1 ha-group 6
The following commands assign virtual server VIP2 to HA group 6 and

enable VIP-based failover for the virtual server. (For simplicity, this exam-
ple does not show configuration of the real servers or non-HA virtual server
options.)
AX-1(config)#slb virtual VIP2 192.168.10.22
AX-1(config-slb virtual server)#ha group 6
AX-1(config-slb virtual server)#ha-dynamic 10
The following commands configure the HA settings on AX-2. The priority

for HA group 6 is set to 80. The server weight for HA group 6 on VIP2 is
set to 10, the same weight value set on AX-1. Up to 2 real servers bound to
VIP2 can become unavailable on AX-1 without triggering a failover. How-
ever, if a third real server becomes unavailable, the priority of HA group 6 is
reduced to 70, which is lower than the priority value set on AX-2 for the
group. In this case, a failover does occur for VIP2.
AX-2(config)#ha group 6 priority 80
AX-2(config)#ha preemption-enable
AX-2(config)#floating-ip 192.168.10.1 ha-group 6
AX-2(config)#slb virtual VIP2 192.168.10.22
AX-2(config-slb virtual server)#ha group 6
AX-2(config-slb virtual server)#ha-dynamic 10
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Enabling Session Synchronization
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.
USING THE GUI
To globally enable the feature:

2. On the menu bar, select HA Global.
3. In the Mirror IP Address field, enter the IP address of 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.
4. On the Port tab, select the port and click Edit.
5. Select Enabled next to HA Connection Mirror.
Note: If the HA Connection Mirror option is not displayed, session synchroniza-

tion is not supported for this service type.
6. Click OK to redisplay the Port tab.
7. Click OK again.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Synchronizing Configuration Information
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 on the other AX device.
To enable session synchronization on a virtual port, use the following com-

mand at the configuration level for the port:
[no] ha-conn-mirror
CLI Example
The following command sets the session synchronization address to

10.10.10.66, the IP address of the other 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-slb virtua...)#ha-conn-mirror

You can use config-sync options to synchronize some or all of the follow-
ing:
• 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)
• Data files:
• SSL certificates and private-key files
• aFleX files
• External health check files
• Black/white-list files
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Requirements
Session synchronization (connection mirroring) is required for config sync.

Config sync uses the session synchronization link. To enable session syn-
chronization, see “Enabling Session Synchronization” on page 476.
SSH management access must be enabled on both ends of the link. (See
“Securing Admin Access by Ethernet” on page 515.)
Configuration Items That Are Backed Up

The following configuration items are backed up during HA configuration
synchronization:
• Admin accounts and settings
• Floating IP addresses
• IP NAT configuration
• Access control lists (ACLs)
• Health monitors
• Policy-based SLB (black/white lists)
• SLB
• FWLB
• GSLB
• Data Files:
• aFleX files
• External health check files
• SSL certificate and private-key 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration Items That Are Not Backed Up
The following configuration items are not backed up during HA configura-

tion synchronization:
• Management access settings (the ones described in “Securing Admin
Access by Ethernet” on page 515)
• AX Hostname
• MAC addresses
• Management IP addresses
• Trunks or VLANs
• Interface settings
• OSPF or RIP 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 11 lists the cases in which reload is automatic, optional, or not

allowed.
TABLE 11 Reload of Target AX Device After Config-Sync

Admin Role Status of Target AX1 Target Config Reload?
Root or Super User Standby startup-config Automatic
(Read-Write) running-config Automatic
Active startup-config Optional2
Not reloaded by default
running-config Automatic
Partition Write Standby startup-config Not Allowed
running-config Not Allowed
Active startup-config Not Allowed
running-config Not Allowed
1. “Active” means the AX device is currently the active device for at least one HA group.
2. 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.
D e s i g n 479 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
An admin who is logged on with Root or Read-Write (Super Admin) privi-
leges can synchronize for all Role-Based Administration (RBA) partitions
or for a specific partition.
An admin who is logged on with Partition Write privileges can synchronize

only for the partition to which the admin is assigned, and can only synchro-
nize to the startup-config on the other device. The with-reload and to-run-
ning-config options are not available to Partition Write admins.
Caveats
Before synchronizing the Active and Standby 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 privi-

leges on the Standby AX device and will synchronize to it using read-only
privileges. However, you must be logged onto the Active AX with configu-
ration (read-write) access.
If the configuration includes Policy-based SLB (black/white lists), the time

it takes for synchronization depends on the size of the black/white-list file.
This is because the synchronization process is blocked until the files are
transferred from active to standby.
Do not make other configuration changes to the Active or Standby AX

device during synchronization.
Performing HA Synchronization
To synchronize the AX devices in an HA configuration, use the CLI com-
mands described below.
USING THE GUI

1. Select Config > HA > Config Sync.
2. In the User and Password fields, enter the admin username and pass-
word 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 592.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 cop-
ied 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 of the other AX device either is automatic or is not
allowed. See Table 11 on page 479.
7. 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” on page 577.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To synchronize data files and the running-config, use the following com-
mand:
ha sync all
{to-startup-config [with-reload] |
to-running-config}
[all-partitions | partition partition-name]
Note: In some cases, reload of the other AX device either is automatic or is not
allowed. See Table 11 on page 479.
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:
ha sync startup-config
to-running-config}
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-running-config}
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
Network Address Translation
This chapter describes Network Address Translation (NAT) and how to con-
figure it. NAT translates the source or destination IP address of a packet
before forwarding the packet.
The AX device uses NAT to perform SLB. The AX device also supports tra-
ditional Layer 3 NAT, which you can configure if required by your network.
SLB NAT
AX Series devices automatically perform destination NAT for client-VIP
SLB traffic. Figure 141 shows an example.
FIGURE 141 SLB NAT
By default, SLB NAT works as follows.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
• Before forwarding a client packet to a real server, the AX device trans-
lates the destination IP address from the virtual server IP address (VIP)
to the IP address of the real server.
• The AX device reverses the translation before sending the server reply
to the client. The source IP address is translated from the real server’s IP
address to the VIP address.
The default SLB NAT behavior does not translate the client’s IP address.
IP NAT Configuration Limits

The AX device supports the following:
• NAT pool addresses – Maximum of 500 NAT pool addresses supported,
in all NAT pools. For example, you can configure 1 NAT pool contain-
ing 500 NAT addresses, or 100 NAT pools containing 5 addresses each,
and so on.
• NAT pools – Maximum of 100 NAT pools supported.
• NAT pool groups – Maximum of 50 NAT pool groups supported. Each

NAT pool group can contain up to 5 NAT pools.
SLB Source NAT

SLB source NAT is disabled by default. There are some cases where SLB
Source NAT is applicable:
• Connection reuse. (See “Connection Reuse” on page 484.)
• The VIP and real servers are in different subnets. In cases where real
servers are in a different subnet than the VIP, source NAT ensures that
reply traffic from a server will pass back through the AX device. (See
“Source NAT for Servers in Other Subnets” on page 489.)
• Use of different real port numbers for the same service within a service
group, when non-standard port numbers (higher than 1023) are used.
(See “Auto-Port Translation” on page 675.)
Connection Reuse
Connection reuse enables you to reuse TCP connections between the AX

device and real servers for multiple client sessions. When you enable this
feature, the AX device does not tear down a TCP connection with the real
server each time a client ends it session. Instead, the AX device leaves the
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
TCP connection established, and reuses the connection for the next client
that uses the real server.
Connection reuse requires SLB source NAT. Since the TCP connection with
the real server needs to remain established after a client’s session ends, the
client’s IP address cannot be used as the source address for the connection,
Instead, the source address must be an IP address from a NAT pool or pool
group configured on the AX device.
The pool or pool group must have a unique IP address for each reusable
TCP connection you want to establish.
To configure connection reuse:

1. Configure a NAT pool or set of pools to specify the IP addresses to use
as source addresses for the reusable connections with the real servers.
• To use a single, contiguous range of addresses, only one pool is
needed.
• To use a non-contiguous range of addresses, configure a separate
pool for each contiguous portion of the range, then configure a pool
group that contains the pools.
The addresses within an individual pool still must be contiguous,
but you can have gaps between the ending address in one pool and
the starting address in another pool. You also can use pools that are
in different subnets.
A pool group can contain up to 5 pools. Pool group members must
belong to the same protocol family (IPv4 or IPv6) and must use the
same HA ID. A pool can be a member of multiple pool groups. Up
to 50 NAT pool groups are supported.
2. Configure a connection reuse template.
3. If you plan to use policy-based source NAT, to select from among multi-
ple pools based on source IP address, configure an ACL for each of the
client address ranges that will use its own pool.
4. Enable source NAT on the virtual service port and specify the pool or
pool group to use for the source addresses. If you are configuring pol-
icy-based source NAT, bind each ACL to its pool.
5. Add the connection reuse template to the service port.
Note: These steps apply specifically to configuration of connection reuse. A

complete SLB configuration also requires the standard SLB configuration
steps, including configuration of the real servers and service group, and so
on.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
USING THE GUI

1. To configure a pool of addresses:
a. Select Config > Service > IP Source NAT.
b. Select IPv4 Pool or IPv6 Pool on the menu bar.
c. Click New. The Pool tab appears.
d. Enter a name for the pool.
e. Enter the start and end addresses.
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.
2. To configure a connection reuse template:

b. Select Connection Reuse on the menu bar.
c. Click New. The Connection Reuse tab appears.
e. Edit the other parameters or leave them at their default settings.
f. Click OK. The template appears in the connection reuse template
table.
3. To enable source NAT on the virtual port:

a. Select Config > Service > Server.
c. Select the virtual server name or click New.
d. If you are adding a new virtual server, enter the general server set-
tings.
e. Click Port.
f. Select the port and click Edit, or click New. The Virtual Server Port
tab appears.
g. Enter or select the port settings, if the port is new.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
h. Do one of the following:
• To use a single pool or pool group for all source addresses, select
the pool from the Source NAT pool drop-down list.
• To use separate pools based on source addresses, use the
ACL-SNAT Binding fields to bind each ACL to its pool.
For each binding, select the ACL from the Access List drop-
down list, select the pool from the Source NAT Pool drop-down
list, and click Add.
i. Do not click OK yet. Go to step 4.
4. To add the connection reuse template to the virtual port:

a. In the Connection Reuse Template drop-down list, select the tem-
plate.
b. Click OK.
c. Click OK again.
USING THE CLI

1. To configure an IP address pool, 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]

ipv6 nat pool pool-name
start-ipv6-addr end-ipv6-addr
netmask mask-length
To configure a pool group, configure a separate IP pool for each contig-

uous set of addresses, then use the following command to add the pools
to a pool group:
ip nat pool-group pool-group-name
{pool-name ...}
2. To configure a connection reuse template, enter the following command

at the global configuration level to create the template:
slb template connection-reuse template-name
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
This command creates the template and changes the CLI to configura-
tion level for the template. Use the following commands to configure
the template, or use the default settings:
limit-per-server number
timeout seconds
The limit-per-server command specifies the maximum number of reus-
able connections to establish with each real server. You can specify 0-
65535. For unlimited connections, specify 0. The default is 1000.
The timeout command specifies the maximum number of seconds a
reusable connection can remain idle before it times out. You can specify
1-3600 seconds. The default is 2400 seconds (40 minutes).
3. To enable source NAT, do one of the following:

• To enable source NAT on the virtual port and use a single pool or
pool group for all source addresses, use the following command at
the configuration level for the virtual port:
source-nat pool {pool-name | pool-group-name}
• To enable policy-based source NAT and use separate pools based on
source IP address, use the following command at the configuration
level for the port. This command binds an ACL to its pool:
access-list acl-num source-nat-pool pool-name
Note: If you do not specify a NAT pool with this command, the ACL is used
only to filter the traffic.
4. Add the connection reuse template to the virtual port, use the following
command at the configuration level for the virtual port:
template connection-reuse template-name
CLI Example
The following commands configure standard ACLs that match on different
client addresses:
AX(config)#access-list 30 permit ip 192.168.1.1
AX(config)#access-list 50 permit ip 192.168.20.69
The following commands configure source NAT pools:

AX(config)#ip nat pool pool1 10.10.10.200 10.10.10.100 netmask /16
ha-group-id 1
ha-group-id 1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
The following commands configure a real server and a service group:
AX(config)#slb server s1 192.168.19.48
AX(config)#slb service-group group80 tcp
AX(config-slb service group)#method weighted-rr
AX(config-slb service group)#member s1:80
The following commands configure policy-based source NAT, by binding

ACLs to NAT pools on the virtual port.
AX(config-slb virtual server-slb virtua...)#access-list 30 source-nat-pool
pool1
pool2
Source NAT for Servers in Other Subnets
The AX device allows source NAT to be enabled on a virtual port. In cases

where real servers are in a different subnet than the VIP, source NAT
ensures that reply traffic from a server will pass back through the AX
device.
You can enable source NAT on a virtual port in either of the following ways:
• Use the the source-nat option to bind a single IP address pool or pool
group to the virtual port. This option is applicable if all the real servers
are in the same subnet.
• Use sets of ACL-pool pairs, one for each real server subnet. You must
use this method if the real servers are in multiple subnets. This section
describes how to use this method.
For the real server to be able to send replies back through the AX device,
use an extended ACL. The source IP address must match on the client
address. The destination IP address must match on the real server address.
The action must be permit.
The ACL should not match on the virtual IP address (unless the virtual IP
address is in the same subnet as the real servers, in which case source NAT
is probably not required). Figure 142 on page 490 shows an example.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
FIGURE 142 Multiple NAT Pools Bound to a Virtual Port
In this example, a service group has real servers that are located in two dif-
ferent subnets. The VIP is not in either of the subnets. To ensure that reply
traffic from a server will pass back through the AX device, the AX device
uses IP source NAT.
To implement IP source NAT, two pairs of ACL and IP address pool are
bound to the virtual port. Each ACL-pool pair contains the following:
• An extended ACL whose source IP address matches on client addresses
and whose destination IP address matches on the real server’s subnet.
• An IP address pool or pool group containing translation addresses in the
real server’s subnet.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
For example, if SLB selects a real server in the 10.10.10.x subnet, then the
source IP address is translated from the client’s address to an address in
pool 1. When the server replies, it replies to the address from pool 1.
Note: In most cases, destination NAT does not need to be configured for SLB.
The AX device automatically translates the VIP address into a real server
address before forwarding a request to the server.
CLI Example
The following commands implement the source NAT configuration shown

First, the ACLs are configured. In each ACL, “any” is used to match on all
clients. The destination address is the subnet where the real servers are
located.
AX(config)#access-list 100 permit any 10.10.10.0 /24
AX(config)#access-list 110 permit any 10.10.20.0 /24
The following commands configure the IP address pools. Each pool con-
tains addresses in one of the real server subnets.
The following commands bind the ACLs and IP address pools to a virtual
port on the VIP:
pool1
pool2
Direct Server Return

You can disable destination NAT on a virtual port, to enable Direct Server
Return (DSR). DSR enables a real server to respond to clients directly
instead of going through the AX device. The AX is not required to return
the server’s response traffic to clients, so there is no need to un-NAT traffic.
This type of NAT is especially useful for applications that have intensive
payload transfers, such as FTP and streaming media.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SLB NAT
When DSR is enabled, only the destination MAC address is translated from
the VIP’s MAC address to the real server’s IP address. The destination IP
address is still the VIP.
To use DSR, the AX device and the real servers must be in the same Layer 2
subnet. The VIP address must be configured as a loopback address on the
real servers.
To enable DSR on a virtual port, use either of the following methods.
Note: To configure health checking for DSR, see “Configuring Health Monitor-
ing of Virtual IP Addresses in DSR Deployments” on page 308.
Note: For examples of DSR configurations, see “Network Setup” on page 53.
USING THE GUI

3. Select the virtual server name or Click Add.
4. If you are adding a new virtual server, enter the general server settings.
5. Click Port.
6. Select the port and click Edit, or click Add. The Virtual Server Port tab
appears.
7. Enter or select the port settings, if the port is new.
8. Select Enabled next to Direct Server Return.
9. Click OK.
10. Click OK again.
USING THE CLI
Enter the following CLI command at the configuration level for the virtual
port:
no-dest-nat
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
Using IP Pool Default Gateways To Forward Traffic from Real

Servers
The AX device provides an option to use the default gateway of an IP
source NAT pool to forward traffic from a real server.
When this option is enabled, the AX device checks the configured IP NAT
pools for an IP address range that includes the server IP address (the source
address of the traffic). If the address range in a pool does include the
server’s IP address, and a default gateway is defined for the pool, the AX
device forwards the server traffic through the pool’s default gateway.
This feature is disabled by default. To enable it, use the following command
at the global configuration level of the CLI:
[no] slb snat-gwy-for-l3
IP Source NAT
Independently of SLB NAT, you can configure 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
The addresses within an individual pool still must be contiguous, but
you can have gaps between the ending address in one pool and the start-
ing address in another pool. You also can use pools that are in different
subnets.
A pool group can contain up to 5 pools. Pool group members must
belong to the same protocol family (IPv4 or IPv6) and must use the
same HA ID. A pool can be a member of multiple pool groups. Up to 50
NAT pool groups are supported.
If a pool group contains pools in different subnets, the AX device selects
the pool that matches the outbound subnet. For example, of 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 des-
tination 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 map-
ping or a range list before the host traffic is sent to the Internet.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 non-

contiguous ranges of addresses, configure multiple pools and add them
to a pool group.
3. Enable inside source NAT and map the ACL to the pool.
4. Enable inside NAT on the interfaces connected to the inside hosts.
5. Enable outside NAT on the interfaces connected to the Internet.
USING THE GUI
Note: In step 3, the GUI supports binding IPv4 pools to ACLs but not IPv6
pools. To bind an IPv6 pool to an ACL, use the CLI instead.
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.
f. Enter the network mask.
g. If the AX device is deployed in transparent mode, enter the default
gateway to use for NATted traffic.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
FIGURE 143 Configure > Network > ACL > Standard ACL
FIGURE 144 Configure > Service > IP Source NAT > IPv4 Pool
FIGURE 145 Configure > Service > IP Source NAT > Binding
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
FIGURE 146 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 configu-
ration level of the CLI.
Use a standard ACL to specify the host IP addresses to translate. All
host addresses that are permitted by the ACL are translated before traffic
is sent to the Internet.
To also specify other information including destination addresses and
source and destination protocol ports, use an extended ACL.
Standard ACL Syntax

access-list acl-num {permit | deny}
source-ipaddr {filter-mask | /mask-length}
Extended ACL Syntax
access-list acl-num {permit | deny} {ip | icmp}
{any | host host-src-ipaddr |

net-src-ipaddr {filter-mask | /mask-length}}
{any | host host-dst-ipaddr |

net-dst-ipaddr {filter-mask | /mask-length}}
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
or
access-list acl-num {permit | deny} {tcp | udp}

[eq src-port | gt src-port | lt src-port |
range start-src-port end-src-port]

[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.
ip nat pool pool-name start-ipaddr end-ipaddr
netmask {subnet-mask | /mask-length}

ipv6 nat pool pool-name
start-ipv6-addr end-ipv6-addr
netmask mask-length
To configure a pool group:

ip nat pool-group pool-group-name
{pool-name ...}
3. To enable inside source NAT and map the ACL to the pool, use the fol-
lowing command:
ip nat inside source list acl-name
pool {pool-name | pool-group-name}
4. To enable inside NAT on the interfaces connected to the inside hosts,

interface [ethernet port-num | ve ve-num]
ip nat inside
The interface command changes the CLI to the configuration level for
the interface connected to the internal hosts. These are the hosts identi-
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
fied by the ACL configured in step 1 and used by the commands in
step 2 and step 3.
5. To enable outside NAT on the interfaces connected to the Internet, use

the following commands:
ip nat outside
CLI EXAMPLE
The following commands configure an ACL to specify the internal hosts to

be NATted. In this example, all hosts in the 10.10.10.x subnet are to receive
NAT service for traffic to the Internet.
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:
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 con-
nected to the internal hosts:
AX(config-if:ethernet4)#ip nat inside
The following commands enable source NAT on the interface connected to

the external hosts:
AX(config-if:ethernet6)#ip nat outside
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
USING THE GUI
Note: The GUI supports configuring a static NAT range but does not support
configuring individual mappings.
1. To configure the static translations of internal host addresses to external
addresses:
a. Select NAT Range on the menu bar.
b. Click Add.
c. Enter a name for the range.
d. Select the address type (IPv4 or IPv6)
e. In the From fields, enter the first (lowest numbered) address and
network mask in the range of inside host addresses to be translated.
f. In the To field, enter the first (lowest numbered) address and net-
work mask in the range of external addresses into which to translate
the inside host addresses.
g. In the Count field, enter the number of addresses to be translated.
h. To apply HA to the addresses, select the HA group.
i. Click OK.
2. To enable inside NAT on the interfaces connected to the inside hosts:

a. Select Interface on the menu bar.
b. Select the interface from the Interface drop-down list.
c. Select Inside in the Direction drop-down list.
d. Click OK.
e. Repeat for each inside interface.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
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]
To configure a range list to use for the mappings:

ip nat range-list list-name
source-ipaddr /mask-length
nat-ipaddr /mask-length
count number [ha-group-id group-id]
The source-ipaddr specifies the starting address in the range of internal

host addresses. The nat-ipaddr command specifies the first address in
the range of external addresses to use for the translations.
The count option specifies how many mappings to create.
2. If you used the ip nat inside source command, enter the following com-
mand at the global configuration level of the CLI, to enable static NAT
support:
ip nat allow-static-host
Note: This step is not required if you use a static source NAT range list instead.
3. To enable inside NAT on the interfaces connected to the inside hosts,

ip nat inside
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
The interface command changes the CLI to the configuration level for
the interface connected to the internal hosts.
4. To enable outside NAT on the interfaces connected to the Internet, use

the following commands:
ip nat outside
CLI EXAMPLE
The following commands enable static NAT, configure an IP address range

named “nat-list-1” that maps up to 100 local addresses starting from
10.10.10.97 to Internet addresses starting from 192.168.22.50, set Ethernet
interface 2 as the inside NAT interface, and set Ethernet interface 4 as the
outside NAT interface.
AX(config)#ip nat range-list nat-list-1 10.10.10.97 /16 192.168.22.50 /16 count
100
AX(config-if:ethernet2)#ip nat inside
AX(config-if:ethernet4)#ip nat outside
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
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.
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]

Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
[no] ipv6 nat pool pool-name start-ipv6-addr
end-ipv6-addr netmask mask-length [gateway ipaddr]
[no] ip nat range-list list-name

source-ipaddr /mask-length nat-ipaddr /mask-length
count number [ha-group-id group-id]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
IP Source NAT
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Additional Admin Accounts
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
• Admin account lockout in response to excessive invalid passwords
• Interface-level access control for individual management access types

(Telnet, SSH, and so on)
• Web access features for securing access through the GUI
• Authentication, Authorization, and Accounting (AAA) for remotely

managed access security
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.

The AX device comes with one admin account, “admin”, by default. The
“admin” account has Root privileges and cannot be deleted.
When logged onto the AX device with the admin account, you can config-
ure additional admin accounts. For each admin account, you can configure
the following settings:
• Username and password
• Privilege level (read or read-write)
• IP host or subnet address from which the admin is allowed to log on
• Account state (enabled or disabled)
Note: You cannot change the privilege level of the “admin” account or disable
it.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring an Admin Account

To configure an admin account, use either of the following methods.
USING THE GUI

1. Select Config > System > Admin.
2. Click Add. The Administrator tab appears.
3. Enter the name in the Name field.
4. Leave Change Administrator Password selected.

(If you do not change the password, the default is used: “a10”.)
5. Enter the password for the new admin account in the Password and Con-
firm Password fields.
6. 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.
7. From the Privilege drop-down list, select the access level:

• Super Admin – Allows access to all levels of the system. This
account is not the “Root” account and can be deleted. This account
cannot configure other admin accounts. (Only the admin account
that has Root privileges can configure other admin accounts.)
• Read Only Admin – Allows monitoring access to the system but not
configuration access. In the CLI, this account can only access the
User EXEC and Privileged EXEC levels, not the configuration lev-
els. In the GUI, this account cannot modify configuration informa-
tion.
• Partition Write Admin – 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 Read Admin – The admin has read-only privileges within
the private partition to which the admin is assigned, and read-only
privileges for the shared partition.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• Partition RS Operator – The admin is assigned to a private partition
but has permission only to view service port statistics for real serv-
ers in the partition, and to disable or re-enable the real servers and
their service ports.
Note: The Partition roles apply to Role-Based Administration (RBA). For infor-
mation about this feature, see “Role-Based Administration” on page 577.
8. Leave the Status enabled.
9. Click OK.
10. The new admin appears in the Admin table.
FIGURE 147 Config > Admin > Admin
FIGURE 148 Config > Admin - new admin added
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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}
privilege priv-level [partition-name]
The password command assigns the password, which can be 1-63 char-
acters. 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 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 but cannot con-
figure other admin accounts.
• partition-read – The admin has read-only privileges within the pri-
vate partition to which the admin is assigned, and read-only privi-
leges 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 priv-
ilege level partition-read, partition-write, or partition-enable-dis-
able.
Note: To restrict write access to specific configuration areas, see “Configuring

AAA for Admin Access” on page 521.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 Root
adminuser2 Enabled Read/Write
The following commands add admin “adminuser3” with password “abc-

defgh” 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
-------------------------------------------------------
admin Enabled Root
AX(config-admin:adminuser3)#show admin adminuser3 detail

User Name ...... adminuser3
Status ...... Enabled
Privilege ...... Read/Write
Partition ......
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
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 ses-
sion output.
3. To delete the admin account, use the following command at the global
configuration level:
no admin admin-username
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 12 lists the admin lockout parameters you can configure.
TABLE 12 Admin Lockout Parameters

Parameter Description Default
Feature state Controls whether admin accounts can be Disabled
locked.
Threshold Number of failed login attempts allowed for 5
an admin account before it is locked.
Reset time Number of minutes the AX device remembers 10 minutes
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.
Duration Number of minutes a locked account remains 10 minutes
locked. To keep accounts locked until you or
another authorized administrator unlocks
them, set the value to 0.
To configure admin lockout, use either of the following methods.
USING THE GUI
To enable the lockout feature:

2. Select Lockout Policy on the menu bar.
3. Select Enable Administrator lockout Feature.
4. Optionally, change lockout settings. (For descriptions, see Table 12 on

page 513.)
5. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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

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 12 on page 513.)
3. Use the following command to enable admin lockout:

admin lockout enable
To view lockout status or manually unlock a locked account:

2. Enter the following command to view the lockout status of an admin

account:
show admin admin-username detail
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Securing Admin Access by Ethernet

By default, certain types of management access through the AX device’s
Ethernet interfaces are blocked. Table 13 lists the default settings for each
management service.
TABLE 13 Default Management Access

Ethernet
Management Management Ethernet and VE
Service Interface Data Interfaces
SSH Enabled Disabled
Telnet Disabled Disabled
HTTP Enabled Disabled
HTTPS Enabled Disabled
SNMP Enabled Disabled
Ping Enabled 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 fol-
lowing 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.
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 per-
mits 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 inter-

face, do not use a permit ACL to control management access to the inter-
face.
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,
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 drop-
down 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 13, click Reset to
Default.
USING THE CLI

Disabling Management Access
To disable management access, use either of the following commands at the
disable-management service
{all | ssh | telnet | http | https | snmp | ping}
{management | ethernet port-num [to port-num] |
ve ve-num [to ve-num]}
or
disable-management service acl acl-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:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• 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. Manage-
ment 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 manage-
ment 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
enable-management service
{all | ssh | telnet | http | https | snmp | ping}
or
enable-management service acl acl-num

The options are the same as those for the disable-management command.
CLI Example:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 -
ve1 on off off off off off -
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Changing Web Access Settings
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
6 on off on 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 alto-
gether (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.

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 14 lists the default settings for Web access.
TABLE 14 Default Web Access Settings

Auto-redirect Automatically redirects requests for the unse- Enabled
cured port (HTTP) to the secure port
(HTTPS).
HTTP server HTTP server on the AX device. Enabled
HTTP port Protocol port number for the unsecured 80
(HTTP) port.
HTTPS server HTTPS server on the AX device. Enabled
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 14 Default Web Access Settings (Continued)
HTTPS port Protocol port number for the secure (HTTPS) 443
port.
Timeout Number of minutes a Web management ses- Range: 0-60
sion can remain idle before it times out and is minutes
terminated by the AX device. To disable
the timeout,
specify 0.
Default: 10
minutes
aXAPI Timeout Number of minutes an aXAPI session can 0-60 min-
remain idle before being terminated. utes. f you
Once the aXAPI session is terminated, the specify 0,
session ID generated by the AX device sessions
for the session is no longer valid. never time
Note: For information about aXAPI, see the out.
AX Series aXAPI Reference. Default: 10
minutes
Note: If you disable HTTP or HTTPS access, any sessions on the management
GUI are immediately terminated.
USING THE GUI

2. On the menu bar, select Web.
3. Edit the settings you want to change.
4. Click OK.
Note: The Preference tab sets the default IP address type (IPv4 or IPv6) for GUI
configuration fields that require an IP address. The tab does not affect
access to the GUI itself.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring AAA for Admin Access
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: 10 minutes
Http port: 80
Https port: 443
Auto redirect: Enabled
Https: Enabled
Http: Disabled

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+ for Authentication, and TACACS+ for
Authorization and Accounting.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 an external RADIUS or

TACACS+ server for authentication. In this configuration, the AX device
still checks its local database first.
• If the username and password are present in the local database, the AX
device grants access.
• If the username is present but the password is wrong, the AX device
denies access. If admin lockout is enabled, the counter for failed login
attempts for that admin account is incremented.
• If the username is not present in the local database, and if the AX device
is configured to use RADIUS or TACACS+, the AX device checks the
external RADIUS or TACACS+ server for the admin name and pass-
word. If they are on the server, the admin is granted access.
You can use TACACS+ or RADIUS for external authentication. Only one
external authentication method can be used.
Authorization
You can configure the AX device to use external TACACS+ servers for
Authorization.
Following successful Authentication by the AX local database or by

RADIUS, the authenticated party is granted access to specific system
resources by Authorization. For an AX admin, authorization specifies the
CLI levels they can access.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure 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.
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 lev-
els are automatically allowed.
• 0 (user EXEC) – Commands at the User EXEC level are sent to
TACACS+ for authorization. Commands at other levels are automati-
cally allowed.
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 exe-
cute.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• 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.
Accounting
You can configure the AX device to use external 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
Command Accounting
You can 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 523 .)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009

To configure AAA for admin access:
1. Prepare the AAA servers:
• On the RADIUS or TACACS+ server(s), add admin accounts (user-
names and passwords).
• On the TACACS+ servers (if used), add the AX device as a AAA
client. For the client IP address, specify the AX IP address.
• For authorization, on the TACACS+ server(s), specify the com-
mands or command groups that are to be allowed or denied execu-
tion.
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 the authentication method to try
after Local.
The AX device always checks its local admin database first, then
checks the RADIUS or TACACS+ server(s) if the admin account is
not in the local database.
3. Configure Authorization:
a. Add the TACACS+ server(s).
b. Specify the command levels to be authorized by TACACS+.
4. Configure Accounting:
a. Add the TACACS+ 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. Specify the command levels to track.
Configuring RADIUS for Authentication
USING THE GUI

2. On the menu bar, select External Authentication > RADIUS.
3. Select the Server checkbox to display the server configuration fields.
4. Enter the hostname or IP address of the RADIUS server in the Host-

name field.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
5. In the Secret and Confirm Secret fields, enter the shared secret (pass-
word) expected by the RADIUS server when it receives requests.
6. 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 informa-
tion, see the AX Series CLI Reference.
To configure Authentication
1. Use the following command at the global configuration level of the CLI
to add the RADIUS server(s):
radius server {hostname | ipaddr}
secret secret-string
The secret-string is the shared secret (password) expected by the
RADIUS server when it receives requests.
2. Use the following command to add RADIUS as an Authentication

method:
authentication type local radius
The local option is required and must be entered before radius. The AX
device always checks its local admin database first.
Configuring TACACS+ for Authentication
USING THE CLI
To add a TACACS+ server, use the following command at the global con-
[no] tacacs-server host {hostname | ipaddr}

[port protocol-portnum]
[timeout seconds]
To configure the AX device to use the external TACACS+ server(s) for

admin authentication, use the following command at the global configura-
tion level of the CLI:
[no] authentication type local tacplus
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI Example
The following commands configure an AX device to use TACACS+ server

10.10.10.13 to authenticate admin access:
AX(config)#tacacs-server host 10.10.1.13 secret tacpwd
AX(config)#authentication type local tacplus
Configuring TACACS+ for Authorization and Accounting
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 informa-
tion, see the AX Series CLI Reference.
Note: The configuration options described in this section are available only in
the CLI.
To configure Authorization
1. Use the following command at the global configuration level of the CLI
to add the TACACS+ server(s):
tacacs-server host {hostname | ipaddr}
2. Use the following command to 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” on page 522.)
3. Optionally, to enable Authorization debugging, use the following com-

mand:
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 523.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To configure Accounting
1. To configure Accounting for logon/logoff activity, use the following
command:
accounting exec {start-stop | stop-only} tacplus
2. To configure accounting for command execution, use the following

command:
accounting commands cmd-level stop-only tacplus
3. Optionally, to enable Accounting debugging, use the following com-

mand:
accounting debug debug-level
CLI EXAMPLES
The following commands configure an AX device to use RADIUS server

10.10.10.12 to authenticate admin access:
AX(config)#radius server 10.10.1.12 secret radpwd
AX(config)#authentication type local radius
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
The following commands configure the AX device to use the same

TACACS+ server for accounting of logon/logoff activity and of all com-
mand activity:
AX(config)#accounting exec start-stop tacplus
AX(config)#accounting commands 15 stop-only tacplus
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 192.168.1.157 secret a10rad
AX(config)#authentication type local radius
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
}
Note: In this example, the AX device’s subnet is added as the client.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 following values:
• “Read-only-Admin” – The admin can access User EXEC and Privileged
EXEC commands only. These are commands at the > and # prompts.
• “Read-write-Admin” – The admin can access User EXEC, Privileged
EXEC, and configuration commands. These are commands at the >, #,
(config)# and sub-config prompts.
vi /usr/local/share/freeradius/dictionary.a10networks
#
# The FreeRADIUS Vendor-Specific dictionary.
#
# Version: $Id: dictionary.a10networks,v 1.4 2009/05/05 11:03:56 a10user Exp $
#
# For a complete list of Private Enterprise Codes, see:
#
# http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers
#
VENDOR A10-Networks 22610
BEGIN-VENDOR A10-Networks
ATTRIBUTE A10-App-Name 1 String

ATTRIBUTE A10-Admin-Privilege 2 integer
VALUE A10-Admin-Privilege Read-only-Admin 1
VALUE A10-Admin-Privilege Read-write-Admin 2
ATTRIBUTE A10-Single-1 51 String

Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
ATTRIBUTE A10-Multi-1 56 String

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
read Auth-Type := Local, User-Password == "test"

A10-Admin-Privilege = 1
write Auth-Type := Local, User-Password == "test"

A10-Admin-Privilege = 2
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
DDoS Protection
Traffic Security Features
AX Series devices support the following advanced security features:

• DDoS protection
• SYN Cookies
• ICMP rate limiting
• Source-IP based connection rate limiting
• Access Control Lists (ACLs)
• Policy-based SLB (PBSLB)
The following sections describe these features and show how to configure
them.
DDoS Protection
AX Series devices provide enhanced protection against distributed denial-
of-service (DDoS) attacks, with IP anomaly filters. The IP anomaly filters
drop packets that contain common signatures of DDoS attacks.
Note: On AX models AX 3200, AX 3100, and AX 2200, DDoS protection is

hardware-based. On models AX 2100 and AX 2000, DDoS protection is
software-based.
DDoS detection applies only to Layer 3, Layer 4, and Layer 7 traffic.
Layer 2 traffic is not affected by the feature.
You can enable the following DDoS filters:

• 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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
DDoS Protection
Note: On the AX 2000 and AX 2100, the ping-of-death option drops all IP
packets longer than 32000 bytes. On other models, 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
Enabling DDoS Protection

To enable DDoS protection, use either of the following methods.
USING THE GUI

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 Config level of the CLI:
ip anomaly-drop {drop-all | frag | ip-option |
land-attack | ping-of-death | tcp-no-flag | tcp-
syn-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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 illegiti-
mate 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.
• 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 con-
sume 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 half-
open 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 3200, AX 3100, and AX 2200.
• Software-based SYN cookies can be enabled on individual virtual ports.
This version of the feature is available on all AX models.
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 software-
based SYN cookies enabled but they are not used.
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 537.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SYN Cookies
Enabling Hardware-Based SYN Cookies

To enable hardware-based SYN cookies, use following CLI method.
USING THE GUI

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 configures dynamic 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
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 addi-
tional 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SYN Cookies
FIGURE 149 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: 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.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SYN Cookies
USING THE GUI
1. Select Config> Service > Server.
3. Click on an existing virtual server name or click Add.
4. Enter or edit the information on the General tab.
5. On the Port tab, select the TCP port and click Edit, or click Add.
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 [sack]
For information about the sack feature, see the AX Series CLI Reference.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
ICMP Rate Limiting
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.
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-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 pack-
ets when the configured thresholds are exceeded.
You can configure ICMP rate limiting filters globally, on individual Ether-
net 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

IMCP 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 pack-
ets per second.
• Maximum rate – The IMCP 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
ICMP Rate Limiting
• 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.
Specifying a maximum rate (lockup rate) and lockup time is optional. If you
do not specify them, lockup does not occur.
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 inter-

face:
2. Click on the interface name to display the configuration tabs for it.
3. Select the ICMP Rate Limiting checkbox to activate the configuration

fields.
7. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
ICMP Rate Limiting
To configure ICMP rate limiting in a virtual server template:
2. On the menu bar, select Template > Virtual Server.

The Virtual Server tab appears.
4. Select the ICMP Rate Limit Status checkbox to enable the configuration
fields.
6. To configure the lockup time, click Lockup Status.
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 540.
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
Parameters
Source-IP based connection rate limiting is configured using the following
parameters:
• 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.
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 544 for more informa-
tion.)
• 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 con-
nection 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 connec-
tion 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 Source IP Con-
nection rate limit dropped this packet
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 (8654 times)
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 cli-
ent 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 Source IP Con-
nection rate limit dropped this packet (locked out)
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. Cur-
rently, 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 rec-
ommends 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 fol-
lowing 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.
• 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 ter-
minating UDP sessions. If you omit the seconds option, sessions are ter-
minated 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 con-
figurable 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 conn-limit

per {100 | 1000}
[shared]
[exceed-action [log] [lock-out lockout-period]]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The conn-limit option specifies the connection limit and can be 1-1000000.
The per {100 | 1000} option specifies the limit period, either 100 millisec-
onds 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
To clear statistics for this feature, use the following command:

clear slb conn-rate-limit src-ip statistics
CLI Example 1
The following command allows up to 1000 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 1000 per 1000 exceed-action lock-out 3
CLI Example 2
The following command allows up to 2000 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 2000 per 100 shared exceed-action log
CLI Example 3
The following command allows up to 2000 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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Access Control Lists (ACLs)
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 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
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

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 – Standard ACLs filter based on source IP address.
• Extended – Extended ACLs filter based on source and destination IP

addresses, IP protocol, and TCP/UDP port numbers.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 558.)
• 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 559.)
• To permit or block management access, use the ACL with the enable-
management command. (See “Securing Admin Access by Ethernet” on
page 515.)
• 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 483.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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]
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 561.)
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 558.)
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• 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.
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 39.
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-if:ethernet4)#access-list 1 in
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 | remark string} ip


[log]
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 561.)
The deny | permit option specifies the action to perform on traffic that
matches the ACL:
• deny – Drops the traffic.
• permit – Allows the traffic.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The remark option adds a remark to the ACL. (For more information, see
“Adding a Remark to an ACL” on page 558.)
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 log option enables the AX device to generate log messages when traffic
matches the ACL. This option is disabled by default.
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 39.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Syntax for Filtering on ICMP Traffic

{permit | deny | remark string} icmp
[type icmp-type [code icmp-code]]


[log]
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 num-
ber (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
• 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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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

{permit | deny | remark string} {tcp | udp}



[log]
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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
Configuring Extended IPv6 ACLs

To configure an extended IPv6 ACL, use the following CLI method.
Note: The GUI does not support configuration of IPv6 ACLs in the current
release.
USING THE CLI

To configure an IPv6 ACL, use the following commands:
[no] ipv6 access-list acl-id
Enter this command at the global configuration level of the CLI. The acl-id
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 com-
mands 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}
[log]
or
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
[no] {permit | deny} {tcp | udp}
{any | host host-src-ipv6addr |

net-src-ipv6addr /mask-length}
{any | host host-dst-ipv6addr |

net-dst-ipv6addr /mask-length}
[log]
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 num-
bers.
any |
host host-src-
ipv6addr |
net-src-
ipv6addr /mask-
length 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
eq src-port |
gt src-port |
lt src-port |
range start-
src-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.
range start-src-port end-src-port
– The ACL matches on traffic from any source
port within the specified range.
any |
host host-dst-
ipv6addr |
net-dst-
ipv6addr /mask-
length Destination IP address(es) to filter.
eq dst-port |
gt dst-port |
lt dst-port |
range start-
dst-port
end-dst-port For tcp or udp, the destination protocol ports to
filter.
log Configures the AX device to generate log mes-
sages when traffic matches the ACL.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 dis-
played 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 Hits: 0
access-list 42 20 deny 192.168.1.0 0.0.0.255 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.
Applying an ACL to an Interface

To apply a configured ACL to an interface, use either of the following meth-
ods.
USING THE GUI
To apply an ACL to an Ethernet port:

2. Select LAN on the menu bar.
3. Click on the port number.
4. On the IPv4 tab, select the ACL from the Access List field.
5. Click OK.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
To apply an ACL to a Virtual Ethernet (VE) interface:
2. Select Virtual on the menu bar.
3. Click on the VE name.
4. Select IPv4 to display the IPv4 tab.
5. Select the ACL from the Access List field.
6. Click OK.
USING THE CLI
Access the configuration level for the interface and use the following com-
mand:
access-list acl-num in
The following commands configure a standard 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
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.
To apply a configured ACL to a virtual server port, use either of the follow-
ing methods.
USING THE GUI

3. Click Add or click on the name of a configured virtual server.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
4. Enter or change information on the General tab, if you are configuring a
new virtual server.
5. On the Port tab, click Add or select a port and click Edit.
6. On the Virtual Server Port tab, 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:
access-list acl-id
The acl-id specifies the ACL number.
Using an ACL to Control Management Access

To use an ACL to control management access, see “Securing Admin Access
by Ethernet” on page 515.
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.
4. Select the pool ID from the NAT Pool drop-down list.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 deny 10.10.10.0 /24
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
By default, since no sequence number was specified when the rule was con-
figured, 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
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 per-
mit 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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Policy-Based SLB (PBSLB)
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.

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.
Note: IPv6 addresses are not supported in black/white lists.
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 cli-
ent by dropping excessive connection attempts from the client.
Client IP lists (black/white lists) are configured on an external device, then

imported into the AX, where the actions to take on the addresses are speci-
fied. A black/white list can contain up to 8 million individual host addresses
and up to 32,000 subnet addresses.
For each address in a black/white list, you can set values for the following
options:
• Group ID – A number from 1 to 31 in a black/white list that identifies a
group of IP host or subnet addresses contained in the list. In a PBSLB
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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
• Connection limit – The total number of concurrent connections between

the client address and the virtual port. 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.
• Comment – A text string that provides administrators information
within the list file.
Configuring a Black/White List

You can configure black/white lists in either of the following ways:
• Remote option – Use a text editor on a PC, then import the list onto the
AX device.
• Local option – Enter the black/white list directly into a management
GUI window.
With either method, the syntax is the same. Add a row for each IP address
(host or subnet), using the following syntax:
ipaddr [/network-mask] [service-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.
The group-id is a number from 1 to 31 that identifies a group of host or sub-

net IP addresses in the list. The default group ID is 0, which means no group
is assigned.
The #conn-limit specifies the maximum number of concurrent connections

allowed from the client. The # is required only if you do not specify a
group-id.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
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 service 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 sec-
ond 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.
Note: 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.
Configuring Policy-Based SLB on the AX Device

You can configure PBSLB parameters on virtual ports by configuring the
settings directly on individual ports, or by configuring a PBSLB policy tem-
plate and binding the template to individual virtual ports.
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 syn-
chronizes with the list to make sure the AX version is current.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 serv-
ers have already been configured.
USING THE GUI
To Configure PBSLB Settings Using a Policy Template:

2. On the menu bar, select Application > 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 tab appears.

a. Enter or select the following information in the fields of the PBSLB
tab:
• 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 tab 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 tabs 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 connec-
tion 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
10. Click OK. The new policy appears in the PBSLB policy list.
11. To bind the PBSLB policy template to a virtual port:

b. On the menu bar, select Virtual Server.
c. Click on the virtual server name or click Add to create a new one.
d. On the Port tab, click Add, or select a virtual port and click Edit.
e. On the Virtual Server Port tab, select the PBSLB template from the
Policy Template drop-down list.
f. Click OK.
g. Click OK again.
FIGURE 150 PBSLB Policy tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
tab
USING THE CLI
To Import a Black/White List:

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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 run-
ning 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
mand 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 tem-
plate.
[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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• 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 gener-
ates 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 gen-
erate log messages only when there is a failed attempt to reach a service
group. Messages are not generated for successful connections to the ser-
vice 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 fea-
tures for PBSLB logging as those used for ACL logging. See “Log Rate
Limiting” on page 39.
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
[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 con-
nections on the virtual port falls below the connection limit.
[no] use-destination-ip
This command matches black/white list entries based on the client’s desti-
nation IP address. By default, matching is based on the client’s source IP
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
address. This option is applicable if you are using a wildcard VIP. (See
“Wildcard VIPs” on page 229.)
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 con-
nections 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 fre-
quent 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 spec-
ify 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
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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
with the drop or reset option, since any time a drop or reset rule affects traf-
fic, 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 Limit-
ing” on page 39.
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
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 vir-
tual port:
pbslb over-limit {drop | reset}
The drop action drops new connections until the number of concurrent con-
nections on the virtual port falls below the threshold. The reset option resets
new connections until the number of concurrent connections on the virtual
port falls below the threshold. The default action is drop.
Note: 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 follow-

ing command:
show bw-list [name [ipaddr]]
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]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The name option specifies a virtual server name. If you use this option, sta-
tistics 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/sample-
bwlist.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 vir-

tual 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-slb virtua...)#template policy bw1
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-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
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 2 0 0 0
4 0 0 0
PBSLB_VS2 80 sample-bwlist 2 0 0 0
4 0 0 0
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Role-Based Administration
Role Based Administration (RBA) allows administrators (“admins”) to con-

figure and view SLB resources based on administrative domains (“parti-
tions”). RBA supports separate partitions for these types of resources.
Partitioning allows the AX device to be logically segmented to support sep-
arate configurations for different customers; for example, separate compa-
nies or separate departments within an enterprise. Admins assigned to a
partition can manage only the resources inside that partition.
Note: RBA is backwards compatible with configurations saved under earlier

AX releases. All resources are automatically migrated to a single, shared
partition.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Overview
Figure 152 shows an example of an AX device with multiple partitions.
FIGURE 152 Role-Based Administration
In this example, a service provider hosts an AX device shared by two com-

panies: A.com and B.com. Each company has its own dedicated servers that
they want to manage in entirety. The partition for A.com contains A.com's
SLB resources. Likewise, the partition for B.com contains B.com's SLB
resources.
Admins assigned to the partition for A.com can add, modify, delete and save
only those resources contained in A.com's partition. Likewise, B.com's
admins can add, modify, delete and save only the resources in B.com's parti-
tion.
The following sections describe RBA in more detail.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Resource Partitions
AX system resources are contained in partitions. The AX device has a sin-
gle shared partition and can have multiple private partitions.
• Shared partition – The shared partition contains resources that can be
configured only by admins with Root or Read Write privileges. By
default, all resources are in the shared partition. There is one shared par-
tition 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 Root, Read Write, or
Read Only privileges. The AX device does not have any private parti-
tions by default.
Private partitions can be created or deleted only by admins who have Root
or Read Write privileges. A maximum of 128 partitions are supported.
(For descriptions of admin privileges, see Table 15 on page 581.)
Types of Resources That Can Be Contained in Private Partitions
Only certain types of resources can be contained in private partitions. In the

current release, a private partition can contain SLB resources only:
• Real servers
• Virtual servers
• Service groups
• Templates
• Health monitors
• Certificates and keys
• aFleX policies
All other types of resources can reside only in the shared partition and are
not configurable by admins assigned to private partitions.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Use of Shared Resources by Private Resources
SLB resources in private partitions can use SLB resources in the shared par-
tition, 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 ser-
vice group in the shared partition, as shown in the following GUI example.
FIGURE 153 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 con-
tains 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.)
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
FIGURE 154 Configurable Partition Logos
Administrator Roles
The type of access (read-only or read-write) allowed to an admin, and the
partitions where the access applies, depend on that admin’s privilege level
(role). An admin account can have one of the privilege levels listed in
Table 15 on page 581.
Note: The “Partition” privilege levels apply specifically to admins who are
assigned to private partitions.
Table 15 describes the admin roles.
TABLE 15 Admin Privilege Levels

Access to Can configure Can Change
Privilege Shared other admin Own
Level (Role) Partition Access to Private Partition accounts Password?
Root Read-write Read-write Yes1 Yes2
Read Write Read-write Read-write No Yes
Read Only Read-only Read-only No No
Partition Write Read-only Read-write, for the partition to which No Yes
the admin is assigned
D e s i g n 581 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
TABLE 15 Admin Privilege Levels (Continued)
Access to Can configure Can Change
Privilege Shared other admin Own
Level (Role) Partition Access to Private Partition accounts Password?
Partition Read Read-only Read-only, for the partition to which the No No
admin is assigned
Partition Real None Read-only for real servers, with permis- No No
Server Opera- sion to view service port statistics, and
tor to disable or enable real servers and real
server ports.
No other read-only or read-write privi-
leges are granted.
All access is restricted to the partition to
which the admin is assigned.
1. Only the admin account named “admin” is allowed to configure other admin accounts, and cannot be deleted. Otherwise,
the Root and Read-write privilege levels are the same.
2. The Root privilege level can also change the passwords of other admins.
Types of Resources That Can Be Viewed and Saved By Private

Partition Admins
All admins can view resources in the shared partition. However, the only
admins who can add, modify, or delete resources in the shared partition are
admins with Root or Read Write privileges. Admins who are assigned to a
partition can view but not modify resources in the shared partition. Admins
assigned to a partition cannot view the resources in any other private parti-
tion.
Each partition has its own running-config and startup-config. When an

admin assigned to a partition displays the running-config or startup-config,
only the resources within the partition are listed.
Likewise, when an admin assigned to a private partition saves the configu-

ration, only the startup-config for that partition is modified. The configura-
tion changes in the partition’s running-config are copied to the partition’s
startup-config.
Only admins with Root or Read Write privileges can select the partition(s)
for which to save changes.
Admins with Real Server Operator privileges can view real servers within
the private partition and can disable or re-enable the real servers and their
individual service ports. These admins have no other privileges.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring Role-Based Administration

To configure role-based administration, log in using an admin account with
Root 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 inter-
faces, VLANs, routing, and so on. You also will need to configure any
additional admin accounts for the partition.
Note: To configure admin accounts, you must be logged in with Root privileges.
Configuring Private Partitions

To configure a private partition, use either of the following methods.
USING THE GUI

2. On the menu bar, select Partition.
3. Click New. The Partition tab 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 155 Config > System > Admin > Partition
FIGURE 156 Config > System > Admin > Partition - List
USING THE CLI
To configure a private partition, use the following command at the global

partition partition-name [max-aflex-file num]
The partition-name can be 1-14 characters. (For information about the max-
aflex-file option, see “Changing the Maximum Number of aFleX Policies
Allowed in a Partition” on page 584.)
Changing the Maximum Number of aFleX Policies Allowed in a Partition
By default, each partition is allowed to have a maximum of 32 aFleX poli-

cies. If a partition admin attempts to add more aFleX policies than are
allowed for the partition, an error message is displayed to the admin.
You can specify a maximum of 1-128 aFleX policies, on an individual parti-

tion basis.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE GUI
3. Select the partition. (Click the checkbox next to the partition name.)
4. Edit the number in the Max aFleX File field. You can specify 1-128.
USING THE CLI
The max-aflex-file option of the partition command specifies the maxi-

mum number of aFleX policies that can belong to the partition. You can
specify 1-128. The default is 32.
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 Root or Read Write privileges can delete a partition.
When a partition is deleted, all resources within the partition also are
deleted.
USING THE GUI

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]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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.
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 512.
USING THE GUI

To configure an admin account for a private partition:
1. Select Config > System > Admin (if not already selected).
2. On the menu bar, select Admin Management.
3. Click New. The Admin tab appears.
4. Enter a name and password for the admin.
5. From the Role drop-down list, select one of the following:

• Partition Write Admin – Gives read-write privileges within the par-
tition you select below.
• Partition Read Admin – Gives read-only privileges within the parti-
tion you select below.
• Partition RS Operator – Allows the admin to view, disable, or re-
enable real servers and service ports in the partition. No other read
or write privileges are granted.
6. From the Partition drop-down list, select the partition to which you are
assigning the admin.
7. Click OK. The new admin appears in the admin list with their respective
partition logos.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 157 Config > System > Admin > Admin Management
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 configu-
ration level for the account. The default password is “a10”.
The privilege command specifies the privilege level for the account and
assigns the account to a partition. (The partition-enable-disable option
gives Partition Real Server Operator privileges.)
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 507.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI Example
The following commands configure two private partitions, “companyA”
and “companyB”, and verify that they have been created.
AX(config)#partition companyA
AX(config)#partition companyB
AX(config)#show partition
Max Number allowed: 128
Total Number of partitions configured: 2
Partition Name Max. aFleX File Allowed # of Admins
------------------------------------------------------
companyA 32 0
companyB 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
-------------------------------------------------------
admin Enabled Root
compAadmin Enabled P.R/W companyA
compBadmin Enabled P.R/W companyB
The show admin command shows privilege information as follows:

• Root – The admin has Root privileges.
• 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Viewing and Saving the Configuration
• 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.

Admins with Root, Read Write, or Read Only privileges can view resources
in any partition. Admins assigned to a partition can view the resources in the
shared partition and in their own private partition but not in any other pri-
vate partition.
Admins with Root or Read Write privileges can save resources in any parti-
tion. 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 591.
USING THE CLI
To view the configuration, use the following commands:
show running-config
show startup-config
If you enter the command without either option, the command shows only
the resources that are in the shared partition.
The all-partitions option shows all resources in all partitions. In this case,
the resources in the shared partition are listed first. Then the resources in
each private partition are listed, organized by partition.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
If you specify a private partition-name, only the resources in that partition
are listed.
Note: If an admin assigned to a private partition uses the all-partitions option,

the option does not list resources in any other private partitions. Similarly,
if a partition admin enters the name of another private partition for parti-
tion-name, an “Insufficient privilege” warning message appears. The
resources of the other partition are not displayed.
Saving the Configuration

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

operation, a Root or Read Write admin should notify all partition
admins to save their configurations if they wish to. Saving all parti-
tions without consent from the partition admins is not recommended.
Note: The all-partitions and partition partition-name options are not applica-
ble for admins with Partition-write privileges. Partition admins can only
save their respective partitions. For these admins, the command syntax is
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Switching To Another Partition
the same as in previous releases. The options are available only to admins
with Root or Read Write privileges.
Note: A configuration can be saved to a different configuration profile name

(rather than being written to “startup-config”), as supported in previous
releases. In this case, the resources that are saved depend on the parti-
tion(s) to which the write memory command is applied. Unless the
resources in the shared partition are being saved, the configuration profile
name used with the write memory command must already exist. The
command does not create new configuration profiles for private parti-
tions.
Switching To Another Partition

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

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

change the view to the shared partition, specify shared.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Synchronizing the Configuration
The following command changes the view to private partition “companyA”:
AX#active-partition companyA
Currently active partition: companyA
To display the currently active partition, use the following command:
show active-partition

When an admin assigned to a private partition synchronizes the configura-
tion 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 Root or 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 follow-
ing 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 syn-
chronize the private partition to the running-config.
– On the Active AX device, synchronize the shared partition to the run-
ning-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.
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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
The ha sync commands have new options that enable you to specify the
partition. For admins with Root or Read Write privileges, here is the new
syntax for the ha sync commands:
ha sync all
to-running-config}
ha sync startup-config
to-running-config}
ha sync running-config
to-running-config}
ha sync data-files
To synchronize the configuration for all partitions, use the all-partitions

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

mand, see the note at the beginning of this section first.
For admins logged on with Partition Write privileges, the following syntax
is available:
ha sync all to-startup-config
ha sync startup-config to-startup-config
ha sync running-config to-startup-config
ha sync data-files
Admins with Partition Write privileges are not allowed to synchronize to the
running-config or to reload the other AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 158 Real Server Management in Operator Mode
Note: Although the GUI displays the Delete and New buttons, these buttons are
not supported for admins with Partition Real Server Operator privileges.
To Disable or Re-Enable Individual Real Server Ports

1. Log in with your Partition Real Server Operator account.
2. Select the checkbox next to each server for which you want to disable or
re-enable service ports, or click Select All to select all of the servers.
3. Click Edit.
4. A list of all the service ports on the selected servers is displayed.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 159 Disabling Service Ports – Selecting the Servers
FIGURE 160 Disabling Service Ports – Selecting the Ports
USING THE CLI

To View Service Statistics
To view configuration information and statistics for real servers used by the
partition, log in with your Partition-enable-disable account and use the fol-
lowing command:
show slb server [server-name] [config]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
CLI Example
login as:compAoper
Welcome to AX
Password:********
Last login: Wed Aug 20 08:58:45 2008 from 192.168.1.130
[type ? for help]

AX>show slb server
Service Current Total Req-pkt Resp-pkt State
------------------------------------------------------------------------------
compArs1:80/tcp 23 320543 1732383 1263164 Up /60 ms
compArs1: Total 23 321024 1732383 1263164 Up
AX>show slb server config
H-check = Health check Max conn = Max. Connection Wgt = Weight
Service Address H-check Status Max conn Wgt
------------------------------------------------------------------------------
compArs1:80/tcp 7.7.7.7 Default Enable 1000000 1
compArs1 7.7.7.7 Default Disable 1000000 1

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

Use the following commands to access the configuration level of the CLI:
enable
config
The enable command accesses the Privileged EXEC level. The end of the
command prompt changes from > to #. If you are prompted for a password,
enter the enable password assigned by the root administrator. The config
command accesses the configuration level.
At the configuration level, use the following command to access the opera-
tion level for the real server:
slb server server-name [ipaddr]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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:
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>enable
Password:********
AX#config
AX(config)#slb server compArs1
AX(config-real server)#disable
AX(config)#show slb server compArs1
Total Number of Services configured on Server compArs1: 1
Service Current Total Req-pkt Resp-pkt State/Rsp
Time
------------------------------------------------------------------------------
compArs1:80/tcp 0 0 0 0 Down 0.00
ms
compArs1: Total 0 0 0 0 Disabled
AX(config)#show slb server compArs1 config
Total Number of Services configured on Server compArs1: 1
H-check = Health check Max conn = Max. Connection Wgt = Weight
Service Address H-check Status Max conn Wgt
------------------------------------------------------------------------------
compArs1 7.7.7.7 Default Disable 1000000 1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Service Template Parameters
SLB Parameters
This chapter lists the parameters you can configure for Server Load Balanc-
ing (SLB).
Note: This chapter is intended only as a reference. Not every configurable

parameter will apply to a given SLB application. For information about
specific applications, see the individual SLB configuration chapters in
this guide.
For information about health monitoring parameters, see “Health Moni-
toring” on page 297.
For information about GSLB parameters, see “Global Server Load Bal-
ancing” on page 335.
For information about FWLB parameters, see “Firewall Load Balancing”
on page 255.

The tables in this section list the template types that are valid for each ser-
vice type, and the configurable settings in each type of template.
Note: For information about server and port configuration templates, see
“Server and Port Templates” on page 281.
Table 18 lists the types of templates that are valid for each service type.
When you configure a virtual port, the AX device automatically adds any
default templates that are applicable to the service type. To override a
default template, you can configure another template of the same type and
bind that template to the virtual port instead.
For example, when you configure a virtual port that has the service type
Fast-HTTP, the following templates are automatically applied to the service
port:
• TCP
• HTTP
• Connection Reuse (The parameters in this default template are all

unset.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
For information about the default settings in a template, see the section in
this chapter that describes the template. For the template types listed above,
see the following sections:
• “Connection Reuse Template Parameters” on page 605
• “HTTP Template Parameters” on page 610
• “TCP Template Parameters” on page 624
To override the settings in a default template, you must configure another

template of the same type and apply that template to the service port instead.
For example, to override the settings that will be applied from the HTTP
template, configure another HTTP template and assign that one to the vir-
tual port instead.
A virtual port can have only one of each type of template that is valid for the
port’s service type, so when you add a template to the virtual port, the other
template of the same type is automatically removed from the virtual port.
TABLE 16 Template Types Valid for Service Types

Service Type
Fast- SSL-
Template Type HTTP HTTP HTTPS FTP MMS RTSP SIP SMTP Proxy TCP UDP
Cache V V
Client SSL V V V
Connection V V V
Reuse
HTTP V V V
Cookie V V V
Persistence
Policy V V V V V V V V V V V
Destination-IP V V V V V V V V V V V
Persistence
Source-IP V V V V V V V V V V V
Persistence
Server SSL V V V
SIP V
SMTP V
SSL Session-ID V V V
Persistence
Streaming- V
media
TCP V V V V V
TCP-Proxy V V V V V
UDP V V
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Cache Template Parameters

Table 17 lists the parameters you can configure in RAM caching templates.
TABLE 17 Cache Template Parameters

Template name Name of the template. String of 1-31 characters
[no] slb template cache Default: “default”. The default tem-
template-name plate has the default values listed
Config > Service > Template > Application > below.
RAM Caching
Age time Number of seconds a cached object can remain in 1-999999 seconds (about 11-1/2 days)
the AX RAM cache without being requested. Default: 3600 seconds (1 hour)
[no] age seconds
Config > Service > Template > Application >
RAM Caching
Default cache Controls whether the default action is to cache Enabled or disabled
action cacheable objects, or not cache them. If you change Default: disabled (Cacheable objects
the default action to nocache, the AX device can are cached by default.)
cache only those objects that match a dynamic pol-
icy rule that has the cache action.
[no] default-policy-nocache
Note: The current release does not support configu-
ration of this option using the GUI.
Reload header Enables support for the following Cache-Control Enabled or disabled
support headers: Default: disabled
When support for these headers is enabled, either
header causes the AX device to reload the cached
object from the origin server.
[no] accept-reload-req
RAM Caching
Cache size Size of the AX RAM cache. 1-512 Mbytes
The total size of all RAM caches combined can be Default: 10 Mbytes
512 Mbytes on systems with 2 GBytes of memory
and 1024 Mbytes on systems with 4 GBytes of
memory. (To display the amount of memory your
system has, enter the show version command.)
[no] max-cache-size Mbytes
RAM Caching
D e s i g n 601 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 17 Cache Template Parameters (Continued)
Maximum object Maximum object size that can be cached. The AX 1-8000000 bytes
size device will not cache objects larger than this size. Default: 50000 bytes (50 Kbytes)
[no] max-content-size bytes
RAM Caching
Minimum object minimum object size that can be cached. The AX 1-8000000 bytes
size device will not cache objects smaller than this size. Default: 500 bytes (1/2 Kbytes)
[no] min-content-size bytes
RAM Caching
Dynamic Configures dynamic caching. Valid URI pattern.
caching policy [no] policy uri pattern Default: Not set
{cache [seconds] | nocache |
invalidate inv-pattern}
The pattern option specifies the portion of the URI
string to match on.
The other options specify the action to take for URIs
that match the pattern:
• cache [seconds] – Caches the content. By default,
the content is cached for the number of seconds
configured in the template (set by the age com-
mand). To override the aging period set in the
template, specify the number of seconds with the
cache command.
• nocache – Does not cache the content.
• invalidate inv-pattern – Invalidates the content
that has been cached for inv-pattern.
RAM Caching
Verify host Enables the AX device to cache the host name in Default: Disabled
addition to the URI for cached content. Use this
option if a real server that contains cacheable con-
tent will host more than one host name (for exam-
ple, www.abc.com and www.xyz.com).
[no] verify-host
RAM Caching
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 17 Cache Template Parameters (Continued)
Replacement Policy used to make room for new objects when the The policy supported in the current
policy RAM cache is full. release is Least Frequently Used
When the RAM cache becomes more than 90% full, (LFU).
the AX device discards the least-frequently used Default: LFU
objects to ensure there is sufficient room for new
objects.
[no] replacement-policy LFU
RAM Caching
Client SSL Template Parameters

Table 18 lists the parameters you can configure in client SSL templates.
TABLE 18 Client SSL Template Parameters

[no] slb template client-ssl Default: “default”. The default tem-
Config > Service > Template > SSL > Client SSL below.
Certificate Name of the Certificate Authority (CA) certificate Name of a CA certificate or CRL
Authority (CA) to use for validating client certificates. You also can imported onto the AX device
certificate name use this command to specify a Certificate Revoca-
tion List (CRL).
[no] ca-cert cert-name
Config > Service > Template > SSL > Client SSL
Note: To use the certificate, you must import it onto
the AX device. (See “Importing SSL Certificates”
on page 467.)
Certificate name Certificate to use for terminating or initiating SSL Name of a certificate imported onto
connections with clients. the AX device
[no] cert cert-name
on page 467.)
Certificate Chain of certificates to use for terminating or initiat- String of 1-31 characters
key-chain name ing SSL connections with clients.
[no] chain-cert chain-cert-name
D e s i g n 603 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 18 Client SSL Template Parameters (Continued)
Certificate key Key for the certificate, and the passphrase used to Key name: string of 1-31 characters
encrypt the key. Passphrase: string of 1-16 characters
[no] key key-name Default: None configured
[passphrase passphrase-string]
AX response to Action that the AX device takes in response to a cli- One of the following:
connection ent’s connection request. • ignore – The AX device does not
request from cli- [no] client-certificate request the client to send its certifi-
ent {ignore | request | require} cate.
Config > Service > Template > SSL > Client SSL • request – The AX device requests
the client to send its certificate. With
this action, the SSL handshake pro-
ceeds even if either of the following
occurs:
• The client sends a NULL certifi-
cate (one with zero length).
• The certificate is invalid, causing
client verification to fail.
Use this option if you want to the
request to trigger an aFleX policy
for further processing.
• require – The AX device requires
the client certificate. This action
requests the client to send its certifi-
cate. However, the SSL handshake
does not proceed (it fails) if the cli-
ent sends a NULL certificate or the
certificate is invalid.
Default: ignore
Certificate CRL to use for verifying that client certificates have Name of a CRL imported onto the AX
Revocation List not been revoked. device
(CRL) When you add a CRL to a client SSL template, the
AX device checks the CRL to ensure that the certif-
icates presented by clients have not been revoked by
the issuing CA.
[no] crl filename
Note: If you plan to use a CRL, you must set the
Mode to Require.
Note: To use the CRL, you must import it onto the
AX device. (See “Importing SSL Certificates” on
page 467.)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 18 Client SSL Template Parameters (Continued)
Session cache Maximum number of cached sessions for SSL ses- 0-131072
size sion ID reuse. Default: 0 (session ID reuse is dis-
[no] session-cache-size number abled)
Ciphers Cipher suite to support for decrypting certificates One or more of the following:
from clients. • SSL3_RSA_DES_192_CBC3_SHA
[no] cipher • SSL3_RSA_DES_40_CBC_SHA
Config > Service > Template > SSL > Client SSL - • SSL3_RSA_DES_64_CBC_SHA
Cipher tab
• SSL3_RSA_RC4_128_MD5
• SSL3_RSA_RC4_128_SHA
• TLS1_RSA_AES_128_SHA
• TLS1_RSA_EXPORT1024_RC4_56
_MD5
_SHA
Default: All the above are enabled.
Connection Reuse Template Parameters

Table 19 lists the parameters you can configure in connection reuse tem-
plates.
TABLE 19 Connection Reuse Template Parameters

[no] slb template Default: “default”. The default tem-
connection-reuse template-name plate has the default values listed
Config > Service > Template > Connection Reuse below.
Connection limit Maximum number of reusable connections per 0-65535
server port. For unlimited connections, specify 0.
[no] limit-per-server number Default: 1000
Config > Service > Template > Connection Reuse
D e s i g n 605 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 19 Connection Reuse Template Parameters (Continued)
Connection idle Maximum number of seconds a connection can 0-3600 seconds
timeout remain idle before it times out. To disable timeout, specify 0.
[no] timeout seconds Default: 2400 seconds (40 minutes)
Config > Service > Template > Connection Reuse
Cookie Persistence Template Parameters

Table 20 lists the parameters you can configure in cookie persistence tem-
plates.
TABLE 20 Cookie Persistence Template Parameters

[no] slb template persist cookie Default: “default”. The default tem-
Config > Service > Template > Persistent > Cookie below.
Persistence
Cookie Number of seconds a cookie persists on a client’s 0 to 31,536,000 seconds (one year)
expiration PC before being deleted by the client’s browser. If you specify 0, cookies persist only
[no] expire expire-seconds for the current session.
Config > Service > Template > Persistent > Cookie Default: 10 years
Persistence Note: Although the default is 10 years
(essentially, unlimited), the maximum
configurable expiration is one year.
Domain Adds the specified domain name to the cookie. Valid domain name
[no] domain domain-name Default: Not set
Config > Service > Template > Persistent > Cookie
Persistence
Path Adds path information to the cookie. 1-31 characters
[no] path path-name Default: “ / ”
Persistence
Insert always Specifies whether to insert a new persistence cookie Enabled or disabled
in every reply, even if the request already had an Default: Disabled. The AX device
AX cookie. inserts a persistence cookie only if the
[no] insert-always client request does not contain a per-
Config > Service > Template > Persistent > Cookie sistence cookie inserted by the AX
Persistence device, or if the server referenced by
the cookie is unavailable.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 20 Cookie Persistence Template Parameters (Continued)
Match type Changes the granularity of cookie persistence: One of the following:
• Port – The cookie inserted into the HTTP header • Port (selectable in the GUI but not
of the server reply to a client ensures that subse- in the CLI)
quent requests from the client will be sent to • Server
the same real port on the same real server. • Service-group
• Server – The cookie inserted into the HTTP Default: Port
header of the server reply to a client ensures that
subsequent requests from the client for the same
VIP are sent to the same real server. (This
assumes that all virtual ports of the VIP use the
same cookie persistence template with match-
type set to Server.)
• Service Group – Enables support for URL
switching or host switching along with cookie
persistence. Without this option, URL switch-
ing or host switching can be used only for the
initial request from the client. After the ini-
tial request, subsequent requests are always
sent to the same service group.
Note: To use URL switching or host switching,
you also must configure an HTTP template
with the Host Switching or URL Switching
option.
[no] match-type
{server | service-group}
Persistence
Cookie name Specifies the name of the persistence cookie. String of 1-63 characters
The format of the cookie depends on the match Default: sto-id
type.
[no] name cookie-name
Persistence
Ignore Ignores connection limit settings configured on real Enabled or Disabled
connection limits servers and real ports. This option is useful for Default: Disabled. By default, the con-
applications in which multiple sessions (connec- nection limit set on real servers and
tions) are likely to be used for the same persistent real ports is used.
cookie.
[no] dont-honor-conn-rules
Persistence
D e s i g n 607 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Destination-IP Persistence Template Parameters

Table 21 lists the parameters you can configure in destination-IP persistence
templates.
TABLE 21 Destination-IP Persistence Template Parameters

[no] slb template persist Default: “default”. The default tem-
destination-ip template-name plate has the default values listed
Config > Service > Template > Persistent > below.
Destination IP Persistence
Persistence Granularity of persistence: One of the following:
granularity • Port – Traffic from a given client to the same vir- • Port (selectable in the GUI but not
tual port is always sent to the same real port. This in the CLI)
is the most granular setting. • Server
• Server – Traffic from a given client to the same • Service-group
VIP is always sent to the same real server, for any
Default: Port
service port requested by the client.
• Service-group – This option is applicable if you
also plan to use URL switching or host switching.
If you use the Service-group option, URL or host
switching is used for every request to select a ser-
vice group. The first time URL or host switching
selects a given service group, the load-balancing
method is used to select a real port within the ser-
vice group. The next time URL or host switching
selects the same service group, the same real port
is used. Thus, service group selection is per-
formed for every request, but once a service
group is selected for a request, the request goes to
the same real port that was selected the first time
that service group was selected.
Note: To use URL switching or host switching, you
also must configure an HTTP template with the
Host Switching or URL Switching option.
[no] match-type
Config > Service > Template > Persistent >
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 21 Destination-IP Persistence Template Parameters (Continued)
Hashing netmask Granularity of IP address hashing for initial server Valid IPv4 network mask
port selection. Default: 255.255.255.255
You can specify an IPv4 network mask in dotted
decimal notation.
• To configure initial server port selection to occur
once per destination VIP subnet, configure the
network mask to indicate the subnet length. For
example, to select a server port once for all
requested VIPs within a subnet such as
10.10.10.x, 192.168.1.x, and so on (“class C”
subnets), use mask 255.255.255.0. SLB selects a
server port for the first request to the given VIP
subnet, the sends all other requests for the same
VIP subnet to the same port.
• To configure initial server port selection to occur
independently for each requested VIP, use mask
255.255.255.255. (This is the default.)
[no] netmask ipaddr
Persistence Number of minutes the mapping of a client source 1-1000 minutes
Timeout IP to a real server persists after the last time traffic Default: 5 minutes
from the client is sent to the server.
[no] timeout timeout-minutes
client source IP address.
D e s i g n 609 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
HTTP Template Parameters

Table 22 lists the parameters you can configure in HTTP templates.
TABLE 22 HTTP Template Parameters

[no] slb template http template- Default: “default”. The default tem-
name plate has the default values listed
Config > Service > Template > Application > HTTP below.
Failover URL Fallback URL to send in an HTTP 302 response Valid URL
when all real servers are down. Default: Not set
[no] failover-url url-string
Config > Service > Template > Application > HTTP
Retry and Configures the AX device to retry sending a client’s 1-3
reassignment request to a service port that replies with an HTTP Default: Disabled. The AX device
when server 5xx status code, and reassign the request to another sends the 5xx status code to the client.
replies with 5xx server if the first server replies with a 5xx status
When you enable this option, the
status code code.
default number of retries is 3.
The first command shown below temporarily stops
using a service port after reassignment. The second
command does not.
[no] retry-on-5xx num
[no] retry-on-5xx-per-req num
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 22 HTTP Template Parameters (Continued)
Compression Offloads Web servers from CPU-intensive HTTP Any of the following:
compression operations.
• enable – Enables compression.
[no] compression {enable |
• content-type – Specifies the types
content-type content-string |
of content to compress, based on a
exclude-content-type content-
string in the content-type header of
string | exclude-uri uri-string the HTTP response. The content-
keep-accept-encoding enable |
string can be 1-64 characters long.
level number |
minimum-content-length number} • exclude-content-type – Specifies the
types of content to exclude from
compression.
• exclude-uri – Specifies URI strings
(up to 31 characters) to exclude
from compression.
• keep-accept-encoding enable –
Leaves the Accept-Encoding header
in HTTP requests from clients
instead of removing the header.
• level – Specifies the compression
level, 1-9. Each level provides a
higher compression ratio, begin-
ning with level 1, which provides
the lowest compression ratio. A
higher compression ratio results in a
smaller file size after compression.
However, higher compression levels
also require more CPU processing
than lower compression levels, so
performance can be affected.
• minimum-content-length – Speci-
fies the minimum length (in bytes) a
server response can be in order to be
compressed. The length applies to
the content only and does not
include the headers. You can specify
0-2147483647 bytes.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Compression Compression is disabled by default.
(cont.) When it is enabled, the compression
options have the following defaults:
• content-type – “text” and “applica-
tion” included by default
• exclude-content-type – not set
• exclude-content – not set
• keep-accept-encoding – disabled
• level – 1
• minimum-content-length – 120
bytes
Header insert / Inserts the specified header into an HTTP request or String of 1-256 characters
replace reply. Default: Not set
[no] request-header-insert
field:value [insert-always |
insert-if-not-exist]
[no] response-header-insert
field:value [insert-always |
insert-if-not-exist]
Note: These options are not supported with the fast-
http service type. The AX device does not allow an
HTTP template with any of the header erase or
header insert options to be bound to a fast-http vir-
tual port. Likewise, the AX device does not allow
header options to be added to an HTTP template
that is already bound to a fast-http virtual port.
Header erase Erases the specified header from an HTTP request String of 1-256 characters
or reply. Default: Not set
[no] request-header-erase field
[no] response-header-erase field
Note: These options are not supported with the fast-
http service type. The AX device does not allow an
HTTP template with any of the header erase or
header insert options to be bound to a fast-http vir-
tual port. Likewise, the AX device does not allow
header options to be added to an HTTP template
that is already bound to a fast-http virtual port.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Host switching Selects a service group based on the value in the Each host string can be all or part of an
Host field of the HTTP header. The selection over- IP address or host name.
rides the service group configured on the virtual Default: Not set
port.
If the host-string does not match, the service group
configured on the virtual port is used.
Selection is performed using the following match
filters:
• starts-with host-string – matches only if the
hostname or IP address starts with host-string.
• contains host-string – matches if the host-string
appears anywhere within the hostname or host IP
address.
• ends-with host-string – matches only if the host-
name or IP address ends with host-string.
The match options are always applied in the order
listed above, regardless of the order in which they
appear in the configuration. The service group for
the first match is used.
If a host name matches on more than one match fil-
ter of the same type, the most specific match is used.
[no] host-switching
{starts-with |contains | ends-with}
host-string service-group service-
group-name
Client IP insert Inserts the client’s source IP address into HTTP String of 1-256 characters
headers. Default: Not set
[no] insert-client-ip When you enable this option, the client
[http-fieldname] [replace] IP address is inserted into the
Config > Service > Template > Application > HTTP X-ClientIP field by default, without
replacing any client IP addresses
already in the field.
Redirect rewrite Modifies redirects sent by servers by rewriting the Strings of 1-256 characters
matching URL string to the specified value before Default: Not set
sending the redirects to clients.
[no] redirect-rewrite
match url-string
rewrite-to url-string
D e s i g n 613 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Redirect rewrite Changes HTTP redirects sent by servers into Strings of 1-256 characters
secure HTTPS redirects before sending the redirects to cli- Default: Not set
ents.
[no] redirect-rewrite secure
{port tcp-portnum}
Strict Forces the AX device to perform the server selec- Enabled or disabled
transaction tion process anew for every HTTP request. Without Default: Disabled
switching this option, the AX device reselects the same server
for subsequent requests (assuming the same server
group is used), unless overridden by other template
options.
[no] strict-transaction-switch
URL switching Selects a service group based on the URL string Strings of 1-256 characters
requested by the client. The selection overrides the Default: Not set
service group configured on the virtual port.
[no] url-switching
{starts-with | contains |
ends-with} url-string
If the URL-string does not match, the service group
configured on the virtual port is used.
filters:
• starts-with url-string – matches only if the URL
starts with url-string.
• contains url-string – matches if the url-string
appears anywhere within the URL.
• ends-with url-string – matches only if the URL
ends with url-string.
If a URL matches on more than one match filter of
the same type, the most specific match is used.
• Note: You can configure a maximum of 16 URL
switching rules in a template. If you need to use
more, use aFleX policies.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
URL hash Selects a service group based on the hash value of First or last
persistence the first or last bytes of the URL string. The bytes 4-128 bytes
(also called URL option specifies how many bytes to use to calculate Default: Not set
hash switching) the hash value.
Optionally, you can use URL hashing with either
URL switching or host switching. Without URL
switching or host switching configured, URL hash
switching uses the hash value to choose a server
within the default service group. If URL switching
or host switching is configured, for each HTTP
request, the AX device first selects a service group
based on the URL or host switching values, then
calculates the hash value and uses it to choose a
server within the selected service group.
[no] url-hash-persist
{first | last} bytes
Policy Template Parameters

Table 23 lists the parameters you can configure in Policy-Based SLB
(PBSLB) templates.
TABLE 23 Policy Template Parameters

[no] slb template policy template- Default: None.
name
Config > Service > Template > Application > Policy
Black/white list Binds a black/white list to the virtual ports that use Name of a configured black/white list.
name this template. Default: None.
[no] bw-list name file-name
Action for over- Specifies the action to take for traffic that is over the Reset or drop
limit traffic limit. Default: drop
[no] bw-list over-limit {drop | reset}
Matching based Matches black/white list entries based on the cli- Enabled or Disabled
on destination IP ent’s destination IP address. Default: Disabled. Matching is based
address [no] use-destination-ip on the client’s source IP address.
D e s i g n 615 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 23 Policy Template Parameters (Continued)
Action Specifies the action to take for clients in the black/ The following settings are config-
white list. urable:
[no] bw-list id id • List ID – ID of the black/white list.
{service service-group-name | • Group ID – Group ID in the black/
drop | reset} white list.
[logging [minutes] [fail]]
• Service-group name – Name of an
Config > Service > Template > Application > Policy SLB service group on the AX Series
device.
Note: If the option to use default selection if pre- • Action:
ferred server selection fails is enabled on the virtual • Drop – Drops new connections
port, log messages will never be generated for until the number of concurrent
server-selection failures. To ensure that messages connections on the virtual port
are generated to log server-selection failures, dis- falls below the port’s connection
able the option on the virtual port. This limitation limit. (The connection limit is set
does not affect failures that occur because a client is in the black/white list.)
over their PBSLB connection limit. These failures
• Reset – Resets new connections
are still logged.
until the number of concurrent
connections on the virtual port
falls below the connection limit.
• Logging – Enables logging. You can
specify the number of minutes
between log messages. This option
reduces overhead caused by fre-
quent recurring messages. You can
specify a logging interval from 0 to
60 minutes. To send a separate mes-
sage for each event, set the interval
to 0.
Defaults:
• List ID – None
• Group ID – None
• Action – Not set
• Logging – Disabled. If you enable
logging, the default for minutes is 3.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Source-IP Persistence Template Parameters

Table 24 lists the parameters you can configure in source-IP persistence
templates.
TABLE 24 Source-IP Persistence Template Parameters

[no] slb template persist source-ip Default: “default”. The default tem-
Config > Service > Template > Persistent > Source below.
IP Persistence
Persistence Granularity of persistence: One of the following:
granularity • Port – Traffic from a given client to the same vir- • Port (selectable in the GUI but not
tual port is always sent to the same real port. This in the CLI)
is the most granular setting. • Server
• Server – Traffic from a given client to the same • Service-group
VIP is always sent to the same real server, for any
Default: Port
service port requested by the client.
• Service-group – This option is applicable if you
also plan to use URL switching or host switching.
If you use the Service-group option, URL or host
switching is used for every request to select a ser-
vice group. The first time URL or host switching
selects a given service group, the load-balancing
method is used to select a real port within the ser-
vice group. The next time URL or host switching
selects the same service group, the same real port
is used. Thus, service group selection is per-
formed for every request, but once a service
group is selected for a request, the request goes to
the same real port that was selected the first time
that service group was selected.
Note: To use URL switching or host switching, you
also must configure an HTTP template with the
Host Switching or URL Switching option.
[no] match-type
Config > Service > Template > Persistent > Source
IP Persistence
D e s i g n 617 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 24 Source-IP Persistence Template Parameters (Continued)
Hashing netmask Granularity of IP address hashing for server port Valid IPv4 network mask
selection. Default: 255.255.255.255
You can specify an IPv4 network mask in dotted
decimal notation.
• To configure server port selection to occur on a
per subnet basis, configure the network mask to
indicate the subnet length. For example, to send
all clients within a subnet such as 10.10.10.x,
192.168.1.x, and so on (“class C” subnets) to the
same server port, use mask 255.255.255.0. SLB
selects a server port for the first client in a given
subnet, the sends all other clients in the same sub-
net to the same port.
• To configure server port selection to occur on a
per client basis, use mask 255.255.255.255. SLB
selects a server port for the first request from a
given client, the sends all other requests from the
same client to the same port. (This is the default.)
[no] netmask ipaddr
IP Persistence
Persistence Number of minutes the mapping of a client source 1-1000 minutes
Timeout IP to a real server persists after the last time traffic Default: 5 minutes
from the client is sent to the server.
IP Persistence
client source IP address.
IP Persistence
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Server SSL Template Parameters

Table 24 lists the parameters you can configure in Server SSL templates.
TABLE 25 Server SSL Template Parameters

[no] slb template server-ssl Default: “default”. The default tem-
Config > Service > Template > SSL > Server SSL below.
Certificate Name of the Certificate Authority (CA) certificate Name of a CA certificate imported
Authority (CA) to use for validating server certificates. onto the AX device
certificate name [no] ca-cert cert-name Default: None
Config > Service > Template > SSL > Server SSL
on page 467.)
Ciphers Cipher suite to support for decrypting certificates One or more of the following:
from servers. • SSL3_RSA_DES_192_CBC3_SHA
[no] cipher • SSL3_RSA_DES_40_CBC_SHA
Config > Service > Template > SSL > Server SSL • SSL3_RSA_DES_64_CBC_SHA
_MD5
_SHA
Default: All the above are enabled.
Note: If you add, remove, or replace a certificate in a server-SSL template that is

already bound to a VIP, the AX device does not use the changes. To
change the certificates in a server-SSL template, unbind the template from
the VIP and delete the template. Configure a new template with the
changed certificates and bind the new template to the VIP.
D e s i g n 619 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SIP Template Parameters

Table 26 lists the parameters you can configure in SIP templates.
TABLE 26 SIP Template Parameters

[no] slb template sip template-name Default: “default”. The default tem-
Config > Service > Template > Application > SIP plate has the default values listed
below.
Registrar service Name of a configured service group of SIP Regis- Name of a configured service group
group trar servers.
[no] registrar service-group
group-name
Config > Service > Template > Application > SIP
Header erase Erases the specified SIP header from the SIP request String of 1-256 characters
before sending it to a SIP Registrar. Default: None
[no] header-erase string
Header insert Inserts the specified SIP header into the SIP request String of 1-256 characters
[no] header-insert string
Header replace Replaces the specified SIP header in the SIP request String of 1-256 characters
[no] header-replace string
new-string
Reverse NAT Disables reverse NAT based on the IP ID of a configured extended ACL.
disable addresses in an extended ACL. This option is Default: Not set. Reverse NAT is
useful in cases where a SIP server needs to enabled for all traffic from the server.
reach another server, and the traffic must pass
through the AX device.
Configure the extended ACL to match on the SIP
server IP address or subnet as the source address,
and matches on the destination server’s IP address
or subnet as the destination address.
[no] pass-real-server-ip-for-acl
acl-id
Call timeout Number of minutes a call can remain idle before the 1-250 minutes
AX Series terminates it. Default: 30 minutes
[no] timeout minutes
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SMTP Template Parameters

Table 27 lists the parameters you can configure in SMTP templates.
TABLE 27 SMTP Template Parameters

[no] slb template smtp Default: “default”. The default tem-
Config > Service > Template > Application > below.
SMTP
Domain name Selects a service group based on the domain of the Strings
switching client. You can specify all or part of the client Default: Not set. All client domains
domain name. match, and any service group can be
This option is applicable when you have multiple used.
SMTP service groups.
If the client domain does not match, the service
group configured on the virtual port is used.
filters:
• starts-with string – matches only if the domain
name starts with string.
• contains string – matches if the string appears
anywhere within the domain name.
• ends-with string – matches only if the domain
name ends with string.
If a domain name matches on more than one match
filter of the same type, the most specific match is
used.
[no] client-domain-switching
{starts-with | contains | ends-
with}
string service-group group-name
SMTP
D e s i g n 621 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 27 SMTP Template Parameters (Continued)
STARTTLS Disables support of certain SMTP commands. If a Any of the following: VRFY, EXPN,
command dis- client tries to issue a disabled SMTP command, the TURN
able AX sends the following message to the client: “502 Default: VRFY, EXPN, and TURN are
- Command not implemented” enabled
[no] command-disable [vrfy] [expn]
[turn]
Note: To disable all three commands, simply enter
the following: command-disable
SMTP
Email server Email server domain. This is the domain for which String
domain the AX Series device provides SMTP load balanc- Default: “mail-server-domain”
ing.
[no] server-domain name
SMTP
Service ready Text of the SMTP service-ready message sent to cli- String
message ents. The complete message sent to the client is con- Default: “ESMTP mail service ready”
structed as follows:
200 - smtp-domain service-ready-string
[no] service-ready-message string
SMTP
STARTTLS Specifies whether use of STARTTLS by clients is One of the following:
requirement required. • Disabled – Clients cannot use
starttls STARTTLS. Use this option if you
{disable | optional | enforced} need to disable STARTTLS support
Config > Service > Template > Application > but you do not want to remove the
SMTP configuration.
• Optional – Clients can use START-
TLS but are not required to do so.
• Enforced – Before any mail transac-
tions are allowed, the client must
issue the STARTTLS command to
establish a secured session. If the
client does not issue the STARTTLS
command, the AX sends the follow-
ing message to the client: "530 -
Must issue a STARTTLS command
first”
Default: Disabled
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
SSL Session-ID Persistence Template Parameters

Table 28 lists the parameters you can configure in SSL session-ID persis-
tence templates.
TABLE 28 SSL Session-ID Persistence Template Parameters

[no] slb template persist ssl-sid Default: “default”. The default tem-
Config > Service > Template > Persistent > below.
SSL Session ID Persistence
Persistence Number of minutes the mapping of an SSL session 1-250 minutes
Timeout ID to a real server and real server port persists after Default: 5 minutes
the last time traffic using the session ID is sent to
the server.
SSL session ID.
Streaming-Media Template Parameters

Table 29 lists the parameters you can configure in streaming-media tem-
plates.
TABLE 29 Streaming-media Template Parameters

[no] slb template streaming-media Default: “default”. The default tem-
Config > Service > Template > Application > RTSP below.
D e s i g n 623 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 29 Streaming-media Template Parameters (Continued)
URI switching Service group to which to send requests for a spe- Name of a configured service group
cific URI. Default: Requests are sent to the ser-
[no] uri-switching stream vice group that is bound to the virtual
uri-string port.
Config > Service > Template > Application > RTSP
TCP Template Parameters

Table 30 lists the parameters you can configure in TCP templates.
TABLE 30 TCP Template Parameters

[no] slb template tcp template-name Default: “default”. The default tem-
Config > Service > Template > L4 > TCP plate has the default values listed
below.
Idle timeout Number of seconds a connection can remain idle 60-15000 seconds
before the AX Series device terminates it. Default: 120 seconds
Config > Service > Template > L4 > TCP
Server reset Sends a TCP RST to the real server after a session Enabled or disabled
times out. Default: Disabled
[no] reset-fwd
Client reset Sends a TCP RST to the client after a session times Enabled or disabled
out. Default: Disabled
Note: If the server is Down, this option immediately
sends the RST to the client and does not wait for the
session to time out.
[no] reset-rev
Initial window Sets the initial TCP window size in SYN ACK 1-65535 bytes
size packets to clients. The TCP window size in a SYN Default: The AX device uses the TCP
ACK or ACK packet specifies the amount of data window size set by the client or server.
that a client can send before it needs to receive an
ACK.
[no] initial-window-size bytes
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TCP-Proxy Template Parameters

Table 30 lists the parameters you can configure in TCP-proxy templates.
TABLE 31 TCP-Proxy Template Parameters

[no] slb template tcp-proxy Default: “default”. The default tem-
Config > Service > Template > TCP Proxy below.
FIN timeout Number of seconds that a connection can be in the 1-60 seconds
FIN-WAIT or CLOSING state before the AX Series Default: 5 seconds
terminates the connection.
[no] fin-timeout seconds
Config > Service > Template > TCP Proxy
Idle timeout Number of minutes that a connection can be idle 60-15000 seconds
before the AX Series terminates the connection. Default: 600 seconds
Nagle algorithm Enables Nagle congestion compression (described Enabled or disabled
in RFC 896). Default: Disabled
[no] nagle
Receive buffer Maximum number of bytes addressed to the port 1-2147483647 bytes
size that the AX Series will buffer. Default: 87380 bytes
[no] receive-buffer number
Retransmit Number of times the AX Series can retransmit a 1-20
retries data segment for which the AX Series does not Default: 3
receive an ACK.
[no] retransmit-retries number
SYN retries Number of times the AX Series can retransmit a 1-20
SYN for which the AX Series does not receive an Default: 5
ACK.
[no] syn-retries number
Time-Wait Number of seconds that a connection can be in the 1-60 seconds
TIME-WAIT state before the AX Series transitions Default: 5 seconds
it to the CLOSED state.
[no] timewait number
D e s i g n 625 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 31 TCP-Proxy Template Parameters (Continued)
Transmit buffer Number of bytes sent by the port that the AX Series 1-2147483647
size will buffer. Default: 16384 bytes
[no] transmit-buffer number
Initial window Sets the initial TCP window size in SYN ACK 1-65535 bytes
size packets to clients. The TCP window size in a SYN Default: The AX device uses the TCP
ACK or ACK packet specifies the amount of data window size set by the client or server.
that a client can send before it needs to receive an
ACK.
[no] initial-window-size bytes
UDP Template Parameters

Table 32 lists the parameters you can configure in UDP templates.
TABLE 32 UDP Template Parameters

[no] slb template udp template-name Default: “default”. The default tem-
Config > Service > Template > L4 > UDP plate has the default values listed
below.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 32 UDP Template Parameters (Continued)
Aging Specifies how quickly sessions are terminated when One of the following:
the request is received. • Immediate – Sessions are termi-
aging {immediate | short [seconds]} nated as soon as a response is
Config > Service > Template > L4 > UDP received.
• Short – The AX device waits briefly
before terminating a UDP session.
Note: If you are configuring DNS load balancing,
A10 Networks recommends using the immediate • If you specify the number of sec-
option. onds, the AX device waits the
specified number of seconds after
a request is received and sent out
to the server, then terminates the
session. You can specify 1-32
seconds.
• If you do not specify the number
of seconds, sessions are termi-
nated after the SLB maximum
session life (MSL) time expires,
after a request is received and
sent out to the server. (See “Glo-
bal SLB Parameters” on
page 628.)
Default: Not set. The idle timeout
value in the template is used
instead.
Idle timeout Number of seconds a connection can remain idle 60-15000 seconds
before the AX Series terminates it. Default: 120 seconds
[no] idle-timeout number
Config > Service > Template > L4 > UDP
Server Configures the AX device to select another real Enabled or disabled
reselection server if the server that is bound to an active con- Default: Disabled
nection goes down. Without this option, another
server is not selected.
[no] re-select-if-server-down
Config > Service > Template > L4 > UDP
D e s i g n 627 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Global SLB Parameters

Table 34 lists the SLB parameters you can configure globally.
TABLE 33 Global SLB Parameters

Server state Globally disables or re-enables a real or virtual Enabled or disabled
server. Default: Enabled
{disable | enable} slb server
[server-name] [port port-num]
{disable | enable}
slb virtual-server [server-name]
[port port-num]
Config > Service > SLB > Server

DSR health Enables Layer 4-7 health checking in Direct Server Enabled or disabled
check Return (DSR) configurations. Default: Disabled
[no] slb dsr-health-check-enable
Config > Service > SLB > Global > Settings
Note: Additional configuration is required. See
“Configuring Health Monitoring of Virtual IP
Addresses in DSR Deployments” on page 308.
Graceful shut- Allows currently active sessions time to terminate 1-65535 seconds (about 18 hours)
down normally before shutting down a service when you Default: Not set; all existing connec-
delete the real or virtual port providing the service. tions on the server or port are immedi-
[no] slb graceful-shutdown ately terminated.
grace-period By default, graceful shutdown applies
[server | virtual-server] to all real and virtual servers, and
[after-disable] applies only to deleted servers, not to
Config > Service > SLB > Global > Settings disabled ones.
Maximum ses- Maximum session life following completion of a 1-40 seconds
sion life TCP flow. Default: 2 seconds
[slb] msl-time seconds
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 33 Global SLB Parameters (Continued)
Hardware-based Enables system-wide protection against TCP SYN Disabled or Enabled
SYN cookies flood attacks. SYN cookies enable the AX device to On-Threshold – 0-2147483647 half-
continue to serve legitimate clients during a TCP open connections
SYN flood attack, without allowing illegitimate Off-Threshold – 0-2147483647 half-
traffic to consume system resources. open connections
• On-Threshold – Specifies the maximum number Default: Disabled
of concurrent half-open TCP connections
allowed on the AX device, before SYN cookies
are enabled. If the number of halfopen TCP con- Note: If you leave the On-Threshold
nections exceeds the on-threshold, the AX device and Off-Threshold fields blank, SYN
enables SYN cookies. You can specify 0- cookies are enabled and are always on
2147483647 half-open connections. regardless of the number of half-open
TCP connections present on the AX
• Off-Threshold - Specifies the minimum number device.
of concurrent half-open TCP connections for
which to keep SYN cookies enabled. If the num-
ber of half-open TCP connections falls below this
level, SYN cookies are disabled. You can specify
0-2147483647 halfopen connections.
[no] syn-cookie
[on-threshold num off-threshold
num]
Note: This option is not supported on model
AX 2000 or AX 2100.
Use of IP pool Enables use of IP pool default gateways to forward Enabled or disabled
default gateways traffic from real servers. Default: Disabled
by real servers When this option is enabled, the AX device checks
the configured IP NAT pools for an IP address range
that includes the server IP address (the source
address of the traffic). If the address range in a pool
does include the server’s IP address, and a default
gateway is defined for the pool, the AX device for-
wards the server traffic through the pool’s default
gateway.
[no] slb snat-gwy-for-l3
Note: This parameter is not configurable using the
GUI.
D e s i g n 629 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Source-IP based Protects the system from excessive connection Connection limit – 1-1000000.
connection rate requests from individual clients. Limit period – One of the following:
limiting slb conn-rate-limit src-ip • 100 milliseconds (one tenth of a
conn-limit second)
per {100 | 1000}
• 1000 milliseconds (one second)
[shared]
[exceed-action [log] Scope – One of the following:
[lock-out lockout-period]] • Shared – Connection limit applies
Note: The current release does not support configu- as an aggregate to all virtual ports.
ration of this feature using the GUI. • Not shared – Connection limit
For more information about this feature, see applies separately to each virtual
“Source-IP Based Connection Rate Limiting” on port. (This is the default behavior.
page 543. There is no “Not shared” option.)
Exceed actions – 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. Optionally, you can enable
one or both of the following additional
exceed actions:
• Logging – Generates a log message
when a client exceeds the connec-
tion limit.
• Lockout – Locks out the client for a
specified number of seconds. Dur-
ing the lockout period, all connec-
tion requests from the client are
dropped. The lockout period can be
1-3600 seconds (1 hour). There is
no default.
Default: Not configured
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Auto-port trans- Configures a range of protocol ports for auto-trans- Range number: 1-3
lation range lation. Auto-translation allows real server protocol Default: Protocol ports 0-1023
port numbers to differ from the protocol port num- assigned to each range
bers used on a virtual server bound to the real serv-
ers, in configurations that do not use source NAT.
You do not need to reconfigure an auto-port transla-
tion range unless the real or virtual port number is
non-standard (above 1023).
Note: If you configure a port range, the ports in the
range are reserved and can not be used by other fea-
tures (for example, NAT pools). To prevent deple-
tion of available ports, it is recommended to use a
narrow port range.
Note: To determine whether you need to change an
auto-port translation range for your configuration,
see “Auto-Port Translation” on page 675.
[no] slb auto-translate-port range
number
range-start port-num
range-end port-num
Config > Service > SLB > Global > Auto Transla-
tion
Hardware-based Enables hardware-based compression. Enabled or disabled
content When you enable hardware-based compression, all Default: Disabled
compression compression settings configured in HTTP tem-
plates, except the compression level, are used.
Hardware-based compression always uses the same
compression level, regardless of the compression
level configured in an HTTP template.
Hardware-based compression is available using an
optional hardware module in new AX devices, on
the following models: AX 2100, AX 2200, AX
3100, and AX 3200. If this option does not appear
on your AX device, the device does not contain a
compression module.
[no] slb hw-compression
Note: This parameter is not configurable using the
GUI.
Fast-path Enables fast-path processing, wherein the AX Enabled (slb fast-path-dis-
processing device does not perform a deep inspection of every able) or disabled (no slb fast-
field within a packet. path-disable)
[no] slb fast-path-disable
Note: This parameter is not configurable using the Default: Enabled. Deep inspection of
GUI. every packet field is enabled.
D e s i g n 631 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Real Server Parameters

Table 34 lists the parameters you can configure on real servers.
TABLE 34 Real Server Parameters

Configurable in
Supported Real Server
Parameter Description and Syntax Values Template?
Server name Name and IP address of the real server. String of 1-31 N/A
and IP address The name is not required to be the hostname config- characters
ured on the real server. The IP address must be the IPv4 or IPv6
real IP address of the server. address
[no] slb server server-name ipaddr Default: None con-
Config > Service > SLB > Server figured
Server state State of the real server. Enabled or disa- No
[no] {disable | enable} bled
Config > Service > SLB > Server Default: Enabled
Real server Configuration template of real server parameters. Name of a config- N/A
template [no] slb template server template- ured real server
name template
Config > Service > SLB > Template > Server Default: “Default”
real server tem-
plate
Health check Enables or disables Layer 3 health monitoring and Enabled or disa- Yes
species the monitor to use. bled
[no] health-check Name of a config-
[monitor-name] ured health moni-
Config > Service > SLB > Server tor
Default: Enabled;
ping (ICMP)
Connection Number of concurrent connections allowed on a real 1-1000000 (one Yes
limit server. million) if config-
[no] conn-limit max-connections ured on the real
server; 1-1048575
if configured in the
server template
Default: 1000000
if configured on
the real server;
1048575 if config-
ured in the server
template
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 34 Real Server Parameters (Continued)
Configurable in
Connection Maximum number of connections the server can 1-1000000 (one Yes, but as addi-
resume have before the AX device resumes use of the million) connec- tional parameter
server. Use does not resume until the number of tions with conn-limit
connections reaches the configured maximum or Default: Not set. command (CLI) or
less. The AX device is additional field
[no] conn-resume connections allowed to start under Connection
sending new con- Limit Status (GUI)
nection requests to
the server as soon
as the number of
connections on the
server falls back
below the connec-
tion limit.
Service port TCP or UDP port number. Transport protocol: N/A
[no] port port-num {tcp | udp} TCP or UDP
Config > Service > SLB > Server - Port tab Port number:
0-65534
(For parameters you can set on the service port, see
“Real Service Port Parameters” on page 634.) Default: None con-
figured
Slow start Allows time for a server to ramp up after the server Enabled or dis- Yes
is enabled or comes online, by temporarily limiting abled Note: Template
the number of new connections on the server. Default: Disabled configuration of
[no] slow-start this feature pro-
Config > Service > SLB > Server - Port tab vides additional
options. See
“Slow-Start” on
page 294.
Weight Administrative weight of the server, used for 1-100 No
weighted load balancing (weighted-least-connection Default: 1
or weighted-round-robin).
[no] weight num
External IP External IP address, used for reaching a server in a Valid IP address No
address private network from outside the network. Default: Not set
[no] external-ip ipaddr
Note: This parameter can not be configured using
the GUI.
D e s i g n 633 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Real Service Port Parameters
TABLE 34 Real Server Parameters (Continued)
Configurable in
Spoofing Enables support for a spoofing cache server. A Enabled or disa- No
cache spoofing cache server uses the client’s IP address bled
instead of its own as the source address when Default: Disabled
obtaining content requested by the client.
This command applies to the Transparent Cache
Switching (TCS) feature. (see .)
[no] spoofing-cache
Note: This parameter can not be configured using
the GUI.

Table 35 lists the parameters you can configure on individual service ports
on real servers.
TABLE 35 Real Service Port Parameters

Configurable in
Supported Real Port
Service port TCP or UDP port number. TCP or UDP N/A
number and [no] port port-num {tcp | udp} 0-65534
transport pro- Default: Not set
Config > Service > SLB > Server - Port tab
tocol
In the CLI, this is set at the real server configuration Note: Port number
level. In the GUI, this is set on the Port tab. 0 is a wildcard port
used for IP proto-
col load balanc-
ing. (For more
information, see
“IP Protocol Load
Balancing” on
page 221.)
Service port State of the service port. Enabled or disa- No
state [no] {disable | enable} bled
Config > Service > SLB > Server - Port tab Default: Enabled
Real server Configuration template of real port parameters. Name of a config- N/A
port template [no] slb template port template- ured real port tem-
name plate
Config > Service > SLB > Template > Server Port Default: “Default”
real port template
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 35 Real Service Port Parameters (Continued)
Configurable in
Supported Real Port
Health check Enables or disables health monitoring and species Enabled or disa- Yes
the monitor to use. bled
[no] health-check [monitor-name] Name of a config-
Config > Service > SLB > Server - Port tab ured health moni-
tor
Default: The AX
performs the
default TCP or
UDP check every
30 seconds. (See
“Default Health
Checks” on
page 297.)
Connection Number of concurrent connections allowed on the 1-1000000 (one Yes
limit service port. million) if config-
[no] conn-limit max-connections ured on the server
port; 1-1048575 if
configured in the
server port tem-
plate
Default: 1000000
if configured on
the server port;
1048575 if config-
ured in the server
port template
Connection Maximum number of connections the port can have 1-1000000 (one Yes, but as addi-
resume before the AX device resumes use of the port. Use million) connec- tional parameter
does not resume until the number of connections tions with conn-limit
reaches the configured maximum or less. Default: Not set. command (CLI) or
[no] conn-resume connections The AX device is additional field
allowed to start under Connection
sending new con- Limit Status (GUI)
nection requests to
the port as soon as
the number of con-
nections on the
port falls back
below the connec-
tion limit.
Weight Administrative weight of the service port, used for 1-100 Yes
weighted load balancing (service-weighted-least- Default: 1
connection).
[no] weight num
D e s i g n 635 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Service Group Parameters
TABLE 35 Real Service Port Parameters (Continued)
Configurable in
Supported Real Port
No-SSL Disables SSL for server-side connections. This Enabled or No
option is useful if a server-SSL template is bound to disabled
the virtual port that uses this real port, and you want Default: Disabled
to disable encryption on this real port. (SSL is enabled)
Encryption is disabled by default, but it is enabled
for server-side connections when the real port is
used by a virtual port that is bound to a server-SSL
template.
[no] no-ssl

Table 35 lists the parameters you can configure in service groups.
TABLE 36 Service Group Parameters

Service group Name of a service group and the transport protocol String of 1-31 characters
name and type used by service ports in the group. TCP or UDP
[no] slb service-group group-name Default: None configured
{tcp | udp}
Config > Service > SLB > Service Group
Member Real servers and service ports managed by the Name of a configured real server, and
group. a service port number configured on
[no] member server-name:portnum the server
[disable | enable] The priority can be 1-16.
[priority num] Default priority: 1
[template port template-name]
The enable | disable options change the server and
port state within the service group only.
The priority option enables you to designate some
real servers as backups (the lower priority servers)
to be used only if the higher priority servers all are
unavailable.
The template option binds a real port template to
the port.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 36 Service Group Parameters (Continued)
Load balancing Algorithm used to select a real server and service One of the following:
method port to fulfil a client’s request. • Fastest-response – Selects the server
[no] method lb-method with the fastest SYN-ACK response
Config > Service > SLB > Service Group time.
Note: The fastest-response algorithm takes effect • Least-connection – Selects the server
only if the traffic rate on the servers is at least 5 con- that currently has the fewest connec-
nections per second (per server). If the traffic rate is tions.
lower, the first server in the service group usually is • Service-least-connection – Selects
selected. the server port that currently has the
lowest number of total request bytes
and total response bytes, added
together. If there is a tie (two or
more server ports have the lowest
number of total request and
response bytes, combined), SLB
randomly selects a server port.
• Weighted-least-connection – Selects
a server based on a combination of
the server’s administratively
assigned weight and the number of
connections on the server.
• Service-weighted-least-connection
– Same as weighted-least-connec-
tion, but per service.
• Weighted-round-robin – Selects
servers in rotation, biased by the
servers’ administratively assigned
weights.
If the weight value is the same on
each server, this load-balancing
method simply selects the servers in
rotation.
Default: Round robin (simple rotation
without weighting)
Health monitor Assigns a health monitor to all members in the ser- The default health monitor (IP ping) or
vice group. the name of a configured health moni-
This option is useful in cases where the same server tor
provides content for multiple, independent sites. Default: Not set
When you use this feature, if a site is unavailable
(for example, is taken down for maintenance), the
server will fail the health check for that site, and cli-
ents will not be sent to the site. However, other sites
on the same server will pass their health checks, and
clients of those sites will be sent to the server.
D e s i g n 637 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Virtual Server Parameters
TABLE 36 Service Group Parameters (Continued)
Minimum active Uses backup servers even if some primary servers 1-63
members are up. To configure this parameter, specify the Default: Not set. Backup servers are
number of primary servers that can still be active used only if all primary servers are
before the backup servers are used. unavailable.
The skip-pri-set option specifies whether the When you configure this parameter,
remaining primary servers continue to be used. If the skip-pri-set option is disabled by
you use this option, the AX device uses only the default, for all load-balancing methods
backup servers and stops using any of the primary except round-robin. For round-robin
servers. (the default), skip-pri-set is always
[no] min-active-member num enabled and can not be disabled.
[skip-pri-set]

Table 37 lists the parameters you can configure on virtual servers.
TABLE 37 Virtual Server Parameters

Configurable in
Supported Virtual Server
Virtual server Name to identify the virtual server on the AX String of 1-31 N/A
name and vir- device, and the virtual IP address that clients will characters
tual IP address request. IPv4 or IPv6
[no] slb virtual-server name ipaddr address
Config > Service > SLB > Virtual Server Default: None con-
figured
Virtual server State of the virtual server. Enabled or disa- No
state [no] {disable bled
[when-all-ports-down] | Default: Virtual
enable} servers are
The when-all-ports-down option automatically dis- enabled by
ables the virtual server if all its service ports are default. The
down. If OSPF redistribution of the VIP is enabled, when-all-ports-
the AX device also withdraws the route to the VIP down option is
in addition to disabling the virtual server. disabled by
Config > Service > Server > Virtual Server default.
Note: The when-all-ports-down option is not con-
figurable using the GUI.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 37 Virtual Server Parameters (Continued)
Configurable in
Virtual server Configuration template of virtual server parameters. Name of a config- N/A
template [no] slb template virtual-server ured virtual server
template-name template
Config > Service > SLB > Template > Virtual Default: “Default”
Server virtual server tem-
plate
Virtual ser- Service port number and service type. Port number: N/A
vice port num- [no] port port-num service-type 0-65535
ber and service Service type:
Config > Service > SLB > Virtual Server - Port tab
type
Service type can be one of the following: • fast-http
• fast-http – Streamlined Hypertext Transfer Proto- • ftp
col (HTTP) service • http
• ftp – File Transfer Protocol • https
• http – HTTP • mms
• https – Secure HTTP (SSL) • rtsp
• mms – Multimedia Messaging Service • sip
• rtsp – Real Time Streaming Protocol • smtp
• sip – Session Initiation Protocol • ssl-proxy
• smtp – Simple Mail Transfer Protocol • tcp
• ssl-proxy – SSL proxy service • udp
• tcp – Transmission Control Protocol • others
• udp – User Datagram Protocol Default: None con-
• others – Wildcard port used for IP protocol figured
load balancing. (For more information, see
“IP Protocol Load Balancing” on page 221.)
(For parameters you can set on the service port, see
“Virtual Service Port Parameters” on page 640.)
ARP disable Disables or re-enables ARP replies from a virtual Enabled or dis- No
server. abled
[no] arp-disable Default: Disabled;
Config > Service > SLB > Virtual Server ARP replies are
enabled.
HA group ID HA group ID to use for session backup. 1-31 No
[no] ha-group group-id Default: Not set
D e s i g n 639 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Virtual Service Port Parameters
TABLE 37 Virtual Server Parameters (Continued)
Configurable in
VIP-based Enables dynamic failover based on server weight. 1-255 No
High Avail- The configured amount is subtracted from the HA Default: Not set
ability (HA) group’s priority value for each real server that goes
failover down.

Table 38 lists the parameters you can configure on individual service ports
on virtual servers.
TABLE 38 Virtual Service Port Parameters

Configurable in
Supported Virtual Port
Virtual ser- Service port number and service type. Port number: N/A
vice port num- [no] port port-num service-type 0-65535
ber and service Service type:
Config > Service > SLB > Virtual Server - Virtual
type
Server Port tab • fast-http
In the CLI, this is set at the virtual server configura- • ftp
tion level. In the GUI, this is set on the Virtual • http
Server Port tab.
• https
Service type can be one of the following:
• mms
• fast-http – Streamlined Hypertext Transfer Proto-
• rtsp
col (HTTP) service
• sip
• ftp – File Transfer Protocol
• smtp
• http – HTTP
• ssl-proxy
• https – Secure HTTP (SSL)
• tcp
• mms – Multimedia Messaging Service
• udp
• rtsp – Real Time Streaming Protocol
Default: None con-
• sip – Session Initiation Protocol
figured
• smtp – Simple Mail Transfer Protocol
• ssl-proxy – SSL proxy service
• tcp – Transmission Control Protocol
• udp – User Datagram Protocol
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
TABLE 38 Virtual Service Port Parameters (Continued)
Configurable in
Virtual State of the virtual service port. Enabled or disa- No
service port [no] {disable | enable} bled
state Default: Enabled
Server Port tab
Virtual port Configuration template of virtual port parameters. Name of a config- N/A
template [no] slb template virtual-port tem- ured virtual port
plate-name template
Config > Service > SLB > Template > Default: “Default”
Virtual Server Port virtual port tem-
plate
Service group Service group bound to the virtual service port. The Name of a config- No
AX device uses real servers and ports in the service ured service group
group to fulfill requests for the virtual service port. Default: Not set
Server Port tab
Template Connection or application template to use for ser- Template type: N/A
vice port parameters. One of the types
[no] template template-type described in “Ser-
template-name vice Template
Parameters” on
page 599.
Server Port tab
Template name:
Name of a config-
ured template.
Default: Depends
on whether the
template type has a
default and
whether the ser-
vice type uses that
template type. (See
“Service Template
Parameters” on
page 599.)
D e s i g n 641 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configurable in
Access ID of an ACL. Valid standard or No
Control List If you do not also specify a NAT pool name, the extended ACL ID
(ACL) ACL is used to deny or permit inbound traffic on the Default: None
service port.
If you do specify a NAT pool name, the ACL does
not permit or deny traffic. Instead, it binds the
source addresses in the ACL to the NAT pool. The
NAT pool is used only for the client addresses in the
ACL.
[no] access-list acl-num
[source-nat-pool pool-name]
Server Port tab
aFleX policy aFleX policy to use for custom SLB processing. Name of a config- No
[no] aflex aflex-name ured aFleX policy.
Config > Service > SLB > Virtual Server - Virtual Default: None
Server Port tab
Connection Number of concurrent connections allowed on the 0-8000000 (8 mil- Yes, but the range
limit virtual service port. lion) is 1-1048575
[no] conn-limit number 0 means no limit.
Config > Service > SLB > Virtual Server - Virtual Default: Not set
Server Port tab
Session syn- Backs up session information on the Standby AX Enabled or dis- No
chronization device in an HA configuration. When this option is abled
(connection enabled, sessions remain up even following a Default: Disabled
mirroring) failover.
[no] ha-conn-mirror
Server Port tab
Direct Server Disables destination NAT, so that server responses Enabled or dis- No
Return (DSR) go directly to clients. abled
[no] no-dest-nat Disabled: Destina-
Config > Service > SLB > Virtual Server - Virtual tion NAT is
Server Port tab enabled.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configurable in
Policy-based Uses a black/white list to allow or deny clients who Name of a config- No
SLB (PBSLB) request the service port, select service groups for ured black/white
allowed clients, and drop or reset connections if the list. The list must
connection limit is reached. be imported onto
[no] pbslb bw-list name the AX device.
[no] pbslb id id Default: Not set
{service service-group-name |
drop | reset}
[logging [minutes [fail]]]
[no] pbslb over-limit {drop |
reset}
Note: In the GUI, PBSLB can only be configured
and applied using PBSLB policy templates.
Note: If the option to use default selection if pre-
ferred server selection fails 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, dis-
able the 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.
(For information about PBSLB, see “Policy-Based
SLB (PBSLB)” on page 563.)
Source NAT Name of a pool of IP addresses to use for Network Name of a config- No
Address Translation (NAT). ured source NAT
[no] source-nat pool pool-name pool.
Config > Service > SLB > Virtual Server - Virtual Default: Not set
Server Port tab
Note: This option is not applicable to the mms or
rtsp service types.
Software- Protects against TCP SYN floods. Enabled or dis- No
based protec- [no] syn-cookie [sack] abled
tion against Default: Disabled
TCP SYN Config > Service > SLB > Virtual Server - Virtual
flood attacks Server Port tab
Note: If hardware-based SYN cookies are sup-
ported on the AX model you are configuring, use
that version of the feature instead. (See “SYN
Cookies” on page 535.)
D e s i g n 643 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configurable in
Use receive Sends replies to clients back through the last hop on Enabled or dis- No
hop for which the request for the virtual port's service was abled
responses received. Default: Disabled
[no] use-rcv-hop-for-resp
Server Port tab
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configurable in
Default selec- Continues checking for an available server in other Enabled or disa- No
tion if pre- service groups if all of the servers are down in the bled
ferred server first service group selected by SLB. Default: Enabled
selection fails During SLB selection of the preferred server to use
for a client request, SLB checks the following con-
figuration areas, in the order listed:
1. Layer 3-4 configuration items:

a. aFleX policies triggered by Layer 4 events
b. Policy-based SLB (black/white lists).
PBSLB is a Layer 3 configuration item
because it matches on IP addresses in
black/white lists.
2. Layer 7 configuration items:

a. Cookie switching
b. aFleX policies triggered by Layer 7 events
c. URL switching
d. Host switching
3. Default service group. If none of the items

above results in selection of a server, the
default service group is used.
• If the configuration uses only one service
group, this is the default service group.
• If the configuration uses multiple service
groups, the default service group is the
one that is used if none of the templates
used by the configuration selects another
service group instead.
The first configuration area that matches the client

or VIP (as applicable) is used, and the client request
is sent to a server in the service group that is appli-
cable to that configuration area. For example, if the
client’s IP address in a black/white list, the service
group specified by the list is used for the client
request.
[no] def-selection-if-pref-failed
Server Port tab
D e s i g n 645 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configurable in
GSLB enable Enables a DNS port to function as a proxy for Glo- Enabled or dis- No
(DNS proxy bal Server Load Balancing (GSLB) for this virtual abled
ports only) port. Default: Disabled
[no] gslb-enable
Server Port tab
Note: This option applies only to DNS ports and
only for a virtual service port on a virtual server that
will be used as a DNS proxy on the GSLB AX
device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
SSL Certificate Management
This chapter describes how to install SSL keys, certificates, and Certificate
Revocation Lists (CRLs) on the AX device. Installing these SSL resources
on the AX device enables the AX device to provide SSL services on behalf
of real servers.
You can use the AX device to offload SSL processing from servers or, for
some types of traffic, you can use the AX device as an SSL proxy. (For
more information about SSL offload and SSL proxy, see “SSL Offload and
SSL Proxy” on page 177.)
Overview
Some types of client-server traffic need to be encrypted for security. For
example, traffic for online shopping must be encrypted to secure sensitive
account information from being stolen.
Commonly, clients and servers use Secure Sockets Layer (SSL) or Trans-
port Layer Security (TLS) to secure traffic. For example, a client that is
using a shopping application on a server will encrypt data before sending it
to the server. The server will decrypt the client’s data, then send an
encrypted reply to the client. The client will decrypt the server reply, and so
on.
Note: SSL is an older version of TLS. The AX device supports SSL version 3.0
and TLS version 1.0. The AX device also supports RFC 3268: “AES
Ciphersuites for TLS”. For simplicity, elsewhere this document and other
AX user documents use the term “SSL” to mean both SSL and TLS.
Note: The AX device supports Privacy Enhanced Mail (PEM) format for certif-
icate files and CRLs. AX SSL processing supports PEM format and RSA
encryption.
SSL Process
SSL works using certificates and keys. Typically, a client will begin a secure
session by sending an HTTPS request to a VIP. The request begins an SSL
handshake. The AX device will respond with a digital certificate. From the
client’s perspective, this certificate comes from the server. Once the SSL
handshake is complete, the client begins an encrypted client-server session
with the AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Figure 161 shows a simplified example of an SSL handshake. In this exam-
ple, the AX device is acting as an SSL proxy for backend servers.
FIGURE 161 Typical SSL Handshake (simplified)
To begin, the client sends an HTTPS request. The request includes some
encryption details such as the cipher suites supported by the client.
The server (in this case, the AX device, on behalf of the server), checks for
a client-SSL template bound to the VIP. If a client-SSL template is bound to
the VIP, the AX device sends all the digital certificates and certificate chains
contained in the template to the client. Each digital certificate includes a
public key and various other identifying information.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
The client checks its certificate store (sometimes called the certificate list)
for a copy of the server certificate. If the client does not have a copy of the
server certificate, the client will check for a certificate from the Certificate
Authority (CA) that signed the server certificate.
Ultimately, a certificate must be validated by a root CA. Certificates from

root CAs are the most trusted. They do not need to be signed by a higher
(more trusted) CA.
If the CA that signed the certificate is a root CA, the client should have a
copy of the root CA’s certificate. If the CA that signed the server certificate
is not a root CA, the client should have another certificate or a certificate
chain, which is a nested set of certificates, that includes the CA that signed
the CA’s certificate.
If a CA certificate or certificate chain in the client’s certificate store can val-

idate the server certificate, the client accepts the certificate and begins an
encrypted session with the AX device. In a typical deployment, traffic
between the AX device and the client is encrypted, whereas traffic between
the AX device and the real servers is clear (not encrypted).
If the client can not validate the server certificate or the certificate is out of
date, the client’s browser may display a certificate warning. Figure 162
shows an example of a certificate warning displayed by Internet Explorer.
FIGURE 162 Example of Certificate Warning
Note: It is normal for the AX device to display a certificate warning when an

admin accesses the AX management GUI. Certificates used for SLB are
not used by the management GUI.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
CA-Signed and Self-Signed Certificates
Typically, clients have a certificate store that includes certificates signed by

the various root CAs. The certificate store may also have some non-CA cer-
tificates that can be validated by a root CA certificate, either directly or
through a chain of certificates that end with a root certificate.
Each certificate is digitally “signed” to validate its authenticity. Certificates

can be CA-signed or self-signed:
• CA-signed – A CA-signed certificate is a certificate that is created and
signed by a recognized Certificate Authority (CA). To obtain a CA-
signed certificate, an admin creates a key and a Certificate Signing
Request (CSR), and sends the CSR to the CA.The CSR includes the key.
The CA then creates and signs a certificate. The admin installs the cer-
tificate on the AX device. When a client sends an HTTPS request, the
AX device sends a copy of the certificate to the client, to verify the iden-
tity of the server (AX device).
The example in Figure 161 on page 648 uses a CA-signed certificate.
• Self-signed – A self-signed certificate is a certificate that is created and
signed by the AX device. A CA is not used to create or sign the certifi-
cate.
CA-signed certificates are considered to be more secure than self-signed

certificates. Likewise, clients are more likely to be able to validate a CA-
signed certificate than a self-signed certificate. If you configure the AX
device to present a self-signed certificate to clients, the client’s browser may
display a certificate warning. This can be alarming or confusing to end
users. Users can select the option to trust a self-signed certificate, in which
case the warning will not re-appear.
SSL Templates
You can install more than one key-certificate pair on the AX device. The
AX device selects the certificate(s) to send a client or server based on the
SSL template bound to the VIP. You can bind the following types of SSL
templates to VIPs:
• Client-SSL template – Contains keys and certificates for SSL-encrypted
traffic between clients and the AX device.
• Server-SSL template – Contains CA certificates for SSL-encrypted traf-
fic between servers and the AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Client-SSL Template Options
Use client-SSL templates for deployments in which traffic between clients
and the AX device will be SSL-encrypted. Client-SSL templates have the
following options.
For the deployment example in Figure 161 on page 648, only the first
option (Certificate) needs to be configured.
• Certificate – Specifies a server certificate that the AX device will send
to a client, so that the client can validate the server’s identity. The certif-
icate can be generated on the AX device (self-signed) or can be signed
by another entity and imported onto the AX device.
• Key – Specifies a public key for a server certificate. If the CSR used to
request the server certificate is generated on the AX device, the key is
automatically generated. Otherwise, the key must be imported.
• Certificate chain – Specifies a named set of server certificates. You can
add server certificates to the AX device individually, in certificate
chains, or using a combination of individual certificates and certificate
chains. The AX device always sends all individual server certificates
and certificate chains in the template to each client.
• CA certificate – Specifies a CA certificate that the AX device can use to
validate the identity of a client. A CA certificate is needed only if the
AX device will be required to validate the identities of clients. If CA
certificates are required for this purpose, they must be imported onto the
AX device. The AX device is not configured at the factory to contain a
certificate store.
• Certificate Revocation List (CRL) – Specifies a list of client certificates
that have been revoked by the CAs that signed them. This option is
applicable only if the AX device will be required to validate the identi-
ties of clients.
• Connection-request response – Specifies the AX response to connection
requests from clients. This option is applicable only if the AX device
will be required to validate the identities of clients. The response can be
one of the following:
• ignore (default) – The AX device does not request the client to send
its certificate.
• request – The AX device requests the client to send its certificate.
With this action, the SSL handshake proceeds even if either of the
following occurs:
• The client sends a NULL certificate (one with zero length).
• The certificate is invalid, causing client verification to fail.
Use this option if you want to the request to trigger an aFleX policy
for further processing.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
• require – The AX device requires the client certificate. This action
requests the client to send its certificate. However, the SSL hand-
shake does not proceed (it fails) if the client sends a NULL certifi-
cate or the certificate is invalid.
• Cipher list – Specifies the cipher suites supported by the AX device.
When the client sends its connection request, it also sends a list of the
cipher suites it can support. The AX device selects the strongest cipher
suite supported by the client that is also enabled in the template, and
uses that cipher suite for traffic with the client. By default, all the fol-
lowing are enabled:
• SSL3_RSA_DES_192_CBC3_SHA
• SSL3_RSA_DES_40_CBC_SHA
• SSL3_RSA_DES_64_CBC_SHA
• TLS1_RSA_EXPORT1024_RC4_56_MD5
• TLS1_RSA_EXPORT1024_RC4_56_SHA
• Session cache size – Specifies the maximum number of cached sessions for
SSL session ID reuse.
Server-SSL Template Options
A server-SSL template is needed only if traffic between the AX device and

real servers will be encrypted using SSL. In this case, the AX device will be
required to validate the identities of the servers.
• CA certificate – Specifies a CA certificate that the AX device can use to
validate the identity of a server.
• Cipher list – Specifies the cipher suites supported by the AX device.
When the server sends its connection request, it also sends a list of the
cipher suites it can support. The AX device selects the strongest cipher
suite supported by the server that is also enabled in the template and
uses that cipher suite for traffic with the server. The same cipher suites
supported in client-SSL templates are supported in server-SSL tem-
plates. Support for all of them is enabled by default.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Certificate Installation Process

To configure an AX device to perform SSL processing on behalf of real
servers, you must install a certificate on the AX device. This certificate is
the one that the AX device will present to clients during the SSL handshake.
You also must configure a client-SSL template, add the key and certificate
to the template, and bind the template to the VIP that will be requested by
clients.
You can install a CA-signed certificate or a self-signed certificate (described

in “CA-Signed and Self-Signed Certificates” on page 650).
This section gives an overview of the process for each type of certificate.
Detailed procedures are provided later in this chapter.
Requesting and Installing a CA-Signed Certificate
To request and install a CA-signed certificate, use the following process.

For detailed steps, see “Generating a Key and CSR for a CA-Signed Certifi-
cate” on page 655 and “Importing a Certificate and Key” on page 658.
1. Create an encryption key.
2. Create a Certificate Signing Request (CSR).

The CSR will include the public portion of the key, as well as informa-
tion that you enter when you create the CSR.
You can create the key and CSR on the AX device or on a server that is
running openssl or a similar application.
3. Submit the CSR to the CA.

If the CSR was created on the AX device, do one of the following:
• Copy and paste the CSR from the AX CLI or GUI onto the CSR
submission page of the CA server.
• Export the CSR to another device, such as the PC from which you
access the AX CLI or GUI. Email the CSR to the CA, or copy-and-
paste it onto the CSR submission page of the CA server.
If the CSR was created on another device, email the CSR to the CA, or
copy-and-paste it onto the CSR submission page of the CA server.
4. After receiving the signed certificate and the CA’s public key from the
CA, import them onto the AX device.
• If the key and certificate are provided by the CA in separate files
(PKCS #7 format), import the certificate. You do not need to import
the key if the CSR was created on the AX device. In this case, the
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
key is already on the AX device. If the certificate is not in PEM for-
mat, convert it into PEM format.
If the CSR was not created on the AX device, you do need to import
the key also.
• If the key and certificate are provided by the CA in a single file
(PKCS #12 format), convert them into separate files in PEM format,
then import the certificate. If the CSR was not created on the AX
device, you need to import the key also.
See “Converting SSL Certificates to PEM Format” on page 666.
Figure 163 shows the most common way to obtain and install a CA-signed
certificate onto the AX device.
FIGURE 163 Obtaining and Installing Signed Certificate from CA
Note: As an alternative to using a CA, you can use an application such as

openssl to create a certificate, then use that certificate as a CA-signed cer-
tificate to sign another certificate. However, in this case, a client’s
browser is still likely to display a certificate warning to the end user.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Generating a Key and CSR for a CA-Signed Certificate
Installing a Self-Signed Certificate
To install a self-signed certificate instead of a CA-signed certificate:

1. Create an encryption key.
2. Create the certificate.
See “Generating a Self-Signed Certificate” on page 659.

USING THE GUI
1. Select Config > Service > SSL Management, if not already selected.
2. On the menu bar, select Certificate.
3. Click Create.
4. Enter a name for the certificate.
5. In the Issuer drop-down list, select Certificate Authority, if not already

selected.
This option displays the Pass Phrase and Confirm Pass Phrase fields.
6. Enter the rest of the certificate information in the remaining fields of the
Certificate section.
7. Enter a passphrase.
8. From the Key drop-down list, select the length (bits) for the key.
9. Click OK. The AX device generates the certificate key and the certifi-
cate signing request (CSR), and displays the CSR. The CSR is displayed
in the Request Text field.
10. To save the CSR to your PC:

a. Click Download.
Note: If the browser security settings normally block downloads, you may need
to override the setting. For example, in Internet Explorer, hold the Ctrl
key while clicking Download.
b. Click Save.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
c. Navigate to the save location.
d. Click Save again.
Note: If you prefer to copy-and-paste the CSR, make sure to include everything,
including “-----BEGIN CERTIFICATE REQUEST-----” and “-----END
CERTIFICATE REQUEST-----”.
11. When you receive the certificate from the CA, import it onto the AX
device. (See “Importing a Certificate and Key” on page 658.)
USING THE CLI

To generate a key and a CSR, use the following command at the global con-
slb ssl-create csr csr-name url
The csr-name can be 1-31 characters. The url specifies the file transfer pro-
tocol, username (if required), directory path, and filename. 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:
• http://[user@]host/file
• https://[user@]host/file
This command displays a series of prompts, for the following information:

• IP address of the server to which to export the CSR
• Username for write access to the server
• Password for write access to the server
• Path and filename
• Key length, which can be 512, 1024, or 2048 bits
• Common name, 1-64 characters
• Division, 0-31 characters
• Organization, 0-63 characters
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• Locality, 0-31 characters
• State or Province, 0-31 characters
• Country, 2 characters
• Email address, 0-64 characters
• Passphrase to use for the key, 0-31 characters
After the CSR is generated, send the CSR to the CA. After you receive the
signed certificate from the CA, use the import command to import the CA
onto the AX device. The key does not need to be imported. The key is gen-
erated along with the CSR.
The following commands generate and export a CSR, then import the
signed certificate.
AX(config)#slb ssl-create csr slbcsr1 ftp:
Password []?********
File name [/]?slbcsr1
input key bits(512,1024,2048) default 1024:<Enter>
input Common Name, 1~64:slbcsr1
input Division, 0~31:div1
input Organization, 0~63:org2
input Locality, 0~31:westcoast
input State or Province, 0~31:ca
input Country, 2 characters:us
input email address, 0~64:axadmin@example.com
input Pass Phrase, 0~31:csrpword
Confirm Pass Phrase:csrpword
AX(config)#import ca-signedcert1 ftp:
Password []?********
File name [/]?ca-signedcert1
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Importing a Certificate and Key
Importing a Certificate and Key

To import certificate and key files, place them on the PC that is running the
GUI or CLI session, or onto a PC or file server that can be locally reached
over the network.
Note: If you are importing a CA-signed certificate for which you used the AX
device to generate the CSR, you do not need to import the key. The key is
automatically generated on the AX device when you generate the CSR.
USING THE GUI

3. To import the certificate:

a. Click Import.
b. In the Name field, enter a name for the certificate. This is the name
you will refer to when adding the certificate to a client-SSL or
server-SSL template.
c. Select Certificate from the Type drop-down list, if not already
selected.
d. Click Browse and navigate to the location of the certificate.
e. Click Open. The path and filename appear in the Source field.
f. Click OK. The certificate appears in the certificate and key list.
4. To import the key:

a. Click Import.
b. In the Name field, enter a name for the key. This is the name you
will refer to when adding the key to a client-SSL or server-SSL tem-
plate.
c. Select Key from the Type drop-down list.
d. Click Browse and navigate to the location of the key.
e. Click Open. The path and filename appear in the Source field.
f. Click OK. The key appears in the certificate and key list.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Generating a Self-Signed Certificate
USING THE CLI
To import a certificate and its key, use the following command at the global
Config level of the CLI:
[no] slb ssl-load
{certificate cert-name | private-key-string} url
The url specifies the file transfer protocol, username (if required), directory
path, and filename.
entire URL:
Alternatively, you can use the following commands at the Privileged EXEC
or global Config level of the CLI:
import ssl-cert file-name url
import ssl-key file-name url

USING THE GUI
3. Click Create.
4. Enter a name for the certificate.
5. In the Issuer drop-down list, select Self, if not already selected.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
6. Enter the rest of the certificate information in the remaining fields of the
Certificate section.
7. From the Key drop-down list, select the length (bits) for the key.
8. Click OK. The AX device generates the self-signed certificate and its
key. The new certificate and key appear in the certificate list. The certif-
icate is ready to be used in client-SSL and server-SSL templates.
USING THE CLI

To generate a self-signed certificate, use the following command at the glo-
slb ssl-create certificate certificate-name
The certificate-name can be 1-31 characters.
This command enters configuration mode for the certificate. The CLI
prompts you for the following information:
• Key length, which can be 512, 1024, or 2048 bits
• Common name, 1-64 characters
• Division, 0-31 characters
• Organization, 0-63 characters
• Locality, 0-31 characters
• State or Province, 0-31 characters
• Country, 2 characters
• Email address, 0-64 characters
• Number of days the certificate is valid, 30-3650 days
The key length, common name, and number of days the certificate is valid
are required. The other information is optional. The default key length is
1024 bits. The default number of days the certificate is valid is 730.
The following commands create a self-signed certificate named “slbcert1”
and verify the configuration:
AX(config)#slb ssl-create certificate slbcert1
input key bits(512,1024,2048) default 1024:<Enter>
input Common Name, 1~64:slbcert1
input Division, 0~31:Div1
input Organization, 0~63:Org2
input Locality, 0~31:WestCoast
input State or Province, 0~31:CA
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Importing a CRL
input Country, 2 characters:US
input email address, 0~64:axadmin@example.com
input valid days, 30~3650, default 730:<Enter>
AX(config)#show slb ssl cert
name: slbcert1
type: certificate/key
Common Name: slbcert1
Organization: Org2
Expiration: Apr 10 00:34:34 2010 GMT
Issuer: Self
key size: 1024
Importing a CRL
To import a CRL, place it on the PC that is running the GUI or CLI session,
or onto a PC or file server that can be locally reached over the network.
USING THE GUI

2. On the menu bar, select Cert Revocation List.
3. Click Import.
4. Click Browse and navigate to the location of the CRL.
5. Click Open. The path and filename appear in the Source field.
6. Click OK.
USING THE CLI
To import a CRL, use the following command at the global Config level of
the CLI:
[no] slb ssl-load certificate crl-name url
path, and filename.
entire URL:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Exporting Certificates, Keys, and CRLs
Exporting a Certificate and Key
USING THE GUI

3. To export a certificate:
a. Select the certificate. (Click the checkbox next to the certificate
name.)
b. Click Export.
to override the setting. For example, in Internet Explorer, hold the Ctrl
key while clicking Export.
c. Click Save.
d. Navigate to the save location.
e. Click Save again.
4. To export a key:
a. Select the key.
b. Click Export.
c. Click Save.
d. Navigate to the save location.
e. Click Save again.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
USING THE CLI
To export a certificate and its key, use the following commands at the Privi-
leged EXEC or global Config level of the CLI:
export ssl-cert file-name url
export ssl-key file-name url
path, and filename.
entire URL:
Exporting a CRL
USING THE GUI

2. On the menu bar, select Cert Revocation List.
3. Select the CRL. (Click the checkbox next to the CRL name.)
4. Click Export.
to override the setting. For example, in IE, hold the Ctrl key while click-
ing Export.
5. Click Save.
6. Navigate to the save location.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Creating a Client-SSL or Server-SSL Template and Binding it to a VIP
7. Click Save again.
Note: The CLI does not support export of CRLs.
Creating a Client-SSL or Server-SSL Template and

Binding it to a VIP
After creating or importing certificates and keys on the AX device, you
must add them to an SSL template, then bind the template to a VIP, in order
for them to take effect.
Creating an SSL Template
USING THE GUI

2. On the menu bar, select one of the following:

• SSL > Client SSL – to create a template for SSL traffic between the
AX device (VIP) and clients.
• SSL > Server SSL – to create a template for SSL traffic between the
AX device and servers.
3. Click Add.
4. Enter or select the configuration options. (For information, see “SSL

Templates” on page 650, the AX Series GUI Reference, or the online
help.)
USING THE CLI
Use one of the following commands at the global configuration level of the
CLI:
[no] slb template client-ssl template-name
[no] slb template server-ssl template-name
The command creates the template and changes the CLI to the configuration
level for it. Use the commands at the template configuration level to config-
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Converting Certificates and CRLs to PEM Format
ure template parameters. (For information, see “SSL Templates” on
page 650 or the AX Series CLI Reference.)
Binding an SSL Template to a VIP
USING THE GUI

3. Click on the virtual server name or click Add to create a new one.
4. Enter the VIP name and IP address, if creating a new VIP.
5. In the Port section, select a port and click Edit, or click Add to add a new
port. The Virtual Server Port page appears.
6. Select the template from the Client-SSL Template or Server-SSL Tem-

plate drop-down list.
7. Click OK.
8. Click OK again.
USING THE CLI

Use one of the following commands at the configuration level for the virtual
port on the VIP:
[no] template client-ssl template-name
[no] template server-ssl template-name
Use the same command on each port for which SSL will be used.

The AX device supports Privacy Enhanced Mail (PEM) format for certifi-
cate files and CRLs.
If a certificate or CRL you plan to import onto the AX device is not in PEM
format, it must be converted to PEM format first, before you import it onto
the AX device.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Converting SSL Certificates to PEM Format

If you have certificates that are in Windows format, use the procedure in
this section to convert them to PEM format. For example, you can use this
procedure to export SSL certificates that were created under a Windows IIS
environment, for use on servers that are running Apache.
This procedure requires a Windows PC and a Unix/Linux workstation. Per-

form step 1 through step 4 on the Windows PC. Perform step 5 through
step 8 on the Unix/Linux workstation.
Steps to perform on the Windows PC:

1. Start the Microsoft Management Console (mmc.exe).
2. Add the Certificates snap-in:

a. Select File Add/Remove Snap-In. The Add/Remove Snap-In dialog
appears.
b. Click Add. A list of available snap-ins appears.
c. Select Certificates.
d. Click Add.
A dialog appears with the following choices: My user account, Ser-
vice account, and Computer account.
e. Select Computer Account and click Next. The Select Computer dia-
log appears.
f. Select Local Computer and click Finish.
g. Click Close.
h. Click OK. The Certificates snap-in appears in the Console Root list.
3. Expand the Certificate folders and navigate to the certificate you want to
convert.
4. Select Action > All Tasks > Export.

The Export wizard guides you with instructions. Make sure to export the
private key too. The wizard will ask you to enter a passphrase to use to
encrypt the key.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Steps to perform on the Unix/Linux workstation:
5. Copy the PFX-format file that was created by the Export wizard to a
UNIX machine.
6. Use OpenSSL to convert the PFX file into a PKCS12 format:

$ openssl pkcs12 -in filename.pfx -out pfxoutput.txt
This command creates a PKCS12 output file, which contains a concate-
nation of the private key and the certificate.
7. Use the vi editor to divide the PKCS12 file into two files, one for the
certificate (.crt) and the other for the private key.
8. To remove the passphrase from the key, use the following command:
$ openssl rsa -in encrypted.key -out unencrypted.key
Note: Although removing the passphrase is optional, A10 Networks recom-

mends that you remove the passphrase for production environments
where Apache must start unattended.
Converting CRLs from DER to PEM Format

If you plan to use a Certificate Revocation List (CRL), the CRL must be in
PEM format.
To convert Distinguished Encoding Rules (DER) format to PEM format,

use the following command on a Unix/Linux machine where the file is
located:
openssl crl -in filename.der –inform der -outform pem -out file-
name.pem
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Route Tables
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 chapter describes the AX device’s two route tables, for data and man-
agement 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 manage-
ment route table, excluding the management default gateway route.
You can configure the AX device to use the management interface as the
source interface for automated management traffic. In addition, on a case-
by-case basis, you can enable use of the management interface and manage-
ment route table for various types of management connections to remote
devices:
The 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 con-
nections from remote hosts to the AX device.
Note: In AX Release 1.2.4 and earlier, all static routes are stored in the main
route table, even if the next hop is connected to the management interface.
The management route table contains only the route to the subnet directly
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Management Routing Options
connected to the management interface, and the IP default gateway con-
figured on the management interface. When you upgrade to an AX release
later than 1.2.4, static routes whose next hop is the management interface
are duplicated in the management route table.
Keep the Management and Data Interfaces in Separate Networks

It is recommended to keep the management interface and the data interfaces
in separate networks. If both tables have routes to the same destination sub-
net, some operations such as pinging may have unexpected results. An
exception is the default route (0.0.0.0/0), which can be in both tables.
To display the routes in each table, use the following commands:

• show ip route mgmt – This command displays the routes in the man-
agement route table.
• show ip route or show ip fib – These commands display data plane
routes.

You can configure the AX device to use the management interface as the
source interface for the following management protocols, used for auto-
mated management traffic:
• SYSLOG
• SNMPD
• NTP
• RADIUS
• TACACS+
• SMTP
For example, when use of the management interface as the source interface
for control traffic is enabled, all log messages sent to remote log servers are
sent through the management interface. Likewise, the management route
table is used to find a route to the log server. The 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 manage-
ment connections to remote devices:
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
• 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 ear-
lier, 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 man-
agement default gateway.
If this is the case, before you downgrade, remove the TACACS+ con-
figuration 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 auto-
mated management traffic is disabled.
To enable it, use the following command at the configuration level for the
management interface:
[no] ip control-apps-use-mgmt-port
Here is an example:
AX(config-if:management)#ip control-apps-use-mgmt-port
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Using the Management Interface as the Source Interface for

Manually Generated Management Traffic
To use the management interface as the source interface for manually gener-
ated management traffic, use the use-mgmt-port option. This option is sup-
ported with the following commands.
Commands at the User EXEC Level

ssh [use-mgmt-port] {host-name | ipaddr)
login-name [protocol-port]
telnet [use-mgmt-port] {host-name | ipaddr)
[protocol-port]
Commands at the Privileged EXEC Level

export {aflex | ssl-cert | ssl-key | axdebug}
file-name [use-mgmt-port] url
ssh [use-mgmt-port] {host-name | ipaddr)
login-name [protocol-port]
telnet [use-mgmt-port] {host-name | ipaddr)
[protocol-port]
Commands at the Global Configuration Level

backup {config | log} [use-mgmt-port] url
[no] bw-list name [use-mgmt-port] url
[period seconds] [load]
copy {running-config | startup-config |
from-profile-name}
[use-mgmt-port]
{url | to-profile-name [cf]}
health external
{delete program-name |
import [use-mgmt-port] [description] url |
export [use-mgmt-port] program-name url}
[no] restore [use-mgmt-port] url
[no] slb ssl-load
{certificate file-name | private-key file-name}
[use-mgmt-port] url
upgrade {cf | hd} {pri | sec} [use-mgmt-port] url
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Show Commands
show techsupport [[use-mgmt-port] export url]
[page]
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Overview
Auto-Port Translation
This chapter describes auto-port translation and how to configure it, if

required.
Overview
The AX device allows you to use different port numbers for a real server
port and its corresponding virtual server port. The AX auto-port translation
feature can automatically translate the port numbers internally. Figure 164
shows an example.
FIGURE 164 Auto-Port Translation
In this example, VIP 192.168.1.10:80 is bound to real server and port

10.10.10.10:8080. The AX device translates the VIP address into the real
server IP address, and translates the virtual service port number into the real
service port number, to interact with the real server on the client’s behalf.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuring an Auto-Port Translation Range
For standard port numbers (port numbers 0-1023), no additional configura-
tion is required for auto-port translation. For example, if the VIP service
port number is 80 and the real port number is 542, no additional configura-
tion is required.
However, if either or both the real service port number and virtual port num-
ber are non-standard (above 1023), some additional configuration is
required. In this case, you can use either of the following methods to config-
ure support for the translation to a non-standard port number:
• Configure one of the AX device’s auto-port translation ranges to contain
the non-standard port. (This is the more simple option.)
• Configure source Network Address Translation (NAT).
Note: You cannot use auto-port translation as an alternative to source NAT for
connection reuse. Connection reuse requires source NAT. (See See “SLB
Source NAT” on page 484..)

The AX device has a set of configurable auto-translation port ranges. You
can configure the ranges as an alternative to configuring source NAT on a
virtual port.
To resolve potential issues with differing real port numbers for the same ser-
vice in the same service group, edit one of the auto-translation ranges to
include the real or virtual port number that is above 1023. It does not matter
which of the ranges you reconfigure.
Note: If you configure a port range, the ports in the range are reserved and can
not be used by other features (for example, NAT pools). To prevent deple-
tion of available ports, it is recommended to use a narrow port range.
USING THE GUI

2. On the menu bar, select Global > Auto Translation.
3. Click on one of the range names. The Auto Translation tab appears.
Note: If a range has already been configured for use by non-standard port num-
bers, do not reconfigure this range. Instead, select an unconfigured range.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
4. Edit the port numbers in the Start Port and End Port fields, based on the
guidelines described above.
5. Click OK.
No further configuration is needed. You do not need to refer to the auto-

translation range from elsewhere in the SLB configuration.
USING THE CLI
slb auto-translate-port range number

range-start port-num range-end port-num
Specify the protocol port numbers for the range, based on the guidelines
described above.
To verify the change, use the following command:
show slb auto-translate-port-range
No further configuration is needed. You do not need to refer to the auto-

translation range from elsewhere in the SLB configuration.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
OSPF Parameters
Routing Parameters
This chapter lists the parameters you can configure for the following IP
routing protocols:
• Routing Information Protocol (RIP)
• Open Shortest Path First (OSPF)
Note: RIP and OSPF are supported only on AX devices that are deployed in
route mode. If your device is deployed in transparent mode, these param-
eters do not apply.
Note: For more syntax information, see the AX Series CLI Reference.
OSPF Parameters
The tables in this section list the configurable OSPF parameters.
The AX device can run two separate instances of OSPF. When you config-
ure two instances of OSPF on an AX device, the instances run completely
independently, as two logically separate OSPF routers. The AX device does
not internally share information between the OSPF instances. For example,
if redistribution of RIP routes is enabled for only one OSPF instance, the
AX device does not redistribute RIP routes into the other OSPF instance.
Note: For OSPFv2 commands and options, see the “Config Commands: Router
– OSPF” chapter in the AX Series CLI Reference.
Note: The AX device does not support multiple OSPF networks on a data inter-
face. One OSPF network configuration can enable at most one network
per interface.
For example, assume a data port has 3 IP addresses configured that belong
to 3 separate subnets, S1, S2, and S3. If you configure network S4 with
area A.B.C.D, and S4 contains S1, S2, and S3, then only S1 will be run-
ning OSPF. S2 and S3 will not be known to other OSPF routers.
To work around this limitation, enable OSPF redistribution of directly
connected routes so that OSPF will redistribute S2 and S3 via the network
running on S1.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
OSPF Parameters
OSPF Global Parameters

Table 39 lists the global OSPF parameters you can configure on AX
devices.
Note: At least one IP interface must be configured on the AX device, per OSPF
instance, in order to enable OSPF for the first time, and the IP interfaces
must be in separate subnets. When you enable an OSPF instance for the
first time, the AX device will assign a configured IP interface to be the
router ID for that instance. If no IP interfaces are configured, or the only
available interface is already assigned to the other OSPF instance, the
device displays an error message and does not enable the OSPF instance.
After an instance of OSPF is enabled, you can use the router-id command
at the configuration level for the instance to change that instance's router
ID.
TABLE 39 Configurable OSPF Parameters – Global

Status State of the OSPF protocol. One of the following:
[no] router ospf {0 | 1} • Enable
Config > Network > Route > OSPF > Route > Gen- • Disable
eral The 0 | 1 option specifies the instance
Note: Only instance 0 is configurable using the of OSPF to enable and configure.
GUI.
Area OSPF area. IP address
[no] area ...
See the AX Series CLI Reference for syntax details.
Config > Network > Route > OSPF > Route >
Stub Area
Note: Only stub areas are configurable using the
GUI.
Network OSPF network. Network address
[no] network ipaddr {subnet-mask |
/mask-length} area ipaddr
Network
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
OSPF Parameters
TABLE 39 Configurable OSPF Parameters – Global (Continued)

Redistribution Other route types to which OSPF is allowed to Any combination of the following:
redistribute routes. • Static
[no] redistribute • Connected
{static |
• RIP
connected |
rip | • Floating-IP addresses
floating-ip | • IP NAT pools
ip-nat-pool • IP NAT range lists
[ipaddr [subnet-mask | /mask-
• Virtual server IP addresses
length]
[floating-IP-forward-address The default metric-type is 2.
ipaddr] |
ip-nat-range-list |
vip [ipaddr floating-IP-forward-
address ipaddr]}
[metric-type {1 | 2} metric num]
General
Default Metric Numeric cost assigned to an OSPF route. When the 0-16777214
IP route table has more than one route to the same 1 is the lowest cost and 16777214 is
destination, the AX Series selects the route with the the highest cost.
lowest cost.
Default: 20
The metric is added to routes when they are redis-
tributed.
[no] default-metric number
General
Default Informa- Default route into the OSPF domain. 0-16777214
tion Originate [no] default-information originate Default: Disabled. If you enable this
[metric num [always] option, it has the following defaults:
[metric-type {1 | 2}]] • Always – Disabled. The AX device
Note: This option is not configurable using the does not automatically declare itself
GUI. a default gateway for other OSPF
routers, even if the AX device does
not have a default route to 0.0.0.0/0.
• Metric – 10
• Metric type – 2
D e s i g n 681 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
OSPF Parameters
TABLE 39 Configurable OSPF Parameters – Global (Continued)
Router ID Value used by the AX Series to identify itself when A valid IP address.
exchanging route information with other OSPF The address does not need to match an
routers. address configured on the AX device;
The AX Series has only one router ID. The default however, the address must be unique
router ID is the highest-numbered IP address con- within the routing domain.
figured on any of the AX Series Ethernet interfaces. New or changed router IDs require a
[no] router-id ipaddress restart of the OSPF process. To restart
Config > Network > Route > OSPF > Route > the OSPF process, use the following
General CLI command:
clear ip ospf process
Link State LSA status, which controls whether the interface Valid port or VE number.
Advertisements advertises link-state information to OSPF neigh- Default: LSAs are enabled. (No inter-
(LSAs) bors. faces are passive.)
[no] passive-interface {ethernet
port-num | ve vlan-id}
Passive Interface
OSPF Interface Parameters

Table 40 lists the OSPF parameters you can configure on individual IP
interfaces.
An interface can belong to only one OSPF instance. An interface belongs to

an OSPF instance if the interface’s IP address is in the same subnet as an
OSPF network configured for an OSPF instance.
Interface-level OSPF parameters automatically apply to the instance that

includes that interface’s IP address. For example, if OSPF instance 0
includes an area in the subnet that contains Ethernet interface 5’s IP address,
OSPF configuration on Ethernet interface 5 applies to OSPF instance 0, not
OSPF 1.
If an interface’s IP address does not belong to an OSPF instance yet or the

interface does not yet have an IP address, you still can configure interface-
level OSPF parameters on the interface. In this case, they do not take effect
until the interface has an IP address in one of the OSPF instances.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
OSPF Parameters
TABLE 40 Configurable OSPF Parameters – Interface

Cost Numeric cost for using the interface. This cost overrides the 1 to 65535
global default metric (either the system default or the value Default: Value is calculated
specified in the General settings). by the interface bandwidth
[no] ip ospf cost number
Config > Network > Route > OSPF > Interface
Retrans Interval Number of seconds between retransmissions of link-state 3 to 65535 seconds
advertisements (LSAs) to adjacent routers for this interface. Default: 5 seconds
[no] ip ospf retransmit-interval seconds
Hello Interval Number of seconds between transmission of OSPF Hello 1 to 65535 seconds
packets on this interface. Default: 10 seconds
[no] ip ospf hello-interval seconds
Dead Interval Number of seconds that neighbor OSPF routers will wait for a 1 to 65535 seconds
new OSPF Hello packet from the AX Series before declaring Default: 40 seconds
this OSPF router (the AX Series) to be down.
[no] ip ospf dead-interval seconds
Trans Delay Number of seconds it takes to transmit Link State Update 1 to 65535 seconds
packets (route updates) on this interface. This amount is Default: 1 second
added to the ages of LSAs sent in the updates.
With the addition of the transit delay, when a neighbor OSPF
router receives an Update, the ages of the LSAs are more
accurate because the estimated travel time of the update is
accounted for by the transit delay.
[no] ip ospf transmit-delay seconds
Priority Eligibility of this OSPF router to be elected as the designated 0 to 255
router (DR) or backup designated router (BDRs) for the rout- Default: 1
ing domain. The OSPF router with the highest priority is 1 is the lowest priority and
elected as the DR and the router with the second highest pri-
255 is the highest priority.
ority is elected as the BDR.
If you set the priority to 0, the
If more than one router has the highest priority, the router
AX Series does not partici-
with the highest OSPF router ID is selected. pate in DR and BDR elec-
Priority applies only to multi-access networks, not to point- tion.
to-point networks.
[no] ip ospf priority number
D e s i g n 683 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
OSPF Parameters
TABLE 40 Configurable OSPF Parameters – Interface (Continued)
Authentication Type of authentication used to validate OSPF route updates One of the following:
sent or received on this interface. • MD – Message Digest 5
[no] ip ospf authentication (MD5)
[message-digest | null] • Null – Authentication is
Config > Network > Route > OSPF > Interface disabled.
Default: Simple key (unless
you use the MD5 or null
option)
Authentication Password used by the interface to authenticate link-state mes- Any string of characters that
String sages exchanged with neighbor OSPF routers. can be entered from the key-
The same authentication string value must be configured on board, up to 8 characters
the neighbor. Otherwise, the interface refuses (drops) the long.
messages. The string cannot contain
This value applies only to simple authentication, not to MD5 blanks.
or null authentication.
[no] ip ospf authentication-key
key-string
Note: For the message-digest-key key-id md5 key-string
option, the CLI lists the encrypted keyword. This keyword
encrypts display of the string in the startup-config and run-
ning-config. Do not enter this keyword. The AX device auto-
matically applies the keyword. Entering the keyword
manually is not valid.
Key Strings Set of MD passwords used by the interface to authenticate Alphanumeric string up to 16
link-state messages exchanged with neighbor OSPF routers. bytes long.
You can enter up to four key strings. The string cannot contain
Each neighbor must be configured with at least one of the blanks.
strings. Otherwise, the interface refuses (drops) the messages.
This value applies only to MD authentication, not to simple
authentication.
[no] ip ospf message-digest-key key-id
md5 key-string
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
RIP Parameters
RIP Parameters
The tables in this section list the configurable RIP parameters.
RIP Global Parameters

Table 41 lists the global RIP parameters you can configure on AX devices.
TABLE 41 Configurable RIP Parameters – Global

Status State of the RIP protocol. One of the following:
[no] router rip • Enable
Config > Network > Route > RIP > Route > • Disable
General
Redistribute Other route types to which RIP is allowed to redis- Any combination of the following:
tribute routes. • Connect
[no] redistribute • Static
{connected | ospf | static}
• OSPF
Config > Network > Route > RIP > Route >
General
Route advertise- Advertisement status, which controls whether the Valid port or VE number.
ment interface advertises route information to peer RIP Default: Advertisement is enabled. (No
routers. interfaces are passive.)
[no] passive-interface {ethernet
port-num | ve vlan-id}
Passive Interface
Network RIP network. Network address
[no] network ipaddr
{subnet-mask | /mask-length}
Network
Key chain Authentication key chain. • Key name, 1-31 characters
[no] key chain name • Key number, 1-255
(at the global configuration level of the CLI) • Authentication string of the key, 1-
Config > Network > Route > RIP > Route > 16 characters
Key-Chain
D e s i g n 685 of 702
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
RIP Parameters
RIP Interface Parameters

Table 42 lists the RIP parameters you can configure on individual IP inter-
faces.
TABLE 42 Configurable RIP Parameters – Interface

Authentication Type of authentication used to validate RIP route updates One of the following:
sent or received on this interface. • MD – Message Digest 5
[no] ip rip authentication mode md5 (MD5)
Config > Network > Route > RIP > Interface • Simple – Text password
Default: Simple
Authentication Password used by the interface to authenticate route Any string of characters that can
String updates exchanged with other RIP routers. be entered from the keyboard, up
The same authentication string value must be configured to 8 characters long.
on the other routers. Otherwise, the interface refuses The string cannot contain blanks.
(drops) the updates.
This value applies only to simple authentication, not to
MD5 authentication.
[no] ip rip authentication string text
Config > Network > Route > RIP > Interface
Note: For the authentication string text option, the CLI
lists the encrypted keyword. This keyword encrypts dis-
play of the string in the startup-config and running-con-
fig. Do not enter this keyword. The AX device
automatically applies the keyword. Entering the keyword
manually is not valid.
Keychain Name Name of a set of authentication keys. Name of any key chain config-
[no] ip rip authentication key-chain ured on the switch.
chain-name
Poison Reverse Specifies the method used to prevent routing loops. Each One of the following:
AX Series interface can be configured to use one of the • Enabled
following methods:
• Disabled (split horizon is used
• Split horizon instead)
• Poison reverse Default: Disabled
By default, split horizon is enabled and poison reverse is
disabled. If you enable poison reverse, split horizon is
automatically disabled. Likewise, if you disable poison
reverse again, split horizon is automatically re-enabled.
[no] ip rip poisoned-reverse
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 configu-
ration 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” on page 577.
Note: For information about synchronizing configuration information between

AX devices in a High Availability (HA) pair, see “Synchronizing Config-
uration Information” on page 477.
Note: For upgrade instructions, see the release notes for the AX release to which
you plan to upgrade.

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 fol-
lowing file transfer protocols:
• Trivial File Transfer Protocol (TFTP)
• File Transfer Protocol (FTP)
• Secure Copy Protocol (SCP)
• Unix Remote Copy (RCP)
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 policies, and SSL certificates and keys.
• Backup > Config – This option backs up only the specified configu-
ration 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.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Saving Multiple Configuration Files Locally
USING THE CLI
At the Privileged EXCE level of the CLI, use the following command:
backup {config | log} url
The config 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:

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 com-
mands in the startup-config stored in the image area the AX device booted
from with the commands in the running-config.
Note: Management of multiple locally stored configuration files is not sup-

ported in the GUI.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Configuration Profiles
Configuration files are managed as configuration profiles. A configuration
profile is simply a configuration file. You can locally save multiple configu-
ration profiles on the AX device. The configuration management commands
described in this section enable you to do the following:
• Save the startup-config or running-config to a configuration profile.
• Copy locally saved configuration profiles.
• Delete locally saved configuration profiles.
• Compare two configuration profiles side by side to see the differences

between the configurations.
• Link the command option “startup-config” to a configuration profile
other than the one stored in the image area used for the most recent
reboot. (This is the profile that “startup-config” refers to by default.)
This option makes it easier to test a configuration without altering the
configuration stored in the image area.
Note: Although the enable and admin passwords are loaded as part of the sys-
tem configuration, they are not saved in the configuration profiles.
Changes to the enable password or to the admin username or password
take effect globally, regardless of the values that were in effect when a
given configuration profile was saved.
Commands for Local Configuration Management

To manage multiple locally stored configurations, use the following com-
mands. All commands are available at the global configuration level of the
CLI.
write memory
[primary | secondary | profile-name] [cf] |
terminal
This command replaces the configuration commands in the specified con-

figuration profile with the commands in the running-config.
If you enter write memory without additional options, the command

replaces the configuration profile that is currently linked to by startup-con-
fig with the commands in the running-config. If startup-config is set to its
default (linked to the configuration profile stored in the image area that was
used for the last reboot), then write memory replaces the configuration pro-
file in the image area with the running-config.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
If you enter write memory primary, the command replaces the configura-
tion profile stored in the primary image area with the running-config. Like-
wise, if you enter write memory secondary, the command replaces the
configuration profile stored in the secondary image area with the running-
config.
If you enter write memory profile-name, where profile-name is the name of

a configuration profile, the AX device replaces the commands in the speci-
fied 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 termi-

nal.
show startup-config [all | profile-name] [cf]
When entered without the all or profile-name option, this command dis-
plays 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 configura-
tion profiles, use the all option.
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 configura-

tion profile that is currently linked to “startup-config” and saves the copy
under the specified profile name.
The copy running-config to-profile-name command copies the running-

config and saves the copy under the specified profile name.
The 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 sup-
ported.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
(The url option backs up the configuration to a remote device. See “Backing
Up System Information” on page 687.)
diff {startup-config | profile-name}

{running-config | profile-name}
Displays a side-by-side comparison of the commands in a pair of configura-

tions.
The diff startup-config running-config command compares the configura-

tion profile that is currently linked to "startup-config" with the running-con-
fig. Similarly, the diff startup-config profile-name command compares the
configuration profile that is currently linked to "startup-config" with the
specified configuration profile.
To compare a configuration profile other than the startup-config to the run-

ning-config, enter the configuration profile name instead of startup-config.
To compare any two configuration profiles, enter their profile names instead
of startup-config or running-config.
In the CLI output, the commands in the first profile name you specify are
listed on the left side of the terminal screen. The commands in the other pro-
file that differ from the commands in the first profile are listed on the right
side of the screen, across from the commands they differ from. The follow-
ing flags indicate how the two profiles differ:
• – This command has different settings in the two profiles.
• – This command is in the second profile but not in the first one.
• – This command is in the first profile but not in the second one.
link startup-config {default | profile-name}

[primary | secondary] [cf]
This command links the "startup-config" token to the specified configura-

tion profile. By default, "startup-config" is linked to "default", which means
the configuration profile stored in the image area from which the AX device
most recently rebooted.
This command enables you to easily test new configurations without replac-
ing the configuration stored in the image area.
The primary | secondary option specifies the image area. If you omit this
option, the image area last used to boot is selected.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
The cf option links the profile to the specified image area in compact flash
instead of the hard disk.
The profile you link to must be stored on the boot device you select. For
example, if you use the default boot device selection (hard disk), the profile
you link to must be stored on the hard disk. If you specify cf, the profile
must be stored on the compact flash. (To display the profiles stored on the
boot devices, use the show startup-config all and show startup-config all
cf commands.)
After you link "startup-config" to a different configuration profile, configu-

ration management commands that affect "startup-config" affect the linked
profile instead of affecting the configuration stored in the image area. For
example, if you enter the write memory command without specifying a
profile name, the command saves the running-config to the linked profile
instead of saving it to the configuration stored in the image area.
Likewise, the next time the 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]
This command deletes the specified configuration profile. The cf option

deletes the profile from compact flash instead of the hard disk.
Note: Although the command uses the startup-config option, the command
only deletes the configuration profile linked to “startup-config” if you
enter that profile’s name. The command deletes only the profile you spec-
ify.
Note: If the configuration profile you specify is linked to “startup-config”, “star-

tup-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 pro-
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
file 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
The following command compares the configuration profile currently

linked to “startup-config” with configuration profile “testcfg1”. This exam-
ple is abbreviated for clarity. The differences between the profiles are
shown in this example in bold type.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
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 | ip address
10.10.20.1 255.255.255.0
ipv6 address 2001:144:121:3::5/64 | ipv6 address
fc00:300::5/64
! (
! (
> ip nat range-
list v6-1 fc00:300::300/64 2001:144:121:1::900/6
! (
ipv6 nat pool p1 2001:144:121:3::996 2001:144:121:3::999 netm <
! <
slb server ss100 2001:144:121:1::100 <
port 22 tcp <
--MORE--
The following command links configuration profile “slbconfig3” with “star-

tup-config”:
AX(config)#link startup-config slbconfig3
The following command deletes configuration profile “slbconfig2”:

AX(config)#delete startup-config slbconfig2
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Scan-All-Members Option in Persistence

Templates
In cookie, source-IP, and destination-IP persistence templates, the match-

type server option has a suboption named scan-all-members. This chapter
describes the option in detail.
The match-type server option changes the granularity of persistence, from

server+port, to simply server. If the match-type is set to server+port (the
default), a persistent session is always sent to the same real port on the same
real server. However, if the match-type is set to server, a persistent session
is always sent to the same real server, but not necessarily to the same real
port.
The match-type server option is useful in cases where the same service is
available on multiple service ports on the server. With this option, if the
server port that a client is using for a persistent session goes down, another
service port of the same service type on the same server can be used.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
FIGURE 165 Scan-all-members
VIP 192.168.10.11 uses 3 real servers for HTTP service. Two of the servers
have a single protocol port for HTTP. However, one of the servers has
HTTP service on multiple service ports.
The load-balancing method for the service group is used to select a server
and port for the first request from a given client (source IP address). After
this initial selection, subsequent requests from the same client are sent to the
same server.
By default, when the match-type is changed to server, the AX device uses

the SLB load-balancing method for the first request to select a member, then
uses fast-path processing to select the first member that has the same IP
address as the server that was initially selected.
In this example, if the load-balancing method chooses port 80 on server s3

for the first request, subsequent requests are also sent to s3. If port 80 goes
down, the next request is still sent to s3, but to a different port on s3.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
However, if the member (port 80 on s3) is set to a lower priority or is

administratively disabled, the AX device will use the load-balancing
method to select a server and port for the next request. Any of the enabled
members can be selected.
In this case, it is possible that a different server will be selected for the next
request. For example, if an admin needs to perform some maintenance on
port 80, and disables the port in order to prevent it from being used for fur-
ther requests, persistent sessions on the port and server may not remain per-
sistent to the same server.
To ensure that sessions do remain persistent on the same server if a member

is administratively disabled or is set to a lower priority, use the scan-all-
members option. In this case, the AX device selects the first member that
has the same IP address as the member that has been taken out of service.
CLI Example
The commands in this section configure the source-IP persistence template
and the service group in Figure 165 on page 698.
The following commands configure the source-IP persistence template:

AX(config)#slb template persist source-ip persist-source
AX(config-source ip persistence template)#match-type server scan-all-members
AX(config-source ip persistence template)#exit

AX(config)#slb service-group sg-1
AX(config-slb service group)#template persist source-ip persist-source
If s3:80 is disabled or is set to a lower priority, the AX device selects the

next member on the same server, s3:8080.
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
Document No.: D-030-01-00-0006 - Ver. 2.0.2 11/11/2009
702
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
Asia Headquarters
A10 Networks, Inc.

No. 8, Dong Bei Wang Xi Lu
ZhongGuanCun Software Park
#2 Building A, 2305
Hai Dian District, Beijing 100094
People's Republic of China
+86-10-8282-5137
702

AX Config Guide v2 0 2-20091111

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

AX Config Guide v2 0 2-20091111

Enviado por

Direitos autorais:

Formatos disponíveis

P e r f o r m a n c e b y D e s i g n

AX Series™ Advanced Traffic Manager

A10 Networks, Inc.

Tel: +1-408-325-8668 (main)

Tel: +1-408-325-8668 (main)

Information in this document is subject to change without notice.

No warranty is expressed or implied; including and not limited to warranties of non-

About This Document

This document describes the features of the A10 Networks AX Series™

Additional information is available for AX Series systems in the following

• AX Series GUI Reference

• AX Series CLI Reference

• AX Series aFleX Reference

• AX Series MIB Reference

• AX Series aXAPI Reference

System Description – The AX Series

The AX Series is the industry’s best performing application acceleration

Representations of Layer 2 and Layer 3 Devices

HTTP Load Balancing 89

HTTP Options for SLB 105

FTP Load Balancing 141

SIP Load Balancing 163

SSL Offload and SSL Proxy 177

STARTTLS for Secure SMTP 195

Streaming-Media Load Balancing 207

Layer 4 TCP/UDP Load Balancing 213

IP Protocol Load Balancing 221

Wildcard VIPs 229

Outbound Link Load Balancing 235

Transparent Cache Switching 241

Firewall Load Balancing 255

Server and Port Templates 281

Health Monitoring 297

Global Server Load Balancing 335

RAM Caching 411

High Availability 423

Network Address Translation 483

Management Security Features 507

Role-Based Administration 577

SLB Parameters 599

Auto-Port Translation 675

Routing Parameters 679

Configuration Management 687

Scan-All-Members Option in Persistence Templates 697

• High Availability (Layer 4 Active-Active and Active-Standby) to pro-

• Removable fan tray

• Dual Core/Dual Processors

• Optimized embedded Linux for Control Thread

• Optimized embedded A10 Packet Processing Data Thread

• Operates in either Transparent mode or Gateway mode

• L4 packet classification assist technology

• Static routes, Dynamic Routing protocols RIP and OSPF

• A10 Networks Proprietary offloading technology provides – buffer

• Server Load Balancing (SLB)

• Global Server Load Balancing (GSLB)

• Link Load Balancing (LLB)

• Firewall Load Balancing (FWLB)

• RAM caching, in which the AX device functions as a web cache server

• Configuration templates for easy configuration of large deployments

• Sophisticated health checking

• High performance IP Network Address Translation (IP NAT)

• Streaming-media server load balancing