AX SLB ADC Config Guide v2 7-0-20121101

Application Delivery and Server Load Balancing
Guide
AX Series Advanced Traffic Manager

Document No.: D-030-01-00-0026
Ver. 2.7.0 11/1/2012
©
A10 Networks, Inc. 11/1/2012 - All Rights Reserved
Information in this document is subject to change without notice.
Trademarks
A10 Networks, the A10 logo, aACI, aCloud, ACOS, aDCS, aDNS, aELB, aFleX, aFlow, aGalaxy, aPlatform, aUSG, aVCS,
aWAF, aXAPI, IDAccess, IDSENTRIE, IP to ID, SmartFlow, SoftAX, Unified Service Gateway, Virtual Chassis, Virtual-
ADC, and VirtualN are trademarks or registered trademarks of A10 Networks, Inc. All other trademarks are property of
their respective owners.
Patents Protection
A10 Networks products including all AX Series products are protected by one or more of the following US patents and pat-
ents pending: 8291487, 8266235, 8151322, 8079077, 7979585, 7716378, 7675854, 7647635, 7552126, 20120216266,
20120204236, 20120179770, 20120144015, 20120084419, 20110239289, 20110093522, 20100235880, 20100217819,
20090049537, 20080229418, 20080148357, 20080109887, 20080040789, 20070283429, 20070282855, 20070271598,
20070195792, 20070180101
Confidentiality
This document contains confidential materials proprietary to A10 Networks, Inc. This document and information and ideas
herein may not be disclosed, copied, reproduced or distributed to anyone outside A10 Networks, Inc. without prior written
consent of A10 Networks, Inc. This information may contain forward looking statements and therefore is subject to change.
A10 Networks Inc. Software License and End User Agreement

Software for all AX Series products contains trade secrets of A10 Networks and its subsidiaries and Customer agrees to
treat Software as confidential information.
Anyone who uses the Software does so only in compliance with the terms of this Agreement. Customer shall not:
1) reverse engineer, reverse compile, reverse de-assemble or otherwise translate the Software by any means
2) sublicense, rent or lease the Software.
Disclaimer
The information presented in this document describes the specific products noted and does not imply nor grant a guarantee
of any technical performance nor does it provide cause for any eventual claims resulting from the use or misuse of the prod-
ucts described herein or errors and/or omissions. A10 Networks, Inc. reserves the right to make technical and other changes
to their products and documents at any time and without prior notification.
No warranty is expressed or implied; including and not limited to warranties of non-infringement, regarding programs, cir-
cuitry, descriptions and illustrations herein.
Environmental Considerations
Some electronic components may possibly contain dangerous substances. For information on specific component types,
please contact the manufacturer of that component. Always consult local authorities for regulations regarding proper dis-
posal of electronic components in your area.
Further Information
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10
Networks location, which can be found by visiting www.a10networks.com.
AX Series - Application Delivery and Server Load Balancing Guide
End User License Agreement
IMPORTANT: PLEASE READ THIS END USER LICENSE AGREEMENT CARE-

FULLY. DOWNLOADING, INSTALLING OR USING A10 NETWORKS OR A10
NETWORKS PRODUCTS, OR SUPPLIED SOFTWARE CONSTITUTES ACCEP-
TANCE OF THIS AGREEMENT.
A10 NETWORKS IS WILLING TO LICENSE THE PRODUCT (AX Series) TO YOU

ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CON-
TAINED IN THIS LICENSE AGREEMENT. BY DOWNLOADING OR INSTALLING
THE SOFTWARE, OR USING THE EQUIPMENT THAT CONTAINS THIS SOFT-
WARE, YOU ARE BINDING YOURSELF AND THE BUSINESS ENTITY THAT YOU
REPRESENT (COLLECTIVELY, "CUSTOMER") TO THIS AGREEMENT. IF YOU
DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, THEN A10
NETWORKS IS UNWILLING TO LICENSE THE SOFTWARE TO YOU AND DO
NOT DOWNLOAD, INSTALL OR USE THE PRODUCT.
The following terms of this End User License Agreement ("Agreement") govern Cus-
tomer's access and use of the Software, except to the extent there is a separate
signed agreement between Customer and A10 Networks governing Customer's use
of the Software
License. Conditioned upon compliance with the terms and conditions of this Agree-
ment, A10 Networks Inc. or its subsidiary licensing the Software instead of A10 Net-
works Inc. ("A10 Networks"), grants to Customer a nonexclusive and
nontransferable license to use for Customer's business purposes the Software and
the Documentation for which Customer has paid all required fees. "Documentation"
means written information (whether contained in user or technical manuals, training
materials, specifications or otherwise) specifically pertaining to the product or prod-
ucts and made available by A10 Networks in any manner (including on CD-Rom, or
on-line).
Unless otherwise expressly provided in the Documentation, Customer shall use the
Software solely as embedded in or for execution on A10 Networks equipment owned
or leased by Customer and used for Customer's business purposes.
General Limitations. This is a license, not a transfer of title, to the Software and
Documentation, and A10 Networks retains ownership of all copies of the Software
and Documentation. Customer acknowledges that the Software and Documentation
contain trade secrets of A10 Networks, its suppliers or licensors, including but not
limited to the specific internal design and structure of individual programs and asso-
ciated interface information. Accordingly, except as otherwise expressly provided
under this Agreement, Customer shall have no right, and Customer specifically
agrees not to:
a. transfer, assign or sublicense its license rights to any other person or entity,
or use the Software on unauthorized or secondhand A10 Networks equip-
ment
b. make error corrections to or otherwise modify or adapt the Software or cre-
ate derivative works based upon the Software, or permit third parties to do
the same
Performance by Design 3 of 828

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
c. reverse engineer or decompile, decrypt, disassemble or otherwise reduce
the Software to human readable form, except to the extent otherwise
expressly permitted under applicable law notwithstanding this restriction
d. disclose, provide, or otherwise make available trade secrets contained
within the Software and Documentation in any form to any third party with-
out the prior written consent of A10 Networks. Customer shall implement
reasonable security measures to protect such trade secrets.
Software, Upgrades and Additional Products or Copies. For purposes of this

Agreement, "Software" and “Products” shall include (and the terms and conditions of
this Agreement shall apply to) computer programs, including firmware and hard-
ware, as provided to Customer by A10 Networks or an authorized A10 Networks
reseller, and any upgrades, updates, bug fixes or modified versions thereto (collec-
tively, "Upgrades") or backup copies of the Software licensed or provided to Cus-
tomer by A10 Networks or an authorized A10 Networks reseller.
OTHER PROVISIONS OF THIS AGREEMENT:

a. CUSTOMER HAS NO LICENSE OR RIGHT TO USE ANY ADDITIONAL
COPIES OR UPGRADES UNLESS CUSTOMER, AT THE TIME OF
ACQUIRING SUCH COPY OR UPGRADE, ALREADY HOLDS A VALID
LICENSE TO THE ORIGINAL SOFTWARE AND HAS PAID THE APPLI-
CABLE FEE FOR THE UPGRADE OR ADDITIONAL COPIES
b. USE OF UPGRADES IS LIMITED TO A10 NETWORKS EQUIPMENT FOR
WHICH CUSTOMER IS THE ORIGINAL END USER PURCHASER OR
LEASEE OR WHO OTHERWISE HOLDS A VALID LICENSE TO USE THE
SOFTWARE WHICH IS BEING UPGRADED
c. THE MAKING AND USE OF ADDITIONAL COPIES IS LIMITED TO NEC-
ESSARY BACKUP PURPOSES ONLY.
Term and Termination. This Agreement and the license granted herein shall remain
effective until terminated. All confidentiality obligations of Customer and all limita-
tions of liability and disclaimers and restrictions of warranty shall survive termination
of this Agreement.
Export. Software and Documentation, including technical data, may be subject to

U.S. export control laws, including the U.S. Export Administration Act and its associ-
ated regulations, and may be subject to export or import regulations in other coun-
tries. Customer agrees to comply strictly with all such regulations and acknowledges
that it has the responsibility to obtain licenses to export, re-export, or import Soft-
ware and Documentation.
Trademarks
A10 Networks, the A10 logo, aACI, aCloud, ACOS, aDCS, aDNS, aELB, aFleX, aFlow, aGalaxy,
aPlatform, aUSG, aVCS, aWAF, aXAPI, IDAccess, IDSENTRIE, IP to ID, SmartFlow, SoftAX,
Unified Service Gateway, Virtual Chassis, VirtualADC, and VirtualN are trademarks or registered
trademarks of A10 Networks, Inc. All other trademarks are property of their respective owners.
Patents Protection
A10 Networks products including all AX Series products are protected by one or more of the fol-
lowing US patents and patents pending: 8291487, 8266235, 8151322, 8079077, 7979585,
7716378, 7675854, 7647635, 7552126, 20120216266, 20120204236, 20120179770,
20120144015, 20120084419, 20110239289, 20110093522, 20100235880, 20100217819,
20090049537, 20080229418, 20080148357, 20080109887, 20080040789, 20070283429,
20070282855, 20070271598, 20070195792, 20070180101
4 of 828 Performance by Design

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Limited Warranty
Disclaimer of Liabilities. REGARDLESS OF ANY REMEDY SET FORTH FAILS

OF ITS ESSENTIAL PURPOSE OR OTHERWISE, IN NO EVENT WILL A10 NET-
WORKS OR ITS SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, PROFIT,
OR LOST OR DAMAGED DATA, BUSINESS INTERRUPTION, LOSS OF CAPITAL,
OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE
DAMAGES HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIA-
BILITY OR WHETHER ARISING OUT OF THE USE OF OR INABILITY TO USE
PRODUCT OR OTHERWISE AND EVEN IF A10 NETWORKS OR ITS SUPPLIERS
OR LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAM-
AGES.
In no event shall A10 Networks’ or its suppliers' or licensors' liability to Customer,

whether in contract, (including negligence), breach of warranty, or otherwise, exceed
the price paid by Customer for the Software that gave rise to the claim or if the Soft-
ware is part of another Product, the price paid for such other Product.
Customer agrees that the limitations of liability and disclaimers set forth herein will
apply regardless of whetherCustomer has accepted the Software or any other prod-
uct or service delivered by A10 Networks. Customer acknowledges and agrees that
A10 Networks has set its prices and entered into this Agreement in reliance upon the
disclaimers of warranty and the limitations of liability set forth herein, that the same
reflect an allocation of risk between the parties (including the risk that a contract
remedy may fail of its essential purpose and cause consequential loss), and that the
same form an essential basis of the bargain between the parties.
The Warranty and the End User License shall be governed by and construed in
accordance with the laws of the State of California, without reference to or applica-
tion of choice of law rules or principles. If any portion hereof is found to be void or
unenforceable, the remaining provisions of the Agreement shall remain in full force
and effect. This Agreement constitutes the entire and sole agreement between the
parties with respect to the license of the use of A10 Networks Products unless other-
wise supersedes by a written signed agreement.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid A10
Networks Regular and Technical Support service contracts, the A10 Net-
works Technical Assistance Center provides support services online and
over the phone.
Corporate Headquarters
A10 Networks, Inc.

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

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

The AX device provides a simple method to collect configuration and status
information for Technical Support to use when diagnosing system issues.
To collect system information, use either of the following methods.
USING THE GUI (RECOMMENDED)

1. Log into the GUI.
2. On the main page (Monitor Mode > Overview > Summary), click
. This option downloads a text log file.
3. Email the file as an attachment to support@A10Networks.com.
USING THE CLI

1. Log into the CLI.
2. Enable logging in your terminal emulation application, to capture out-
put generated by the CLI.
3. Enter the enable command to access the Privileged EXEC mode of the
CLI. Enter your enable password at the Password prompt.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
4. Enter the show techsupport command.
5. After the command output finishes, save the output in a text file.
Note: As an alternative to saving the output in a log file captured by your termi-
nal emulation application, you can export the output from the CLI using
the following command:
show techsupport export [use-mgmt-port] url
(For syntax information, see the AX Series CLI Reference.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
About This Document
About This Document
This document describes features of the A10 Networks AX Series™

Advanced Traffic Manager / Application Delivery Controller.
FIGURE 1 AX 5630 (front panel view)
Information is available for AX Series products in the following documents.

These documents are included on the documentation CD shipped with your
AX Series product, and also are available on the A10 Networks support site:
• AX Series Installation Guides
• AX Series LOM Reference
• AX Series System Configuration and Administration Guide
• AX Series Application Delivery and Server Load Balancing Guide
• AX Series Global Server Load Balancing Guide
• AX Series GUI Reference
• AX Series CLI Reference
• AX Series aFleX Reference
• AX Series MIB Reference
• AX Series aXAPI Reference
Make sure to use the basic deployment instructions in the AX Series Instal-
lation Guide for your AX model, and in the AX Series System Configuration
and Administration Guide. Also make sure to set up your device’s Lights
Out Management (LOM) interface, if applicable.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
About This Document
Note: Some guides include GUI configuration examples. In these examples,
some GUI pages may have new options that are not shown in the example
screen images. In these cases, the new options are not applicable to the
examples. For information about any option in the GUI, see the AX Series
GUI Reference or the GUI online help.
Audience
This document is intended for use by network architects for determining
applicability and planning implementation, and for system administrators
for provision and maintenance of A10 Networks AX Series products.
Documentation Updates
Updates to these documents are published periodically to the A10 Networks
support site, on an updated documentation CD (posted as a zip archive). To
access the latest version, please log onto your A10 support account and nav-
igate to the following page: Support > AX Series > Technical Library.
http://www.a10networks.com
A10 Virtual Application Delivery Community

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
End User License Agreement 3
Obtaining Technical Assistance 7

Collecting System Information.............................................................................................................. 7
About This Document 9

Audience................................................................................................................................................ 10
Documentation Updates ...................................................................................................................... 10
A10 Virtual Application Delivery Community..................................................................................... 10
One-Arm Deployment in Route Mode 25

Overview................................................................................................................................................ 25
Configuration Example ........................................................................................................................ 28
Layer 3 Direct Server Return 43

L3 DSR Packet Flow ............................................................................................................................. 44
Health Monitoring for L3 DSR.............................................................................................................. 46
Configuring Layer 3 DSR ..................................................................................................................... 48
Obtaining Technical Assistance.......................................................................................................... 61
Collecting System Information............................................................................................................ 61
More SLB Deployment Examples 63

Route Mode ........................................................................................................................................... 64
Configuration Example ................................................................................................................... 65
Direct Server Return in Transparent Mode......................................................................................... 69
Direct Server Return in Route Mode ................................................................................................... 74
Direct Server Return in Mixed Layer 2/Layer 3 Environment ........................................................... 77
Transparent Mode................................................................................................................................. 82
Transparent Mode in Multinetted Environment ................................................................................. 89

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
Wildcard VIPs 95
Configuring a Wildcard VIP ..................................................................................................................95
Wildcard VIP Examples.........................................................................................................................97
IPv4 Load Balancing 99

Overview ................................................................................................................................................99
Configuring IP Protocol Load Balancing ..........................................................................................102
IPv6 Load Balancing 107

Configuration Examples .....................................................................................................................107
Example 1: ................................................................................................................................... 107
Example 2: ................................................................................................................................... 108
Example 3: ................................................................................................................................... 108
Example 4: ................................................................................................................................... 109
Layer 4 TCP/UDP Load Balancing 111

Overview .............................................................................................................................................. 111
Configuring Layer 4 Load Balancing.................................................................................................114
Stateless SLB 123

Stateless Load-Balancing Methods...................................................................................................123
Stateless Hash-based SLB 127
Auto-switch to Stateless SLB Based on Traffic 129
FTP Load Balancing 133

Overview ..............................................................................................................................................133
Configuring FTP Load Balancing ......................................................................................................135
Streaming-Media Load Balancing 153

Overview ..............................................................................................................................................153
Configuring Streaming-Media SLB....................................................................................................155
HTTP Load Balancing 159

Overview ..............................................................................................................................................159
Configuring HTTP Load Balancing....................................................................................................164

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
HTTP Options for SLB 175
Overview.............................................................................................................................................. 175
Summary of HTTP Options ........................................................................................................... 175
HTTP Template Configuration ...................................................................................................... 177
URL Hash Switching........................................................................................................................... 178
Offset ............................................................................................................................................ 180
URL Hash Switching with Server Load Awareness ...................................................................... 181
Configuring URL Hashing ............................................................................................................. 183
URL / Host Switching ......................................................................................................................... 184
Configuring URL / Host Switching ................................................................................................ 187
Using URL / Host Switching along with Cookie Persistence ........................................................ 189
Using URL / Host Switching along with Source IP Persistence .................................................... 192
URL Failover........................................................................................................................................ 193
Configuring URL Failover ............................................................................................................. 194
5xx Retry and Reassignment............................................................................................................. 194
Non-HTTP Bypass .............................................................................................................................. 196
High-speed HTTP Content Replacement.......................................................................................... 198
Content Compression ........................................................................................................................ 199
Hardware-Based Compression ..................................................................................................... 201
How the AX Device Determines Whether to Compress a File ...................................................... 202
Configuring Content Compression ................................................................................................ 203
Client IP Insertion / Replacement...................................................................................................... 206
Configuring Client IP Insertion / Replacement .............................................................................. 208
Header Insertion / Erasure ................................................................................................................. 209
Configuring Header Insertion / Replacement ................................................................................ 210
Configuring Header Erasure ......................................................................................................... 213
URL Redirect Rewrite......................................................................................................................... 214
Configuring URL Redirect Rewrite ................................................................................................ 215
Strict Transaction Switching ............................................................................................................. 216
Enabling Strict Transaction Switching .......................................................................................... 217
Web Logging for HTTP and RAM Caching 219

Log Message Format.......................................................................................................................... 219
Configuration ...................................................................................................................................... 219

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
SIP Load Balancing 225

Load Balancing for SIP over UDP......................................................................................................225
Configuring Load Balancing for SIP over UDP ............................................................................. 226
Load Balancing for SIP over TCP/TLS ..............................................................................................239
SIP Multiplexing ............................................................................................................................ 239
Client Keepalive and Server Keepalive ........................................................................................ 242
AX Actions if Selection of a Client or SIP Server Fails ................................................................. 243
SLB Network Address Translation for SIP over TCP / TLS .......................................................... 243
Configuring SIP over TCP / TLS for SIP Multiplexing .................................................................. 244
CLI Example ............................................................................................................................. 255
Displaying SIP SLB Statistics .................................................................................................... 257
Disabling Reverse NAT Based on Destination IP Address..............................................................258
IP NAT for SIP ......................................................................................................................................260
Generic TCP-Proxy 261
Diameter AAA Load Balancing 263

Overview ..............................................................................................................................................263
Diameter Parameters ..........................................................................................................................266
Diameter Attribute-Value Pairs ..................................................................................................... 266
Load Balancing for Specific Message Codes ............................................................................... 267
Timers .......................................................................................................................................... 268
Accounting-Request Message Duplication ................................................................................... 268
Configuration.......................................................................................................................................269
SSL Offload and SSL Proxy 279

Overview ..............................................................................................................................................279
Choosing an SSL Optimization Implementation ........................................................................... 279
Configuring Client SSL .......................................................................................................................280
Configuring HTTPS Offload................................................................................................................284
Configuring the SSL Proxy Feature...................................................................................................291
STARTTLS for Secure SMTP 299

Overview ..............................................................................................................................................299
Configuring STARTTLS ......................................................................................................................301

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
SNMP-based Load Balancing 309
Overview.............................................................................................................................................. 309
Configuration ...................................................................................................................................... 312
SSL Intercept 315

Overview.............................................................................................................................................. 315
SSL Operation .............................................................................................................................. 317
SSL Operation on Inside AX Device ......................................................................................... 318
SSL Operation on Outside AX Device ....................................................................................... 320
Packet Flow for SSL Intercept ................................................................................................... 320
Configuration ...................................................................................................................................... 322
Virtual Ethernet Interfaces ......................................................................................................... 322
Wildcard VIPs ............................................................................................................................... 323
Traffic Flow Through Wildcard VIPs .......................................................................................... 323
Service Groups .......................................................................................................................... 327
Configuration Tasks ...................................................................................................................... 328
GUI Configuration............................................................................................................................... 329
CLI Configuration ............................................................................................................................... 329
Configuring the Inside AX Devices ............................................................................................... 329
Enable Promiscuous VIP Mode on Ethernet Interfaces ............................................................ 329
Import the Root CA-signed Certificate for the Content Servers ................................................ 330
Configure the Client-SSL Template ........................................................................................... 331
Configure the Paths Through the Traffic Inspection Devices .................................................... 331
Configure the Wildcard VIPs ..................................................................................................... 332
Configuring the Outside AX Devices ............................................................................................ 334
Enable Promiscuous VIP Mode on Ethernet Interfaces ............................................................ 334
Configure the Paths Through the Traffic Inspection Devices .................................................... 334
Configure the Service Groups for the Gateway Router ............................................................. 335
Configure the Server-SSL Template ......................................................................................... 335
Configure the Wildcard VIPs ..................................................................................................... 335
Displaying Certificate Hash Entries .............................................................................................. 336
Configuration Example ...................................................................................................................... 337
CLI Example—Inside AX Devices ................................................................................................ 338
Inside Primary AX Device .......................................................................................................... 338
Inside Secondary AX Device ..................................................................................................... 342
Outside Primary AX Device ....................................................................................................... 346
Outside Secondary AX Device .................................................................................................. 349

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
ALG Protocol FWLB Support for FTP and SIP 353

Overview of FTP and SIP ....................................................................................................................353
Topologies for ALG Protocols FTP and SIP......................................................................................356
Persistent Sessions for ALG Protocol FWLB ............................................................................... 358
FTP Persistent Sessions ........................................................................................................... 358
SIP Persistent Sessions ............................................................................................................ 360
Configuration Parameters for ALG Protocol FWLB ...................................................................... 361
Wildcard VIP ............................................................................................................................. 361
Session Persistence for FTP and SIP ....................................................................................... 364
Health Monitoring for FWLB Paths ............................................................................................ 366
Configuration.......................................................................................................................................367
Internal-facing Device ............................................................................................................... 384
External-facing Device .............................................................................................................. 390
Transparent Cache Switching 395

Overview ..............................................................................................................................................395
Configuring Layer 4 TCS ....................................................................................................................398
Configuring Layer 7 TCS ....................................................................................................................401
Service Type HTTP Without URL Switching Rules ...................................................................... 404
Service Type HTTP with URL Switching Rules ............................................................................ 405
Optimizing TCS with Multiple Cache Servers ............................................................................... 407
Enabling Support for Cache Spoofing .......................................................................................... 408
Configuring IPv4 TCS in High Availability Layer 3 Inline Mode ......................................................410
AX-1 Configuration ....................................................................................................................... 413
Configuring IPv6 TCS in High Availability Layer 3 Inline Mode ......................................................417
Configuring TCS for FTP ....................................................................................................................423
Configuration ................................................................................................................................ 424
Destination-based Hashing with Wildcard VIPs 427
SLB Protocol Translation 431

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
DNS Optimization and Security 439
DNS Security....................................................................................................................................... 439
Sanity Check Details ..................................................................................................................... 440
Sanity Checking for Virtual-Port Type UDP ............................................................................... 440
Sanity Checking for Virtual-Port Type DNS-UDP ...................................................................... 440
Configuring DNS Security ............................................................................................................. 441
Configuration Example – DNS Security ........................................................................................ 442
Global DNS Optimization ................................................................................................................... 442
DNS Optimization per VIP .................................................................................................................. 444
Class-List Parameters for DNS Caching ...................................................................................... 444
DNS Template Parameters ........................................................................................................... 445
DNS Caching LID / GLID Policy Parameters ............................................................................ 446
DNS Cache Logging ..................................................................................................................... 447
Configuration ................................................................................................................................ 448
Configure a Class List ............................................................................................................... 448
Configure the GLIDs .................................................................................................................. 452
Configure a DNS Template ....................................................................................................... 453
Enable DNS Caching on a VIP .................................................................................................. 456
Display DNS Caching Information ............................................................................................. 457
Configuration Examples – DNS Optimization ............................................................................... 458
Control Caching on Per-VIP Basis ............................................................................................ 458
Control Caching on Per-Record Basis ...................................................................................... 459
Rate-Based DNS Caching with Rate Limiting ........................................................................... 460
DNS Record Weighting for Selective Cache Entry Aging ......................................................... 462
Throttling Based on Domain Name ........................................................................................... 463
CLI Example – Logging ............................................................................................................. 464
CLI Example – Show Commands ............................................................................................. 464
RADIUS Message Load Balancing 467

Overview.............................................................................................................................................. 467
Traffic Flow for RADIUS Message Load Balancing ...................................................................... 468
Protocol Port Numbers Supported with Stateless RADIUS Load Balancing ................................ 469
Load-balancing Method ................................................................................................................ 469
Load Balancing Across Data CPUs ........................................................................................... 469
RADIUS Session Aging ................................................................................................................ 470
Configuration ...................................................................................................................................... 470

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
RAM Caching 475

Overview ..............................................................................................................................................475
RFC 2616 Support ....................................................................................................................... 475
If-Modified-Since Header Support ............................................................................................. 476
Support for no-cache and max-age=0 Cache-Control Headers ................................................ 476
Insertion of Age and Via Headers into Cached Responses ...................................................... 477
Cacheability Behavior of AX RAM Cache .................................................................................... 477
Dynamic Caching ......................................................................................................................... 478
Host Verification ........................................................................................................................... 478
Memory Allocations for RAM Caching .......................................................................................... 479
Configuring RAM Caching..................................................................................................................480
Health Monitoring 491

Default Health Checks ........................................................................................................................491
Health-check Guidelines .............................................................................................................. 492
Health Method Timers.........................................................................................................................492
Health Check Operation ............................................................................................................... 494
Health Method Types ..........................................................................................................................496
Protocol Port Numbers Tested by Health Checks ........................................................................ 501
Configuring and Applying a Health Method .....................................................................................502
Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments .............................. 506
Using Send and Receive Strings in TCP Health Checks ............................................................. 508
Certificate and Key Support in HTTPS Health Monitors ........................................................... 510
Configuring POST Requests in HTTP/HTTPS Health Monitors ................................................... 511
Customizing DNS Health Monitors ............................................................................................... 514
DNS Health Monitoring over TCP ............................................................................................. 517
Overriding the Target IP Address or Protocol Port Number ......................................................... 517
Basing a Port’s Health Status on Another Port’s Health Status ................................................... 520
Service Group Health Checks ............................................................................................................521
Disable Following Failed Health Check.............................................................................................524
In-Band Health Monitoring .................................................................................................................525
Configuring In-Band Health Monitoring ........................................................................................ 527
Consecutive Health Checks Within a Health Check Period ............................................................529
Maintenance Health Status for Servers in Persistence Configurations.........................................529
On-Demand Health Checks ................................................................................................................531
Enabling Strict Retries........................................................................................................................532

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
Globally Changing Health Monitor Parameters ............................................................................... 533
Globally Disabling Layer 3 Health Checks .................................................................................... 534
Health-check Rate Limiting................................................................................................................ 535
Database Health Monitors.................................................................................................................. 538
Database Health Monitor Parameters ....................................................................................... 538
Compound Health Monitors............................................................................................................... 539
Displaying Health Status.................................................................................................................... 544
Using External Health Methods......................................................................................................... 547
Configuration ................................................................................................................................ 547
Script Examples ............................................................................................................................ 549
TCL Script Example .................................................................................................................. 549
Perl Script Example ................................................................................................................... 551
Shell Script Example ................................................................................................................. 551
Python Script Example .............................................................................................................. 552
Database Health Monitoring Using a Script .................................................................................. 552
Network Address Translation for SLB 557

Overview.............................................................................................................................................. 558
SLB Destination NAT .................................................................................................................... 558
SLB Source NAT .......................................................................................................................... 559
Connection Reuse ..................................................................................................................... 559
Source NAT for Servers in Other Subnets ................................................................................ 564
Direct Server Return........................................................................................................................... 566
IP NAT Support for VIPs..................................................................................................................... 568
Using IP Pool Default Gateways To Forward Traffic from Real Servers........................................ 569
Smart NAT for Virtual Ports ............................................................................................................... 569
Virtual-port TCP Maximum Segment Life for NATted Sessions..................................................... 573
IP Limiting 575
Overview.............................................................................................................................................. 575
Class Lists .................................................................................................................................... 575
Class List Syntax ....................................................................................................................... 576
IP Address Matching ................................................................................................................. 577
Example Class Lists .................................................................................................................. 577
IP Limiting Rules ........................................................................................................................... 578
Match IP Address ...................................................................................................................... 579
Request Limiting and Request-rate Limiting in Class Lists ....................................................... 579

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
Configuring Source IP Limiting .........................................................................................................582
Configuring a Class List ............................................................................................................... 582
Configuring the IP Limiting Rules ................................................................................................. 586
Applying Source IP Limits ............................................................................................................ 589
Displaying IP Limiting Information ................................................................................................ 591
CLI Examples—Configuration ...................................................................................................... 592
Configure System-Wide IP Limiting With a Single Class .......................................................... 592
Configure System-Wide IP Limiting With Multiple Classes ....................................................... 592
Configure IP Limiting on a Virtual Server .................................................................................. 593
Configure IP Limiting on a Virtual Port ...................................................................................... 593
Configure Class List Entries That Age Out ............................................................................... 594
CLI Examples—Display ................................................................................................................ 595
Class Lists ................................................................................................................................. 595
IP Limiting Rules ....................................................................................................................... 596
IP Limiting Statistics .................................................................................................................. 597
Advanced Traffic Replication 599
Geo-location-based Access Control for VIPs 607

Configuration Using a Class List.......................................................................................................607
Configuration Using a Black/White List ............................................................................................609
Configuring the Black/White List .................................................................................................. 609
Enabling Full-Domain Checking for Connection Limits ..................................................................614
Full-Domain Checking .................................................................................................................. 615
Enabling PBSLB Statistics Counter Sharing ................................................................................ 616
SLB Parameters 617

SLB Packet Processing Order ...........................................................................................................618
Service Template Parameters ............................................................................................................619
Cache Template Parameters ....................................................................................................... 621
Cipher Template Parameters ....................................................................................................... 624
Client-SSL Template Parameters ................................................................................................. 625
Connection Reuse Template Parameters .................................................................................... 629
Cookie Persistence Template Parameters ................................................................................... 630
Destination-IP Persistence Template Parameters ....................................................................... 632
Diameter Template Parameters ................................................................................................... 634
DNS Template Parameters (DNS security) .................................................................................. 638
DNS Template Parameters (DNS caching per VIP) ..................................................................... 638
HTTP Template Parameters ........................................................................................................ 641
Policy Template Parameters ........................................................................................................ 649
Server-SSL Template Parameters ............................................................................................... 654

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
SIP Template Parameters (SIP over TCP/TLS) ........................................................................... 657
SIP Template Parameters (SIP over UDP) ................................................................................... 661
SMTP Template Parameters ........................................................................................................ 663
Source-IP Persistence Template Parameters .............................................................................. 665
SSL Session-ID Persistence Template Parameters ..................................................................... 669
Streaming-Media Template Parameters ....................................................................................... 670
TCP Template Parameters ........................................................................................................... 671
TCP-Proxy Template Parameters ................................................................................................. 673
UDP Template Parameters ........................................................................................................... 680
System-wide SLB Parameters........................................................................................................... 681
Real Server Parameters ..................................................................................................................... 689
Real Service Port Parameters............................................................................................................ 692
Service Group Parameters................................................................................................................. 695
Virtual Server Parameters.................................................................................................................. 703
Virtual Service Port Parameters ........................................................................................................ 707
Server and Port Templates 717

Overview.............................................................................................................................................. 717
Default Server and Port Templates .............................................................................................. 718
Parameters That Can Be Configured Using Server and Port Templates ..................................... 719
Configuring Server and Port Templates ........................................................................................... 722
Applying a Server or Service Port Template .................................................................................... 724
Binding a Server Template to a Real Server ................................................................................ 724
Binding a Server Port Template to a Real Server Port ................................................................. 725
Binding a Virtual Server Template to a Virtual Server .................................................................. 725
Binding a Virtual Server Port Template to a Virtual Service Port .................................................. 726
Binding a Server Port Template to a Service Group ..................................................................... 726
Connection Limiting ........................................................................................................................... 727
Setting a Connection Limit ........................................................................................................ 728
Connection Rate Limiting .................................................................................................................. 729
Slow-Start............................................................................................................................................ 731
Graceful Shutdown............................................................................................................................. 735
Gratuitous ARPs for Subnet VIPs ..................................................................................................... 735
aFlow Request Queuing..................................................................................................................... 736
aFlow Control Operation ............................................................................................................... 737
TCP Reset Option for Session Mismatch ......................................................................................... 738
Client Port Preservation..................................................................................................................... 740
Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
Dynamic Real Server Creation Using DNS 743

Template Options for Dynamically Created Real Servers ...............................................................744
Configuring Dynamic Real Server Creation......................................................................................746
VIP Creation Based on Subnet 753
Sending a Reset After Server Selection Failure 755
Alternate Servers and Ports for Individual Backup 761

Alternate Servers.................................................................................................................................761
Configuration ............................................................................................................................. 762
Alternate Ports.....................................................................................................................................766
Configuration ............................................................................................................................. 767
Priority Affinity 771

Overview ..............................................................................................................................................771
Priority Affinity Options......................................................................................................................774
Actions Tied to Exceeded Limits .................................................................................................. 775
Source-IP Persistence Override and Reselect 781

Overview ..............................................................................................................................................781
Scan-All-Members Option in Persistence Templates 785
SSL Certificate Management 789

Overview ..............................................................................................................................................789
SSL Process ................................................................................................................................. 790
Certificate Chain ........................................................................................................................ 791
Certificate Warning from Client Browser ................................................................................... 792
CA-Signed and Self-Signed Certificates ................................................................................... 793
SSL Templates ............................................................................................................................. 794
Client-SSL Template Options .................................................................................................... 794
Server-SSL Template Options .................................................................................................. 797
Cipher Template Options .......................................................................................................... 798
Certificate Installation Process ..................................................................................................... 798
Requesting and Installing a CA-Signed Certificate ................................................................... 799
Installing a Self-Signed Certificate ............................................................................................ 801
Generating a Key and CSR for a CA-Signed Certificate ..................................................................801

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents
Importing a Certificate and Key......................................................................................................... 804
Generating a Self-Signed Certificate ................................................................................................ 806
Importing a CRL.................................................................................................................................. 808
Renewing a Certificate (GUI) ............................................................................................................. 809
Exporting Certificates, Keys, and CRLs ........................................................................................... 810
Exporting a Certificate and Key .................................................................................................... 810
Exporting a CRL ........................................................................................................................... 812
Creating a Client-SSL or Server-SSL Template and Binding it to a VIP ........................................ 812
Creating an SSL Template ........................................................................................................... 813
Binding an SSL Template to a VIP ............................................................................................... 813
Multiple CA Certificate Support in Server-SSL Templates ........................................................ 814
Support for Binding Server-SSL Templates to Individual Real Ports ........................................ 816
Support for TLS Server Name Indication ......................................................................................... 818
Configuring Email Notification for SSL Certificate Expiration ....................................................... 819
Converting Certificates and CRLs to PEM Format .......................................................................... 821
Converting SSL Certificates to PEM Format ................................................................................ 821
Converting CRLs from DER to PEM Format ................................................................................ 823
Preventing Reset of SLB and Ethernet Statistics 825

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Contents

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
One-Arm Deployment in Route Mode
This chapter provides an example of a widely used Server Load Balancing

(SLB) deployment method—one-arm deployment in route mode.
For additional deployment examples, see “More SLB Deployment Exam-

ples” on page 63.
Overview
One-arm deployment allows the AX device to be added to the network
without inserting the device directly into the traffic path between clients and
servers. Figure 1 shows an example of an AX device deployed in route
mode in a one-arm topology.
Note: This example includes use of Access Control Lists (ACLs) to add a layer
of security on top of the basic deployment. An alternative is to use the
Layer 2/3 virtualization feature. Layer 2/3 virtualization allows the AX
device to be partitioned into multiple logical devices with their own inde-
pendent network resources. (For information, see the “Role-Based
Administration” chapter in the AX Series System Configuration and
Administration Guide.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 1 AX Deployment Example – Route Mode One-Arm Deployment
The blue arrows show the traffic flow for client-server traffic; in this exam-
ple, between clients and server 10.10.10.51.
• A client sends a request to 10.10.10.100:80.
• The Layer 3 router forwards the request to the AX device.
• The AX device selects a server within the VIP’s service group, and for-
wards the request to the server.
• The server reply is routed back to the AX device, which then forwards
the reply to the client.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
AX Interface Configuration
The AX device has a single physical connection to the network, through the
Layer 2 switch. Two VIPs are configured on the AX device:
• 10.0.0.10:80 – The AX device load balances requests to this VIP to the
servers in DMZ1, on subnet 10.0.0.0 /24.
• 10.10.10.100:80 – The AX device load balances requests to this VIP to
the servers in DMZ2, on subnet 10.10.10.0 /24.
The Layer 3 router is configured to route requests to either VIP to the AX

device.
The AX physical interface (Ethernet port 1) connected to the Layer 2 switch

is configured with a separate IP interface to each real server subnet:
• 10.0.0.2 – This IP interface is configured on Virtual Ethernet (VE) inter-
face 10, on VLAN 10.
• 10.10.10.2 – This IP interface is configured on VE interface 20, on
VLAN 20.
A default route on the AX device routes server reply traffic through the
Layer 3 router to clients.
Traffic Blocking Between VLANs

Ethernet port 1 is an 802.1Q-tagged member of each VLAN. As standard
behavior, Layer 2 traffic is not forwarded between the VLANs.
To also prevent Layer 3 traffic from being forwarded between the VLANs,
an Access Control List (ACL) is used. The ACL has the following rules:
• Deny IP traffic from 10.0.0.x to 10.10.10.x
• Deny IP traffic from 10.10.10.x to 10.0.0.x
The ACL is applied to each VLAN’s VE.
Network Address Translation

The AX device uses source NAT for communication with the servers. A
separate pool is configured for each server subnet. Source NAT is required
to ensure that server replies pass back through the AX device before being
forwarded to clients.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration Example
This section shows the GUI screens and CLI commands needed to imple-
ment the configuration shown in Figure 1.
USING THE GUI
ACL Configuration
The following GUI pages configure the ACL. The ACL will be used to
block Layer 3 traffic between VLANs. The Log option enables generation
of log messages when traffic matches the ACL and is dropped.
Note: The log option enables logging for this ACL, but logging still must be
enabled on the system level. Logging is disabled by default. To configure
logging, see the “Basic Setup” chapter in the AX Series System Configura-
tion and Administration Guide.
FIGURE 2 Config Mode > Network > ACL > Extended - block traffic from
10.0.0.x to 10.10.10.x

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 3 Config Mode > Network > ACL > Extended - block traffic from
10.10.10.x to 10.0.0.x
FIGURE 4 Config Mode > Network > ACL > Extended - ACL table

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Interface Configuration
The following GUI pages configure the physical and IP interfaces.
FIGURE 5 Config Mode > Network > Interface > LAN - enable port 1
FIGURE 6 Config Mode > Network > VLAN - configure VLAN 10

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 7 Config Mode > Network > VLAN - configure VLAN 20
FIGURE 8 Config Mode > Network > VLAN - VLAN table

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 9 Config Mode > Network > Interface > Virtual - configure VE 10
FIGURE 10 Config Mode > Network > Interface > Virtual - configure VE 20

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 11 Config Mode > Network > Interface > Virtual - VE table
FIGURE 12 Config Mode > Network > Interface > LAN - data interface table
Default Route Configuration

The following GUI page configures the default route.
FIGURE 13 Config Mode > Network > Route > IPv4 Static

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Source NAT Pool Configuration
The following GUI pages configure the IP source NAT pools.
FIGURE 14 Config Mode > Service > IP Source NAT > IPv4 Pool -
configure pool for DMZ 1 servers
FIGURE 15 Config Mode > Service > IP Source NAT > IPv4 Pool -
configure pool for DMZ 2 servers
FIGURE 16 Config Mode > Service > IP Source NAT > IPv4 Pool - IPv4 NAT
pool table

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SLB Configuration – Real Servers
The following GUI pages configure the real servers.
FIGURE 17 Config Mode > Service > SLB > Server - configure s1
Configuration for the other real servers is similar. In Figure 18, all the real
servers have been configured.
FIGURE 18 Config Mode > Service > SLB > Server - real server table

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SLB Configuration – Service Groups
The following GUI pages configure the service groups.
FIGURE 19 Config Mode > Service > SLB > Service Group - configure
wbgroup1
Configuration for the other service group is similar. In Figure 20, both ser-
vice groups have been configured.
FIGURE 20 Config Mode > Service > SLB > Service Group - service group
table

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SLB Configuration – Virtual Servers
The following GUI pages configure the virtual servers.
FIGURE 21 Config Mode > Service > SLB > Virtual Server - configure
webvip1 (part 1)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
webvip1 (part 2)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
webvip1 (part 3)
Configuration for the other virtual server is similar. In Figure 24, both vir-
tual servers have been configured.
FIGURE 24 Config Mode > Service > SLB > Virtual Server - virtual server
table

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI
The following commands configure ACL 101:

AX(config)#access-list 101 deny ip 10.0.0.0 0.0.0.255 10.10.10.0 0.0.0.255 log
AX(config)#access-list 101 deny ip 10.10.10.0 0.0.0.255 10.0.0.0 0.0.0.255 log
The ACL will be used to block Layer 3 traffic between VLANs. The log
option enables generation of log messages when traffic matches the ACL
and is dropped.
Note: The log option enables logging for this ACL, but logging still must be
enabled on the system level. Logging is disabled by default. To configure
logging, see the “Basic Setup” chapter in the AX Series System Configura-
tion and Administration Guide.
The following commands enable Ethernet interface 1:

AX(config)#interface ethernet 1
AX(config-if:ethernet1)#enable
AX(config-if:ethernet1)#exit
The following commands configure VLANs 10 and 20:

AX(config)#vlan 10
AX(config-vlan:10)#tagged ethernet 1
AX(config-vlan:10)#router-interface ve 10
AX(config-vlan:10)#vlan 20
AX(config-vlan:20)#exit
The following commands configure the IP interfaces on the VLAN’s VEs.

The access-list commands bind ACL 101 to the inbound traffic direction on
the interfaces. The ACL does not take effect until it is bound to the inter-
faces.
AX(config)#interface ve 10
AX(config-if:ve10)#ip address 10.0.0.2 /24
AX(config-if:ve10)#access-list 101 in
AX(config-if:ve10)#interface ve 20
AX(config-if:ve20)#ip address 10.10.10.2 /24
AX(config-if:ve20)#access-list 101 in
AX(config-if:ve20)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following command configures the default route:
AX(config)#ip route 0.0.0.0 /0 10.0.0.1
SLB Configuration
The following commands configure the source NAT pools:
AX(config)#ip nat pool dmz1 10.0.0.200 10.0.0.200 netmask /24
AX(config)#ip nat pool dmz2 10.10.10.200 10.10.10.200 netmask /24
The following commands configure the real servers:

AX(config)#slb server s1 10.0.0.50
AX(config-real server)#port 80 tcp
AX(config-real server-node port)#exit
AX(config-real server)#exit
The following commands configure the service groups:

AX(config)#slb service-group wbgroup1 tcp
AX(config-slb svc group)#member s1:80
AX(config-slb svc group)#exit
AX(config)#slb service-group wbgroup2 tcp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands configure the virtual servers:
AX(config)#slb virtual-server webvip1 10.0.0.10
AX(config-slb virtual server)#port 80 http
AX(config-slb virtual server-slb virtua...)#source-nat pool dmz1
AX(config-slb virtual server-slb virtua...)#service-group wbgroup1
AX(config-slb virtual server-slb virtua...)#exit
AX(config-slb virtual server)#exit
AX(config)#slb virtual-server webvip2 10.10.10.100
AX(config-slb virtual server-slb virtua...)#source-nat pool dmz2
AX(config-slb virtual server-slb virtua...)#service-group wbgroup2

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Layer 3 Direct Server Return
The AX Series supports Direct Server Return (DSR) in Layer 3 environ-

ments. Layer 3 DSR allows a real server to be in a different subnet from the
AX device, so the AX and real servers can be separated by a router, as
shown in Figure 25 below.
FIGURE 25 Layer 3 DSR deployment
Note: Although this diagram shows IPv4 addresses, L3 DSR is also supported in
IPv6 environments. Refer to “CLI Example for DSCP Configuration
(IPv6)” on page 54 for configuration details.
With Layer 3 DSR enabled, a real server can belong to multiple VIPs.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
L3 DSR Packet Flow
The AX device provides Layer 3 DSR by making use of the Differentiated
Services Code Point (DSCP) field, which was originally designed to pro-
vide QoS across IP networks. Due to its use of the DSCP field, the AX
device can support up to 63 VIPs with L3 DSR.
When the AX device receives a client request, it uses the configured load
balancing method to select a real server. The AX device then processes the
packet and updates the DSCP field in the packet header in order to signify
which VIP processed the incoming packet.
By setting the DSCP value in the packet’s header, the AX device creates a
record between DSCP value and the VIP that handled the packet. These
DSCP-to-VIP mappings are stored in a table on the real servers. Up to 63
such mappings can be created, (which corresponds to DiffServ’s range of
values 1-63).
The real server uses the mappings in these tables to know which VIP to
include as the source address in the packets returned to the client.
Note: In Layer 3 DSR, the DSCP values are not used to make routing decisions
but simply offer a way for the real server to track which VIP processed a
specific packet.
The DSCP value is set in a virtual port template, and that template is then
applied to the virtual port in the VIP configuration.
If a virtual port template with a DSCP value is applied to a virtual port, then
all service groups bound to this virtual port (as well as real servers) will also
be associated with the VIP that uses this particular DSCP value.
By applying the template on a virtual port, there can be a particular real

server that belongs to multiple VIPs. This eliminates any one-to-one restric-
tions that may occur if the template is applied at the real server level.
You can configure the DSCP value using the SLB template port DSCP
option within the SLB template. This template can then be applied to a real
server port, or if more granularity is needed, can be bound to a service group
member.
L3 DSR Packet Flow

When Layer 3 Direct Server Return (DSR) is enabled, the DSCP value is
used at the real server level to identify a particular VIP in the response pack-
ets to the client.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
L3 DSR Packet Flow
A table is stored on the real server. This table contains mappings which
associate the DSCP values with the loopback interfaces configured on the
real server. The loopback interface on the real server has the same address
as one of the VIPs configured on the AX device.
When the AX device is configured as described above, packets will flow

from the client to the AX and back to the client as shown in Figure 26.
FIGURE 26 Layer 3 DSR
Step 1 in Figure 26 shows that as the packet goes from the client to the AX
device, the packet’s source address is that of the client, the destination
address is the VIP on the AX device, and the DSCP value is set to 0 (mean-
ing DSCP is “not configured” when the packet leaves the client).
Step 2 shows that the AX device sends the client’s request to a real server
(using a standard load-balancing method). The source address of the packet
remains unchanged, but the destination address is set to the IP address of the
real server instead of the VIP. The AX device also changes the DSCP value
from “0” to “x”, where “x” represents a user-configured DSCP value rang-
ing from 1-63, and corresponds to one of the VIPs configured as a loopback
on the real server.
Note: If L3 DSR is enabled, your router must not be configured with DSCP-
based QoS or this will cause a conflict to occur, because L3 DSR is also
attempting to use the DSCP field which is typically used for QoS.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Monitoring for L3 DSR
In Step 3, the real server responds to the client, setting the source address to
the loopback address of the VIP. (This is the VIP where the client’s request
was originally sent.) The destination address is the client's IP address, and
the DSCP value is set to “0”.
Using the VIP as the Source Address in the Server’s Reply

Layer 3 DSR is similar to standard DSR in that the real servers reply
directly to the clients, bypassing the AX device in the process. Even though
responses are sent from the real server, the source address in the server’s
response is that of the AX VIP. By making the AX VIP appear as the source
address, the real server’s IP address remains hidden from the client.
The AX device’s VIP is configured on the real server as a loopback inter-

face. The loopback address should be configured so that it does not respond
to ARP queries. This approach prevents duplicate IP addresses and also pro-
tects the real server’s anonymity.
The A10 Kernel Module

An A10 kernel module is provided by A10 Networks. The module consists
of sample source code, which must be incorporated into the Linux operating
system on each real server.
The purpose of the A10 kernel module is to extract the DSCP value from
the packets sent to the real server from the AX device. The module uses this
extracted DSCP value to change the source address in the real server’s
response to the client, so the source IP will match the VIP that is associated
with that extracted DSCP value.
This A10 kernel module looks up the packet information (IP addresses,
Layer 4 transport protocol type, and DSCP value), and recalculates the
checksum. The server’s IP stack then forwards the packet back to the client.
For more information acquiring or modifying the A10 kernel module,

please contact A10 Networks.

The commands and options needed to configure health monitoring for L3
DSR are generally the same as those for other types of SLB configurations.
Configure the health monitor, and then specify the monitor name when you
enable the health-check option on the real servers, service ports, or service
group.
The AX device individually checks the health of each VIP loopback address
on each real server. The IP header of each health-check packet includes the

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
DSCP value for a VIP. The source IP address of the request is an AX inter-
face, and the destination of the request is the real server IP address.
When the server replies to the health check packet, the source IP address is
the VIP that has been mapped to the DSCP value included in the request.
The destination IP address is the IP address of the AX device. If the AX
device does not receive the expected type of reply from the VIP, the health
check fails.
Notes
• Layer 3 DSR requires installation of the A10 kernel module on the real
servers. This A10 kernel (L3 DSR SDK source code) must be incorpo-
rated into the Linux operating system on each real server. In the current
release, the A10 kernel module is available for Linux servers only. Con-
tact A10 Networks or your reseller for details.
• The configuration options described in this section provide a more
robust Layer 3 DSR solution than can be provided using the dest-nat
option, used in mixed Layer 2/3 DSR deployments. The dest-nat option
is useful for deploying backup servers to use only if the primary servers
all become unavailable.
Configuring Health Monitoring of VIPs in DSR Deployments
Layer 3 and Layer 4-7 health checks are supported in DSR configurations.
Layer 3 health checks are sent to the IP address of the real server’s IP
address using the default Layer 3 health method (ICMP).
Layer 4-7 health checks are sent to the same IP address as the Layer 3 health
checks, but are then addressed to the specific protocol port. You can use the
default TCP and UDP health monitors or configure new health monitors.
Note: The following sections show how to configure Layer 3 health checks.
A complete DSR deployment requires additional configuration informa-
tion. (See “More SLB Deployment Examples” on page 63.)
Note: A10 recommends configuring a Health Monitor at the service group level.
(This recommendation applies to both L2 DSR and L3 DSR deploy-
ments). It is particularly important to set up Health Monitors for each ser-
vice group when L3 DSR is enabled and one real server belongs to
multiple VIPs. The added granularity can assist in troubleshooting, and it
can also avoid future problems when a customer moves from a one-to-one
binding to one-to-many binding.
See “CLI Example for One-to-many Health Monitors” on page 52 for a
sample CLI configuration showing separate health checks on each service-
group.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring Layer 3 DSR
USING THE GUI

To configure health monitoring for L3 DSR, you must use the CLI. This
functionality is not supported in the GUI in the current release.
USING THE CLI
To configure a Layer 3 health method targeted to a virtual IP

address:
Use the following commands:
health monitor monitor-name
[interval seconds | retry number | timeout seconds

| up-retry number]
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

To configure Layer 3 DSR on the AX device:
1. Optionally, configure health checks for the servers and service ports.
2. Configure a virtual server port template that sets the DSCP value for
client requests before sending them to a real server.
3. Configure the real servers and service ports. If you configured health
checks, apply them to the servers and service ports.
4. Configure a service group and add each real server and service port to
the group.
5. In the virtual server configuration, enable DSR on the virtual port, and
apply the virtual port template and service group to the port.
To configure a real server for Layer 3 DSR:

1. Install the A10 kernel module (Linux source code) on each real server.
For installation advice, contact A10 Networks.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
2. Configure a loopback interface on each real server that corresponds to
one of the AX VIPs. There should be a mutually exclusive, one-to-one
mapping. Assign the VIP address to the loopback interface and then dis-
able ARP replies from that interface.
3. Configure the server to map the DSCP value in the client request to the
VIP and to send the server reply from that loopback interface.
Setting the DSCP value is the only configuration option that is unique to L3
DSR configuration. The other options are the same as those used for other
SLB configurations, and are therefore not described here. (See “More SLB
Deployment Examples” on page 63.)
Note: As an alternative to applying the virtual port template at the VIP level,
you can apply the template at the real server level, resulting in a one-to-
one mapping between the real server and the VIP. This option is not rec-
ommended and is supported for backward compatibility.
USING THE GUI
To set a DSCP value in a virtual port template you must use the CLI. This
functionality is not supported in the GUI in the current release.
USING THE CLI
To set the DSCP value for a virtual port, use the following command at the
configuration level for a virtual port template:
[no] dscp num
The num option specifies the DSCP value and can be 1-63.
To bind the template to a virtual port, use the template template-name com-
mand at the virtual port configuration level within a virtual server.
CLI Example for DSCP Configuration (IPv4)

The following example shows the commands used to configure L3 DSR.
First, the health checks, real servers, and service groups must be configured,
followed by the virtual port templates with DSCP values 1–63. Each of the
virtual port templates is then bound to port 80 on the respective VIP.
Configure the health checks

AX(config)#health monitor hm-1 interval 5
AX(config-health:monitor)#method icmp
AX(config-health:monitor)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Globally enable DSR health checking of VIPs
AX(config)#slb dsr-health-check-enable
Configure the real servers and ports

AX(config)#slb server rs1 20.10.10.3
Configure a TCP service group and bind to RS1, RS2, and RS3
AX(config)#slb service-group sg-web tcp
AX(config-slb service group)#member rs1:80
AX(config-slb service group)#exit
Configure virtual port templates with DSCP values 1-63

AX(config)#slb template virtual-port dscp-1
AX(config-vport)#dscp 1
AX(config-vport)#exit
...

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Bind each virtual port template to port 80 on the respective VIP
AX(config)#slb virtual-server VS1 192.168.1.10
AX(config-slb vserver)#port 80 tcp
AX(config-slb vserver-vport)#template virtual-port dscp-1
AX(config-slb vserver-vport)#service-group sg-web
AX(config-slb vserver-vport)#exit
AX(config-slb vserver)#exit
..

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Example for One-to-many Health Monitors
In this example, a real server (rs1) belongs to two VIPs. Therefore, a sepa-
rate health monitor must be configured for each service-group to which the
server belongs, as shown below:
Configure the real server rs1 at IP 20.10.10.3

Include the real server rs1 in two service groups, sg1 and sg2
AX(config)#slb service-group sg1 tcp
Create two health monitors, web11 and web22

AX(config)#health monitor web11
AX(config-health:monitor)#method http url GET /www.example1.com
AX(config)#health monitor web22
AX(config-health:monitor)#method http url GET /www.example2.com
Configure virtual port templates with DSCP values 11 and 22

AX(config)#slb template virtual-port dscp11

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Associate the service groups with the health monitors
AX(config-slb service group)#health-check web11
AX(config-slb service group)#health-check web22
Create VIP11 at IP 11.11.11.11 with service group sg1, and then

apply virtual port template dscp11
AX(config)#slb virtual-server vip11 11.11.11.11
AX(config-vserver)#port 80 tcp
AX(config-vserver)#service-group sg1
AX(config-vserver)#slb template virtual-port dscp11
AX(config-vserver)#no-dest-nat
AX(config-vserver)#exit
Create VIP22 at IP 22.22.22.22 with service group sg2, and then

apply virtual port template dscp22
AX(config-vserver)#port 80 tcp
AX(config-vserver)#service-group sg2
AX(config-vserver)#slb template virtual-port dscp22
AX(config-vserver)#no-dest-nat
AX(config-vserver)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Example for DSCP Configuration (IPv6)
The following example shows the commands used to configure L3 DSR for
an IPv6 deployment. The virtual port templates are configured with DSCP
values from 10–50, in multiples of 10. Then, the health checks, real servers,
and service groups must be configured. Finally, each of the virtual port tem-
plates is then bound to port 53 on the respective VIP.
Configure virtual port templates with DSCP values 10–50

Configure the health checks

AX(config)#health monitor dns-test
AX(config-health:monitor)#method dns domain test.com
AX(config)#health monitor 53tcp

AX(config-health:monitor)#method tcp port 53
AX(config)#health monitor 53udp

AX(config-health:monitor)#method udp port 53
AX(config)#health monitor dns-test2


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX(config)#health monitor dns-test3

AX(config)#health monitor v6-dns-test

AX(config)#health monitor v6-dns-test2

AX(config)#health monitor v6-dns-test3

Globally enable DSR health checking of VIPs

AX(config)#slb dsr-health-check-enable
Configure the real servers and ports

AX(config)#slb server 20 20.20.20.20
AX(config-real server-node port)#port 53 udp



Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

AX(config-real server)#port 53 udp
AX(config)#slb server 20v6 2020::20

AX(config-real server-node port)#port 53 tcp


AX(config)#slb server ronsv4 20.20.20.128

Configure a UDP service group and bind to 20, 21, and rsonsv4
AX(config)#slb service-group 53udp udp
AX(config-slb service group)#health-check dns-test
AX(config-slb service group)#member 20:53
AX(config-slb service group)#member ronsv4:53

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configure a TCP service group and bind to 20, 21, and rsonsv4
AX(config)#slb service-group 53tcp tcp
Configure a UDP service group with health-check dns-test, and

bind to 23
AX(config)#slb service-group testudp udp
Configure a TCP service group and bind to 23

AX(config)#slb service-group testtcp tcp
Configure a UDP service group, with health-check dns-test2,

and bind to 20, 21, and ronsv4 at port 53
AX(config)#slb service-group 53udp2 udp
AX(config-slb service group)#health-check dns-test2
Configure a UDP service group, with health-check dns-test3,

and bind to 20 and 21 at port 53
AX(config)#slb service-group 53udp3 udp
AX(config-slb service group)#health-check dns-test3

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configure a UDP service group, with health-check v6-dns-test,
and bind to 20v6 and 21v6 at port 53
AX(config)#slb service-group v6-53udp udp
AX(config-slb service group)#health-check v6-dns-test
AX(config-slb service group)#member 20v6:53
Configure a UDP service group, with health-check v6-dns-test2,

AX(config)#slb service-group v6-53udp2 udp
AX(config-slb service group)#health-check v6-dns-test2
Configure a UDP service group, with health-check v6-dns-test3,

AX(config)#slb service-group v6-53udp3 udp
AX(config-slb service group)#health-check v6-dns-test3
Configure a TCP service group, with health-check 53tcp, and

bind to 20v6 and 21v6 at port 53
AX(config)#slb service-group 53tcpv6 tcp
AX(config-slb service group)#health-check 53tcp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configure a TCP service group, with health-check 53tcp, and
bind to 21v6 and 200v6 at port 53
AX(config)#slb service-group 53tcpv6_2 tcp
AX(config-slb service group)#health-check 53tcp
Bind each virtual port template to port 53 on the respective VIP

AX(config)#slb virtual-server dsr1 5.5.5.5
AX(config-slb vserver)#port 53 udp
AX(config-slb vserver-vport)#service-group 53udp
AX(config-slb vserver-vport)#no-dest-nat
AX(config-slb vserver-vport)#template virtual-port dscp10
AX(config-slb vserver-vport)#service-group 53tcp

AX(config-slb vserver-vport)#service-group 53udp2

AX(config-slb vserver)#disable
AX(config-slb vserver-vport)#service-group 53udp3

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX(config)#slb virtual-server v6-dsr1 2030::30

AX(config-slb vserver-vport)#service-group v6-53udp
AX(config-slb vserver-vport)#service-group 53tcpv6

AX(config-slb vserver-vport)#service-group v6-53udp2
AX(config-slb vserver-vport)#service-group 53tcpv6_2

AX(config-slb vserver-vport)#service-group v6-53udp3
AX(config-slb vserver-vport)#service-group 53tcpv6_2

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

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

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

Fax: +1-408-325-8666
www.a10networks.com

The AX device provides a simple method to collect configuration and status
information for Technical Support to use when diagnosing system issues.
To collect system information, use either of the following methods.
USING THE GUI (RECOMMENDED)

1. Log into the GUI.
2. Select Monitor > System > Logging.
3. On the menu bar, click Show Tech.
4. Click Export. The File Download dialog appears.
5. Click Save. The Save As dialog appears.
6. Navigate to the location where you want to save the file, and click Save.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI

1. Log into the CLI.
2. Enable logging in your terminal emulation application, to capture output

generated by the CLI.
3. Enter the enable command to access the Privileged EXEC mode of the
CLI. Enter your enable password at the Password prompt.
4. Enter the show techsupport command.
5. After the command output finishes, save the output in a file.
Note: As an alternative to saving the output in a log file captured by your termi-
nal emulation application, you can export the output from the CLI using
show techsupport export [use-mgmt-port] url
(For syntax information, see the AX Series CLI Reference.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
More SLB Deployment Examples
This chapter provides additional deployment examples for Server Load Bal-
ancing (SLB). The following types of deployment are shown:
• Layer 3 deployment:
• “Route Mode” on page 64
• Direct Server Return (DSR) deployment:

• “Direct Server Return in Transparent Mode” on page 69
• “Direct Server Return in Route Mode” on page 74
• “Direct Server Return in Mixed Layer 2/Layer 3 Environment” on
page 77
• Layer 2 deployment:
• “Transparent Mode” on page 82
• “Transparent Mode in Multinetted Environment” on page 89
Note: For Layer 3 deployment in one-arm mode, see “One-Arm Deployment in

Route Mode” on page 25.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Route Mode
Route Mode
Figure 27 shows an example of an AX device deployed in route mode.
FIGURE 27 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-0026 - Ver. 2.7.0 11/1/2012
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 OSPF and
IS-IS. In this example, a static route is configured to use as the default route
through 10.10.10.1.
Although this example shows single physical links, you could use trunks as
physical links. You also could use multiple VLANs. In this case, the IP
addresses would be configured on Virtual Ethernet (VE) interfaces, one per
VLAN, instead of being configured on individual Ethernet ports.
Since the AX device is a router in this deployment, downstream devices can

use the AX device as their default gateway. 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 the AX Series
System Configuration and Administration Guide.)
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 82.
Note: In the current release, the GUI does not support configuration of OSPF or
IS-IS.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Route Mode
USING THE GUI
FIGURE 28 Config Mode > Network > Interface > LAN - Ethernet data port
1 selected
FIGURE 29 Config Mode > Network > Route > IPv4 Static

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Route Mode
USING THE CLI
The following commands enable the Ethernet interfaces used in the exam-
ple and configure IP addresses on them:
AX(config-if:ethernet1)#ip address 10.10.10.2 /24
AX(config-if:ethernet1)#interface ethernet 2
The following command configures the default route through 10.10.10.1:

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

Commands to configure the service group


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Route Mode
Commands to configure the virtual server
AX(config-slb virtual server-slb virtua...)#service-group sg-web

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Direct Server Return in Transparent Mode

Figure 30 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 30 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
DSR Health Checking

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.
checks, and then addressed to the specific protocol port. You can use the
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 on the return traffic. This
allows real servers to respond directly to clients, bypassing the AX
device and retaining the IP address of the real server in the response
to the client.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.)
This section shows how to implement the configuration shown in Figure 30.
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 Mode > 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 section 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Enable DSR on virtual ports
1. Select Config Mode > 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. In the Virtual Server Port section, 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.
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 interface connected to the cli-
ents and server:


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

AX(config-slb virtual server)#port 80 tcp
AX(config-slb virtual server-slb virtua...)#no-dest-nat
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-0026 - Ver. 2.7.0 11/1/2012
Direct Server Return in Route Mode

Figure 31 shows an example of an AX device deployed in a DSR configura-
tion in route mode.
FIGURE 31 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 69.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
This section shows how to implement the configuration shown in Figure 31.
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 Mode > 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-0026 - Ver. 2.7.0 11/1/2012
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:

The rest of the configuration commands are the same as those shown in
“Direct Server Return in Transparent Mode” on page 69, beginning with
configuration of the real servers.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 32 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 32 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.2.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-0026 - Ver. 2.7.0 11/1/2012
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, desti-
nation NAT is disabled on virtual ports used for DSR. However, destina-
tion NAT needs to be enabled on the real port on the backup server.
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.
Destination NAT can not be set directly on an individual real port. To
enable destination NAT on a real port, create a real port template and
enable destination NAT in the template. You can bind the template to the
real port itself, or to the service group member for the port.
• If you bind the template to the port itself, the template applies to the
port in all service groups that use the port.
• If you bind the template to the service group member instead, the
template applies to the port only within the service group. The tem-
plate does not apply to the same port when used in other service
groups.
USING THE GUI
Configure a port template to enable destination NAT on the

backup server’s port
1. Select Config Mode > Service > SLB.
2. On the menu bar, select Template > Server Port.
3. Click Add.
4. Enter a name for the template in the Name field.
5. Select Disabled next to Direct Server Return.
6. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configure the service group
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. Add the primary servers to the service group:

a. Select a primary server from the Server drop-down list.
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.
b. Enter the protocol port number in the Port field.
c. Select 16 from the Priority drop-down list.
d. Click Add.
e. Repeat for the other primary server.
6. Add the backup server to the service group:

a. Select the backup server from the Server drop-down list.
b. Enter the protocol port number in the Port field.
c. Select the port template for the backup server from the Server Port
Template drop-down list. This is the template configured in “Con-
figure a port template to enable destination NAT on the backup
server’s port” on page 78.
d. Leave 1 selected in the Priority drop-down list.
e. Click Add.
7. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 33 Config Mode > Service > SLB > Template > Server Port
FIGURE 34 Config Mode > Service > SLB > Service Group
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
CLI Example
The following commands configure a server port template for the backup
server:
AX(config)#slb template port dsrbackup
AX(config-rport)#dest-nat
AX(config-rport)#exit
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 template port dsrbackup

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Transparent Mode
Transparent Mode
Figure 35 shows an example of an AX Series device deployed in transpar-
ent mode.
FIGURE 35 AX Deployment Example – Transparent Mode
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Transparent Mode
Note: For simplicity, this example and the other examples in this chapter show
the physical links on single Ethernet ports. Everywhere a single Ethernet
connection is shown, you can use a trunk, which is a set of multiple ports
configured as a single logical link.
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 “Network
Address Translation for SLB” on page 557.)
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.
USING THE GUI
The following figures show the GUI screens used to implement the configu-
ration shown in Figure 35. Here and elsewhere in this guide, the command
paths used to access a GUI screen are listed in the figure caption.
Interface Configuration
FIGURE 36 Config Mode > Network > Interface > Transparent

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Transparent Mode
Note: For reference, Figure 36 shows the entire interface. Subsequent figures
show only the relevant configuration page.
FIGURE 37 Config Mode > Network > Interface > LAN

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 38 Config Mode > Service > SLB > Server

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Transparent Mode
Service group configuration

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Transparent Mode
Virtual server configuration
FIGURE 40 Config Mode > Service > SLB > Virtual Server
FIGURE 41 Config Mode > Service > SLB > Virtual Server - Virtual Server
Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Transparent Mode
USING THE CLI
way:
ple:



AX(config-slb virtual server)#port 80 fast-http

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Transparent Mode in Multinetted Environment

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

Environment
This example is similar to the example in Figure 35, 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-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
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 82.
USING THE GUI
FIGURE 43 Config Mode > Network > VLAN
FIGURE 44 Config Mode > Service > IP Source NAT > IPv4 Pool

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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-0026 - Ver. 2.7.0 11/1/2012


AX(config-slb virtual server-slb virtua...)#source-nat pool pool1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring a Wildcard VIP
Wildcard VIPs
You can create SLB configurations that use wildcard VIPs and wildcard vir-
tual ports. You can use a wildcard VIP along with an ACL or an HTTP tem-
plate for highly granular control of a specific subset of traffic or a specific
HTTP URL.
Generally, wildcard VIPs are applicable to through traffic selected based on

ACL or HTTP information, instead of traffic terminated on an IP address
hosted by the AX device (for example, a VIP). Through traffic is selected
based on criteria specified in the ACL or the HTTP template.
You can use wildcard VIPs for many types of load balancing, such as:
• IP load balancing
• SSL Intercept
• Transparent Cache Switching (TCS)
• Link Load Balancing (LLB)
• Firewall Load Balancing (FWLB)
• Direction of server-initiated traffic to specific destinations
• Policy-based routing
• aFleX packet processing for transparent traffic
Note: Use of wildcard VIPs and interface-based SYN cookies is not supported.

1. Configure the ACL or HTTP template to use for capturing (matching
on) traffic.
2. Configure the real servers and service group.
3. Configure the VIP.
The procedure for configuring the VIP itself is the same as the procedure for
configuring a standard VIP, except you have the option to bind an ACL to
the wildcard VIP.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
IPv4 wildcard VIPs have IP address 0.0.0.0. IPv6 wildcard VIPs have
address :: (double colon). 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 (IPv4) or :: (IPv6),
each with its own port 0.
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, each with its own unique
ACLs.
However, the AX device can have only one IPv4 or IPv6 wildcard VIP that
is not bound to any ACL. This is the default wildcard VIP. The default wild-
card VIP is used for traffic that does not match any of the ACLs bound to
other wildcard 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
The AX device supports forwarding of wildcard VIP traffic that is not
bound to a service group. The AX device creates a session for the traffic and
forwards it at Layer 2/3. This feature is useful in mixed wildcard virtual
server environments where Layer 4-7 features apply to certain VIPs and
Layer 2/3 forwarding applies to other traffic.
Note: 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Wildcard VIP Examples

For examples of deployments that use wildcard VIPS, see the following:
• “IPv4 Load Balancing” on page 99
• “IPv6 Load Balancing” on page 107
• “SSL Offload and SSL Proxy” on page 279
• “ALG Protocol FWLB Support for FTP and SIP” on page 353
• “Transparent Cache Switching” on page 395

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
IPv4 Load Balancing
This chapter describes load balancing of traffic based solely on transport

protocol (TCP, UDP, or others such as ICMP), 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 others such as ICMP (not UDP
or TCP), without 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 46 shows a hypothetical example of an IP protocol load balancing

deployment.
Note: For a real-world example, see the following document: AX Series with
Microsoft Exchange Server 2010 Deployment Guide. This deployment
guide is available for download from the A10 Networks website.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 46 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-0026 - Ver. 2.7.0 11/1/2012
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.
Note: 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-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
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 such as ICMP, you can spec-
ify 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. In the real server Port section (Config Mode > Service > SLB > Server),
enter 0 in the Port field.
2. In the Service Group section, enter 0 as the port number on the Service
Group page.
3. In the Virtual Server Port section (Config Mode > Service > SLB > Vir-
tual 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 46 on

page 100.
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-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration Examples
IPv6 Load Balancing
This chapter describes how to configure IPv6 IP load balancing on virtual

servers and wildcard VIPs. IPv6 IP load balancing for ICMP and tunnel pro-
tocols such as IPIP6 also is supported.
Note: IPv4 to IPv6 and IPv6 to IPv4 port wildcard load balancing is not sup-
ported in the current release.
Support for IPv6 IP load balancing is end to end as shown in the following
graphic:
V6 Traffic V6 Traffic
Clients AX: IP Load Balance Server
“Port 0 Others” roup
Example 1:
For IPv6 load balancing with a regular VIP (including an ICMP echo
request/reply), follow the documented steps:
1. On the AX device, issue the following commands:
AX-Active(config)#slb virtual-server v6 2011::3
AX-Active(config-slb vserver)#ha-group 1
AX-Active(config-slb vserver)#port 0 others
AX-Active(config-slb vserver-vport)#name _v6_2011_3_others_65535
AX-Active(config-slb vserver-vport)#source-nat pool 2012
AX-Active(config-slb vserver-vport)#service-group v6tcp
AX-Active(config-slb vserver-vport)#ha-conn-mirror
2. On a client, issue the ping 2011::3 command.
3. On the AX, issue a show session command. You may repeat the steps 2
and 3 on multiple clients using the same AX VIP.
With the configuration on the AX device, the ping command will function
normally and an ICMP session will be created on the AX device.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Example 2:
For IPv6 load balancing with a regular VIP, and with an IPIP6 tunnel con-
figured on both the client and the server, issue the following commands:
1. On the AX device, issue the following commands:
AX-Active(config)#slb virtual-server v6 2011::3
AX-Active(config-slb vserver-vport)#name _v6_2011_3_others_65535
AX-Active(config-slb vserver-vport)#source-nat pool 2012
AX-Active(config-slb vserver-vport)#service-group v6tcp
2. On a client and a server, configure an ipip6 tunnel.
3. Run traffic on this tunnel.
4. On the AX, issue a show session command. You may repeat the steps 2
and 3 on multiple clients using the same AX VIP.
With this configuration on the AX device, the traffic on the tunnel will work
correctly, with an IP session created on the AX device.
Example 3:
For IPv6 load balancing with a wildcard VIP, and an ICMP echo request/
reply, your running configuration will look like the following:
slb virtual-server wv6 ::
ha-group 15
port 0 others
name _wildcard_v6_v6_Others_0
service-group gw
no-dest-nat
ha-conn-mirror
With this configuration on the AX device, the ping command will function
normally and an ICMP session will be created on the AX device.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
1. Configure device using the following configuration steps.
AX-Active(config)#slb virtual-server wv6 ::
AX-Active(config-slb vserver-vport)#name _wildcard_v6_v6_Others_0
AX-Active(config-slb vserver-vport)#service-group gw
2. On the client, execute ping 2011::10.
3. On the AX device, execute the show session command.
4. Repeat step 2 and 3 from multiple clients on the same AX VIP.
5. On another client, issue the ping 2011::11 command.
6. On the AX device, execute CLI show session command.
Example 4:
For IPv6 load balancing with a wildcard VIP in a L3V partition, and with an
IPIP6 tunnel configured on both the client and the server, your running con-
figuration will look like the following:
slb virtual-server wv6 ::
ha-group 15
port 0 others
name _wildcard_v6_v6_Others_0
service-group gw
no-dest-nat
ha-conn-mirror
With this configuration on the AX device, the traffic on the tunnel will work
correctly, with an IP session created on the AX device.
1. Configure the AX device using the following configuration commands:
AX-Active(config)#slb virtual-server wv6 ::
AX-Active(config-slb vserver-vport)#name _wildcard_v6_v6_Others_0
AX-Active(config-slb vserver-vport)#service-group gw
AX-Active(config-slb vserver-vport)#no-dest-nat

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
2. On the client and server, configure the ipip6 tunnel.
3. Run traffic on this tunnel.
4. On the AX device, execute the show session command.
5. While the session with the current partition still exists, repeat the above
steps 2, 3, and 4 in a different partition.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 “IPv4 Load
Balancing” on page 99.
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 47 shows an example of a Layer 4 load balancing implementation.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 47 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.
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).
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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.
Idle Timeouts
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 671
• “UDP Template Parameters” on page 680
Source-IP Persistence
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 665.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 491.

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
To configure the real servers

2. Select Server on the menu bar.
3. Click Add.
4. In the General section, configure general settings for the server.
5. In the Port section, enter the protocol port number of the application in
the port field.
6. In the Type drop-down list, select the transport protocol for the applica-
tion, TCP or UDP.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
7. Configure other port settings if needed, then click Add. The application
port appears in the Port list.
8. Click OK. The real server appears in the real server table.
FIGURE 48 Config Mode > Service > SLB > Server (tcp-2)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 49 Config Mode > Service > SLB > Server (showing configured
real servers)
To configure the service group

1. Select Config Mode > Service > SLB, if not already selected.
2. Select Service Group on the menu bar.
3. Click Add.
4. In the Service Group section, enter a name for the service group.
tion, TCP or UDP.
6. In the Server section, select a server from the Server drop-down list.
7. Enter the protocol port number in the Port field.
8. Click Add.
9. Repeat step 6 through step 8 for each server and port.
10. Click OK. The service group appears in the Service Group table.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
(Optional) To configure a custom TCP or UDP template

1. Select Config Mode > Service > Template.
2. Select L4 > TCP or L4 > UDP on the menu bar.
3. Click Add.
4. Enter a name for the template.
5. Edit template settings as needed for your application. (See “TCP Tem-
plate Parameters” on page 671 or “UDP Template Parameters” on
page 680.)
6. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To configure a source-IP persistence template
2. Select Persistent > Source IP Persistent on the menu bar.
3. Click Add.
5. Edit template settings as needed for your application. (See “Source-IP

Persistence Template Parameters” on page 665.)
6. Click OK.
FIGURE 51 Config Mode > Service > Template > Persistent > Source IP
Persistence
To configure the virtual server

1. Select Config Mode > Service > SLB, if not already selected.
2. Select Virtual Server on the menu bar.
3. Click Add.
4. Enter a name for the virtual server.
5. In the IP Address field, enter the virtual IP address to which clients will
send requests.
6. Select or enter other general settings as needed.
7. In the Port section, click Add. The Virtual Server Port section appears.
tion, TCP or UDP.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
9. Enter the application port number in the Port field.
10. If you configured any custom templates, select them from the drop-
down lists for each template type.
11. Enter or select other values as needed.
12. Click OK. The port appears in the port section.
13. Click OK again. The virtual server appears in the virtual server list.
FIGURE 52 Config Mode > Service > Virtual Server

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 53 Config Mode > Service > Virtual Server - Virtual Server Port
section
USING THE CLI

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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:
member server-name:portnum
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”.
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 671 or “UDP Template
Parameters” on page 680. 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
5. To configure the virtual server, use the following commands:

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 {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:
service-group group-name
The group-name is the name of the service group configured in step 2.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
If you configured a custom template, use the following command to
bind the template to the service group:
template template-type template-name
CLI EXAMPLE

AX(config)#slb server tcp-2 10.10.10.2
The following commands configure the service group:

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
The following commands configure the virtual server:

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-0026 - Ver. 2.7.0 11/1/2012
Stateless Load-Balancing Methods
Stateless SLB
Stateless SLB conserves system resources by operating without session

table entries on the AX device. Session table entries contain information
about sessions, including the client, VIP, and real server IP addresses and
protocol ports. Session table entries also may contain additional state infor-
mation for specific features.
If the AX device is running short on sessions, you can use stateless SLB
where applicable to make more sessions available for traffic that requires
session table entries.
Stateless SLB is valid for the following types of traffic:

• Traffic with very short-lived sessions, such as DNS
• Layer 2 Direct Server Return (DSR) traffic
• Other types of traffic that do not require features that use session-table
entries. (See “Limitations” on page 124.)
You can enable stateless SLB on an individual service-group basis, by

selecting a stateless SLB load-balancing method for the group. (See “Using
the CLI” on page 125.)

The following stateless SLB methods are available:
• Stateless Source IP+Port Hash – Balances server load based on a hash
value calculated using the source IP address and source TCP or UDP
port.
• Stateless Destination IP+Port Hash – Balances server load based on a
hash value calculated using the destination IP address and destination
TCP or UDP port.
• Stateless Source and Destination IP Hash – Balances server load based
on a hash value calculated using both the source and destination IP
addresses, and the source and destination TCP or UDP ports.
• Stateless Source IP Only Hash – Balances server load based on a hash
value calculated using the source IP address only.
• Stateless Per-Packet Round Robin – Balances server load by sending
each packet to a different server, in rotation.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Limitations
Stateless SLB is not valid for the following features or traffic types:
• Rate limiting
• ACLs
• IP source NAT
• HA session synchronization
• Application Layer Gateway (ALG)
• Layer 3 DSR
• SLB-PT
• aFleX
A given real server can be used in only one stateless SLB service group. The
AX will assume any traffic coming from a real server in a stateless SLB ser-
vice group is response traffic and needs to be processed through the virtual
IP address. A real server that is in a stateless SLB service group can not be
used in any other service groups.
DNS templates are not supported with stateless load-balancing methods.
Adding or removing a member of the service group will cause the AX

device to recalculate the distribution hash, potentially causing existing con-
nections to be sent to different servers.
When a health check marks a member of the service group down, there is a
pre-calculated backup hash that allows the connections associated with the
failed server to be evenly redistributed to other servers. When the failed
member is marked back up by the health check, the redistributed connec-
tions will immediately be sent back to the original server based on the pri-
mary hash.
If the virtual port is on a wildcard VIP, destination NAT must be disabled on

the virtual port.
Graceful transitions between stateful and stateless SLB in a service group

are not supported.
Mega-proxies may interfere with equal balancing of traffic load among the
multiple data CPUs. In this case, for DNS traffic only, try using the state-
less-per-pkt-round-robin method.
Note: The stateless-per-pkt-round-robin method is applicable only for traffic

that uses a single packet for a request. Examples include DNS queries or

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
RADIUS requests without a Challenge-request/Response message used
for EAP.
USING THE GUI
On the service group configuration page, select one of the following from
the Algorithm drop-down list:
• Stateless Source IP+Port Hash
• Stateless Destination IP+Port Hash
• Stateless Src and Dst IP Hash
• Stateless Source IP Only Hash
• Stateless Per-Packet Round Robin
USING THE CLI

To enable stateless SLB for a service group, use one of the following
options with the method command, at the configuration level for the service
group:
• stateless-dst-ip-hash
• stateless-src-dst-ip-hash
• stateless-src-ip-hash
• stateless-per-pkt-round-robin
• stateless-src-ip-only-hash
Configuration of the real servers and virtual server is the same as for stateful
SLB.
CLI Example
The following commands configure a stateless SLB service group for UDP
traffic. Traffic is load balanced based on a hash value of the source and des-
tination IP addresses.
AX(config)#slb service-group dns-stateless udp
AX(config-slb svc group)#member dns1:53
AX(config-slb svc group)#member dns2:53
AX(config-slb svc group)#method stateless-src-dst-ip-hash

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Stateless Hash-based SLB
Stateful hash-based load balancing provides the persistence and perfor-

mance benefits of hash-based load balancing, while allowing use of
advanced SLB features that require stateful load balancing. For example,
rate limiting is an advanced SLB feature that requires stateful load balanc-
ing.
The main difference between stateless load balancing and stateful load bal-
ancing is that stateful load balancing uses the AX session table to manage
sessions. Stateless load balancing does not use the session table.
This chapter describes the following stateful hash-based load balancing

methods:
• src-ip-hash – Calculates a hash value based on the source IP address and
protocol port of the client’s request.
• src-ip-only-hash – Calculates a hash value based on only the source IP
address of the client’s request.
• dest-ip-hash – Calculates a hash value based on the destination IP
address and protocol port of the client’s request.
• dest-ip-only-hash – Calculates a hash value based on only the destina-
tion IP address of the client’s request.
How Hashing Works

The AX device assigns each available real server in the service group to a
hash bucket. Each hash bucket consists of a unique set of possible hash
values.
When a client initiates a session by sending a request, the AX device calcu-

lates a hash value based on address information in the request. The AX
device then sends the request to the server to which the calculated hash
value belongs. All subsequent traffic for that session is sent to the same
server.
If the server used by the client session goes down (fails a health check), the
AX device recalculates the hash buckets, and sends the client to one of the
available servers. For persistence, the AX device continues to use the new
server for the client, even when the down server comes back up.
The hash calculation always results in the same hash value, on any AX
device running this software version. This consistency is important in cases

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
where a client’s session traffic might pass through different AX devices. For
example, the consistent hash values hash are important in Equal Cost Mul-
tipath (ECMP) topologies in which multiple AX devices are deployed.
USING THE GUI
On the configuration page for the service group, select one of the following
values from the Algorithm drop-down list:
• Source IP Only Hash
• Source IP Hash
• Destination IP Only Hash
• Destination IP Hash
USING THE CLI
To use a stateful hash-based load-balancing method, use one of the follow-

ing values with the method command at the configuration level for the ser-
vice group:
• dst-ip-hash
• dst-ip-only-hash
• src-ip-hash
• src-ip-only-hash
CLI Example
The following commands configure a service group to use stateful hashing
based only on source IP address:
AX(config)#slb service-group stateful-IP-LB tcp
AX(config-slb svc group)#method src-ip-only-hash

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Auto-switch to Stateless SLB Based on Traffic
The AX device has a service-group option that begins using stateless load
balancing instead of stateful load balancing, based on traffic.
You can configure the change from stateful to stateless load balancing to be
triggered based on connection rate or Layer 4 session use.
Note: This feature supports only a single virtual port per service group. If you
configure this feature on a service group, you can use that service group
with only one virtual port.
Options for this Feature

You can configure the following options for this feature. Although only
some of these options must be specified when you configure the feature,
none of the options has a default value.
• Trigger – The trigger can be one of the following:
• Connection rate – Rate of new connection requests per second at
which the load balancing method is changed. The rate applies col-
lectively to all servers in the service group. The threshold can be
1-1000000 connection requests per second.
• Layer 4 session use – Percentage of the system-wide Layer 4 ses-
sion capacity that is currently in use. The threshold can be 1-100
percent.
• Trigger duration – Number of seconds during which the specified trig-
ger must continue to occur before the service group changes to stateless
load balancing. You can specify 1-600 seconds.
• (Optional) Revert trigger – Connection rate or Layer 4 session use per-
centage at which the service group can revert to using stateful load bal-
ancing.
• For connection rate, the threshold can be 1-1000000 connection
requests per second.
• For Layer 4 session use, the threshold can be 1-100 percent.
• (Optional) Revert duration – Number of seconds during which the spec-

ified revert trigger must continue to occur before the service group
changes to stateful load balancing again. You can specify 1-600 seconds.
• (Optional) Grace period – Number of seconds the AX device continues
to use the current load balancing method for active sessions, before
changing to the other load balancing method. You can specify 1-600
seconds.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: The grace period applies only to sessions that are active when the load
balancing change is triggered. The change applies immediately to new
sessions that begin after the change is triggered.
• Logging – Logs changes between stateful and stateless load balancing
that occur due to this feature. Logging is disabled by default.
USING THE GUI

1. Navigate to the configuration page for the service group.
• If configuring a new service group, select Config Mode > Service >
SLB > Service Group. Click Add.
• If modifying an existing service group, use the same menu path
shown above. However, instead of clicking Add, click on the ser-
vice-group name.
2. Select the Auto Stateless Method checkbox. This displays a drop-down

list of the stateless methods used by this feature.
3. Select the stateless method from the drop-down list. This displays con-
figuration fields for the options described in “Options for this Feature”
on page 129.
4. To specify the trigger type, select one of the following:

• Connection Rate
• Session Usage
5. Configure the applicable trigger options. (See “Options for this Feature”
on page 129.)
6. Add the servers, if they are not already added.
7. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI
To configure a service group to change to a stateless load balancing method

based on traffic, use the auto-switch option when specifying the method.
[no] method lb-method auto-switch

[
stateless-lb-method
{ conn-rate rate duration
[revert-rate revert-duration]
[grace-period seconds] [log] |
l4-session-usage percent duration
[revert-rate revert-duration]
[grace-period seconds] [log]
}
]
The lb-method option specifies the default load-balancing method to use.

The stateless-lb-method option specifies the stateless load-balancing
method to use if the traffic reaches the configured threshold, and can be one
of the following:
• stateless-dst-ip-hash
• stateless-per-pkt-round-robin
• stateless-src-dst-ip-hash
• stateless-src-ip-hash
• stateless-src-ip-only-hash
The remaining options configure the threshold. (See “Options for this Fea-
ture” on page 129.)
If you need to manually reset the service group to stateful SLB, use the fol-
lowing command at the configuration level for the service group:
reset auto-switch
CLI Example 1
The following commands configure a service group that uses the stateless-
per-pkt-round-robin stateless load-balancing method. This method is used if
the rate of new connection requests to the virtual port bound to the service

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
group reaches 80,000 connections per second, and remains at least this high
for 300 seconds.
AX(config)#slb service-group auto-stateless tcp
AX(config-slb svc group)#method weighted-rr auto-switch stateless-per-pkt-
round-robin conn-rate 80000 300 60000 300 grace-period 15 log
To return to using the stateful load-balancing method (weighted round-robin

in this example), the rate of new connection requests to the virtual port must
drop to 60,000 per second, and remain that low for at least 300 seconds.
Once this occurs, the AX device waits for and additional 15 seconds (the
grace period) before returning to use of stateful load balancing. Logging is
enabled.
CLI Example 2
In the following configuration, if Layer 4 session usage reaches 2 percent
and stays at least this high for 5 seconds, both service-group members begin
using the stateless-dst-ip-hash method. The AX device reverts back to
stateful load balancing when 1 percent or less is reached for 5 seconds.
slb service-group sg-auto1 tcp
method dst-ip-hash auto-switch stateless-dst-ip-hash l4-session-usage 2 5 1 5
member s1:80
member s2:80
slb service-group sg-auto tcp

method dst-ip-hash auto-switch stateless-dst-ip-hash l4-session-usage 2 5 1 5
member s3:80
member s4:80

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 54 shows an example of an FTP load balancing solution.
FIGURE 54 FTP Load Balancing

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 Series supports both the passive and active (port) FTP modes.
The following example uses the weighted-round-robin load balancing

method. The AX Series device is configured to send all HTTP requests to
server ftp-2. FTP requests will be load balanced among servers ftp-2, ftp-3,
and ftp-4.
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 two service groups. One service group contains all three
FTP servers and the other service group contains a single server for HTTP.
To provide the weighted load balancing described above, the load balancing
method is changed from the default (round robin) to weighted round robin
for the FTP service group.
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-0026 - Ver. 2.7.0 11/1/2012
Configuring FTP Load Balancing
For more information about templates, see the following:
• “Service Template Parameters” on page 619
• “Server and Port Templates” on page 717
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 491.)

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-0026 - Ver. 2.7.0 11/1/2012
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

1. Select Config Mode > Service > Health Monitor.
2. Click Add.
3. In the Health Monitor section, enter a name for the monitor in the Name
field.
4. Click Method.
5. In the Method section, 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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 55 Config Mode > Service > Health Monitor (for HTTP monitor)
FIGURE 56 Config Mode > Service > Health Monitor - Method section (for
FTP monitor)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 57 Config Mode > Service > Health Monitor (showing configured
health monitors)

3. Click Add.
4. In the General section, 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. In the Port section, 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 136. (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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 58 Config Mode > Service > SLB > Server (ftp-2)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 61 Config Mode > Service > SLB > Server (showing configured
real servers)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: The Health Monitor column shows the Layer 3 (ICMP ping) health moni-
tors for the real servers, not the Layer4-7 health monitors for individual
server ports.
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 62 Config Mode > 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. In the Service Group section, 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-0026 - Ver. 2.7.0 11/1/2012
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 to service group http-grp.
10. Click OK. The new service group appears in the service group table.
FIGURE 63 Config Mode > 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 142, 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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 64 Config Mode > Service > Service Group (for FTP)
FIGURE 65 Config Mode > Service > Service Group (service groups
added)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
2. Select Virtual Server on the menu bar, if not already selected.
3. Click Add.
4. In the General section, 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.
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 142.
12. Click OK. The new virtual server appears in the virtual server table.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 66 Config Mode > Service > Virtual Server
section (for HTTP)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
section (for FTP)
FIGURE 69 Config Mode > Service > Virtual Server - Port section (ports
added)
FIGURE 70 Config Mode > Service > Virtual Server (virtual server added)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
health-check monitor-name
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-0026 - Ver. 2.7.0 11/1/2012
The idle-timeout command specifies the number of seconds a TCP ses-
sion can remain idle. For this example, set the idle timeout to 15000 sec-
onds.
4. To configure a service group for HTTP, use the following commands:

slb service-group group-name tcp
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 to
weighted round robin:
method weighted-rr
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.

This command creates the virtual server and changes the CLI to the con-
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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:80
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-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Streaming-Media Load Balancing
This chapter describes streaming-media load balancing and how to config-

ure it.
Note: Also see “Generic TCP-Proxy” on page 261.
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 225.
Figure 71 shows an example of a streaming-media load balancing solution.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 71 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-0026 - Ver. 2.7.0 11/1/2012
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 671.)
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.
5. Configure other options, if applicable to your configuration.
6. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012

AX(config)#slb server stream-rs1 192.168.66.21

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
Overview
HTTP Load Balancing
This chapter describes HTTP load balancing and how to configure it.
Note: This chapter and other SLB configuration chapters walk through the indi-
vidual GUI pages used for configuration. The GUI also provides smart
templates for easy configuration. For information, see the GUI online
help or the AX Series GUI Reference.
Note: Fast-HTTP is optimized for very high performance information

transfer in comparison to regular HTTP. Due to this optimization,
fast-HTTP does not support all the comprehensive capabilities of
HTTP such as header insertion and manipulation. It is recom-
mended not to use fast-HTTP for applications that require complete
data transfer integrity.
Overview
HTTP load balancing manages HTTP traffic across a Web server farm.
Figure 72 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).

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 72 HTTP Load Balancing
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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
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 707.)
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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 619.)
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 559.)
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
(For an example that uses a source-IP persistence template, see “Layer 4
TCP/UDP Load Balancing” on page 111.)
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 717 in this guide
• “Config Commands: SLB Templates” chapter in the AX Series CLI Ref-

erence
• “Config Mode > Service > SLB > Template” section in the “Config
Mode” chapter of the AX Series GUI Reference
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring HTTP Load Balancing
• 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 491.)

To configure the HTTP load balancing solution described in “Overview” on
page 159, 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.
USING THE GUI
To configure an HTTP health method

2. Select Health Monitor on the menu bar.
3. Click Add.
4. In the Health Monitor section, enter a name for the monitor.
5. In the Method section, select HTTP from the Type drop-down list.
The other configuration fields change to those that apply to HTTP health
monitors.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
6. Optionally, select or enter additional options for the health monitor. (See
“Health Monitoring” on page 491.)
In this example, you can use all the default settings
7. Click OK. The new monitor appears in the health monitor table.
FIGURE 73 Config Mode > Service > Health Monitor > Health Monitor

Perform the following procedure separately for each real server.
3. Click Add.
4. In the General section, 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 491.)
7. In the Port section, 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 164.
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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 75 Config Mode > 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
To configure the service group

1. Select Config Mode > Service > SLB, if not still selected.
2. Select Service Group on the menu bar.
3. Click Add.
4. In the Service Group section, select the load-balancing method from the
Algorithm drop-down list.
For this example, you can leave the default selected: Round Robin
5. In the Server section, 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-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
1. Select Config Mode > Service > SLB, if not still selected.
3. Click Add. The General section appears.
4. In the General section, 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.
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 section.
11. Click OK. The virtual server appears in the virtual server table.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Port section

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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:
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
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.

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”.
level for the port, where you can use the following command to enable
the HTTP health check:
For monitor-name, specify the name of the HTTP health monitor config-
ured in step 1.


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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:
to the server:
port port-number fast-http
or
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.
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 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)#slb server web-2 10.10.10.2
AX(config-real server-node port)#health-check http-hmon

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

AX(config-slb service group)#member web-2:80

AX(config)#slb virtual-server web-vip 192.168.10.11

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
HTTP templates can be used with the following service (virtual port) types:
• HTTP
• HTTPS
• Fast-HTTP
Note: Fast-HTTP is optimized for very high performance information

transfer in comparison to regular HTTP. Due to this optimization,
fast-HTTP does not support all the comprehensive capabilities of
HTTP such as header insertion and manipulation. It is recommended
not to use fast-HTTP for applications that require complete data
transfer integrity.
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 178.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
• 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 184.)
• 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 193.)
• 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 194.)
• 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-
ancing of server selection. (See “Strict Transaction Switching” on
page 216.)
• Non-HTTP bypass – Redirects non-HTTP traffic to a specific service
group. This feature helps prevent non-HTTP traffic from being dropped
by the AX device. (See “Non-HTTP Bypass” on page 196.)
Performance Enhancing Options

• High-speed HTTP Content Replacement – Allows quick configuration
of content replacement in HTTP replies from load-balanced servers.
(See “High-speed HTTP Content Replacement” on page 198.)
• 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 199.)
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 206.)
• Header insertion / erasure – Inserts a field:value pair into requests or
responses, or deletes a header. (See “Header Insertion / Erasure” on
page 209.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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 214.)
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:
USING THE GUI
To configure an HTTP template:

2. Select Application > HTTP on the menu bar.
3. Click Add. The HTTP section appears.
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 sections (App switching,
Redirect Rewrite, and Compression).
6. When finished, click OK. The template appears in the HTTP template
list.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Hash Switching
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 section appears.
4. Click Port. The Port section appears.
5. Select the port or Click Add. The Virtual Server Port section 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 section.
10. Click OK. The virtual server list reappears.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Hash Switching
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 79 shows an example of URL hashing.
FIGURE 79 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Hash Switching
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.
Hash Options
You can specify the following hash options:
• Offset – Specifies how far into the string to begin hash calculation.
• 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.
• Server load awareness – Allows servers to act as backups to other serv-
ers, based on load.
The example in Figure 79 calculates hash values based on the last 3 bytes of
the URL strings.
Offset
You can specify an offset at which to begin when calculating a hash value.
For example, you can configure the AX device to calculate a hash value
starting with the fifth character in the URL string, as shown in Figure 80.
FIGURE 80 URL Hashing Offset Example
url-hash-persist offset 5 first 7

/abcdefghijkl/somepage/with/graphics
Begin here Calculate hash based

on these 7 characters
By default, there is no offset.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Hash Switching
URL Hash Switching with Server Load Awareness

You can configure URL hash switching to be aware of server load. Server
load awareness allows servers to act as backups to other servers, based on
load.
Normally, URL hashing selects a server for the first request for a given
URL, then uses the same server for all subsequent requests for the same
URL. In cases where a given URL becomes wildly popular (for example, a
viral video), the server for that URL can become overwhelmed.
The server load awareness option provides a way to avoid server outage in
this type of situation. After some configuration on the server and on the AX
device, the AX device can learn a server’s load status from the server.
Server Configuration
This feature requires some custom configuration on the server. The server
must be configured to insert an HTTP header named “Server-Status” in the
server’s responses. The header must have one of the following values: 0, 1,
or 2.
Server-Status: load=N
The value N can be 0, 1, or 2.
The AX device manages requests to the server based on the Server-Status

code. Table 1 describes the valid load status codes that can be reported by a
server.
TABLE 1 Server-Status Load Values

Load Status
Reported by
Server Description AX Action
0 Server is able to handle all of its own AX device continues using the server for the
requests. URLs hashed to the server.
Server also can handle requests for other If necessary, AX device also uses the server
servers if necessary. to help with URLs hashed to servers that have
load status 2.
1 Server is able to handle its own requests. AX device continues using the server for the
However, server can not handle requests for URLs hashed to the server.
other servers. AX device does not use the server to help
handle requests for other servers.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Hash Switching
TABLE 1 Server-Status Load Values (Continued)
Load Status
Reported by
Server Description AX Action
2 Server is overloaded and needs help handling AX device uses servers that have load
its own requests. Requests are distributed status 0 to help handle the overloaded
among this server and at least one other server’s requests.
server (with load status 0), in round robin Note: If no other servers are able to help, all
fashion. servers in the service group are pulled in to
help. Requests will be sent round-robin
among the busy servers. For example, if there
are 3 servers, and s1 returns status 2, s2
returns 1, and s3 returns 0, then the traffic is
sent round-robin between s1 and s3. How-
ever, if s3 returns 1 or 2, then the traffic is
sent round-robin among all 3 servers.
The system conditions that result in reporting 0, 1, or 2 depend on how you

program calculation of the code. For example, you can program the server
to set the Server-Status code based on CPU utilization, memory utilization,
I/O utilization, and so on.
For a CPU-intensive application, you could calculate the Server-Status code

based on CPU utilization. For an I/O-intensive application, you could calcu-
late the Server-Status code based on I/O utilization.
Server Load Awareness Load-Balancing Example

Here is an example of how server load awareness works. In this example,
URL hash switching is used to balance traffic load across three servers:
S1, S2, and S3.
Assume that the first request for URI /article-new1 is hashed to S1. Subse-
quent requests are load balanced as listed in Table 1.
TABLE 2 Server-Status Load-Balancing Example

Load Status
Reported by
Server Server AX Action
S1 0 New requests for /article-new1 are sent only to server S1.
S2 0
S3 0
S1 2 New requests for /article-new1 are distributed between S1 and S2, using
S2 0 round robin.
S3 0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Hash Switching
TABLE 2 Server-Status Load-Balancing Example (Continued)
Load Status
Reported by
Server Server AX Action
S1 2 New requests for /article-new1 are distributed between S1 and S3, using
S2 1 or 2 round robin.
S3 0
AX Configuration
On the AX device, URL hash switching with server load awareness does not
require configuration of dedicated backup servers in the service group.
Instead, any primary server can also act as a backup for other servers, based
on server load.
Server load awareness is disabled by default but can easily be enabled in

new or existing URL hash switching configurations. Configure an HTTP
template with URL hash switching. Include the use-server-status (CLI) or
Use Server Status (GUI) option.
Configuring URL Hashing

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

1. Access the configuration sections for the template. (See “HTTP Tem-
plate Configuration” on page 177.)
2. Click App Switching.
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. If you plan to use the server load awareness option, select the Use
Server Status checkbox.
6. If applicable, enter the offset in the Offset field next to URL Hash.
7. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL / Host Switching
USING THE CLI
Enter the following command at the configuration level for the HTTP tem-
plate:
url-hash-persist [offset offset-bytes]
{first | last} bytes
[use-server-status}
CLI Examples
The following commands implement the URL hashing configuration shown

in Figure 79 on page 179.
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
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 following commands configure an HTTP template for URL hash

switching with server load awareness:
AX(config)#slb template http url-hash
AX(config-HTTP template)#url-hash-persist last 12 use-server-status
The following commands configure an HTTP template to perform URL

hashing with the offset shown in Figure 80 on page 180:
AX(config)#slb template http url_hash1
AX(config-http)#url-hash-persist offset 5 first 7

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:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• 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 189.)
Figure 81 shows an example of URL switching.
FIGURE 81 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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. However, if you need to use
both types of switching, you can do so with an aFleX script.
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.
• Equals
• 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
Configuring URL / Host Switching

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

2. Click App Switching.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI
Enter one of the following commands at the configuration level for the
HTTP template:
url-switching
{equals | starts-with | contains | ends-with}
url-string
service-group service-group-name
host-switching
{starts-with |contains | ends-with} host-string
CLI Example
The following commands implement the URL switching configuration

shown in Figure 81 on page 185.
The following commands configure the HTTP template:

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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 82 shows an example.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 82 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.
• 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
• 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Failover
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 83 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.example2.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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Failover
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 214.)
Configuring URL Failover

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

2. In the URL Failover field of the HTTP section, 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
The following commands bind the HTTP template to virtual port 80:
AX(config-slb virtual server-slb virtua...)#template http urlfailover

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 stops send-
ing client requests to the service port and server for 30 seconds.
Note: Server re-selection is not performed if Layer 3 features such as PBSLB,

source-IP persistence, or cookie 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 216.)
Note: This option is supported only for virtual port types HTTP and HTTPS. It
is not supported for fast-HTTP or any other virtual port type.
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
The first command continues to use the service port and server for client
requests, even after a reassignment has occurred. The second command
stops using the service port and server for 30 seconds after a reassignment
occurs.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
By default, logging of HTTP retries is disabled by default. To enable log-

ging of HTTP retries, use the following command at the configuration level
for the HTTP template:
[no] log-retry
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 stops using the service port and server for 30
seconds following reassignment.
AX(config)#slb template http 5xxretry
AX(config-HTTP)#strict-transaction-switch
AX(config-HTTP)#retry-on-5xx

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Non-HTTP Bypass
Non-HTTP Bypass
Non-HTTP bypass redirects non-HTTP traffic to a specific service group.
This feature helps prevent non-HTTP traffic from being dropped by the AX
device.
USING THE GUI
Select Config Mode > Template > Application > HTTP > Create
The new Non HTTP Bypass field added to this page allows you to indicate
the server to which you would like to redirect non-HTTP traffic.
From the drop down menu to the right of the Non HTTP Bypass field,
choose the server name.
Click Ok to save your changes.
USING THE CLI
To redirect non-HTTP traffic to a specific service group, from the HTTP

template configuration level, use the following command. By default, the
AX will drop non-HTTP requests that are sent to an HTTP port:
[no] non-http-bypass service-group group-name

service-group
group-name Indicates the name of the service group that will
receive all non-HTTP traffic.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
High-speed HTTP Content Replacement
CLI Example
To configure, view, or remove this feature, follow these steps:
1. On an AX, configure the HTTP template and indicate the service group
(in this case sg1) to which all non-HTTP traffic should be sent:
AX-Active(config)#slb template http http
AX-Active(config-http)#non-http-bypass service-group sg1
2. To view the existing configuration, use the show slb template com-
mand:
AX-Active(config-http)#show slb template | section sg1
slb service-group sg1 tcp
priority 10 drop
priority 5 reset
non-http-bypass service-group sg1
3. Bind the http template to the virtual port 80:

AX(config-slb vserver)#port 80 http
AX(config-slb vserver-vport)#name _10.10.10.66_HTTP_80
AX(config-slb vserver-vport)#service-group sg1
AX(config-slb vserver-vport)#template http http
The above commands help apply the template to the virtual-port. When
the http template is applied to the “virtual port 80,” any non-http
requests will be forwarded to the service-group specified in the non-http
bypass option.
4. To remove the non-http-bypass option for the service group (sg1), issue
AX-Active(config-http)#no non-http-bypass service-group sg1

The AX device provides an HTTP template option that allows quick config-
uration of content replacement in HTTP replies from load-balanced servers.
When the AX device detects the specified data pattern in a server reply, the
AX device replaces the matching content with the content you specify.
Note: A maximum of 16 content-replacement rules are supported in a given

HTTP template. If you need more rules, aFleX supports up to 32.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Content Format
The AX device uses either a Content-Length header or a Transfer-
Encoding: chunked header for the new content.
• If the replacement pattern is the same length as the original pattern, the
AX device uses the same header type used by the server.
• If the replacement pattern length is different from the length of the orig-
inal pattern, the AX device uses a Transfer-Encoding: chunked header
and chunk-encodes the content.
USING THE GUI

1. Navigate to the configuration page for the HTTP template.
• If configuring a new template, select Config Mode > Service >
Template > Application > HTTP. Click Add.
• If modifying an existing template, use the same menu path shown
above. However, instead of clicking Add, click on the template
name.
2. Click “Response Content Replace” to display the configuration fields

for content replacement.
3. In the Old String field, enter the content to look for in server responses.
This is the text to be replaced.
4. In the New String field, enter the content to use to replace the original
content.
5. Click OK.
Note: Quotation marks are not required, even if either or both strings contains
blank spaces.
USING THE CLI
To configure replacement of content in server responses, use the following

command at the configuration level of the HTTP template:
[no] response-content-replace
original-content new-content
The original-content specifies the content to look for in server responses.

The new-content specifies the content to use to replace the original content.
For each value, you can specify a string of 1-127 characters. If a string con-
tains blank spaces, use double quotation marks around the string.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Content Compression
CLI Example
The following command configures replacement of “Welcome to
Company X” with “Greetings from Company Y!”:
AX(config)#slb template http http1
AX(config-http)#response-content-replace "Welcome to Company X" "Greetings from Company
Y!"
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.
Note: Compression is supported only for HTTP and HTTPS virtual ports. Com-
pression is not supported for fast-HTTP virtual ports.
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.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Content Compression
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 the following AX models: AX 2200, AX 3200, AX 3200-11,
AX 3200-12, AX 3400, AX 5100, AX 5200, AX 5200-11, and AX 5630.
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.
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-0026 - Ver. 2.7.0 11/1/2012
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 84 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-0026 - Ver. 2.7.0 11/1/2012
Content Compression
Configuring Content Compression

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

1. Access the configuration sections for the HTTP template. (See “HTTP
Template Configuration” on page 177.)
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 Compression Type.
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:
a. Select Config Mode > Service > SLB.
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-0026 - Ver. 2.7.0 11/1/2012
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
does not compress. This option is disabled by default, which means the AX
device performs all the compression.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Content 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 coun-

ters 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
No tuple error 0
Parse req fail 0
Server selection fail 0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Client IP Insertion / Replacement
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 162 on page 558.)
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
real server. Instead, the source IP address of the request is the address into
which the AX device translates the client’s IP address.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 85 shows an example of client IP insertion.
FIGURE 85 Client IP Insertion

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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 209.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Header Insertion / Erasure
4. To change the name of the field, edit the name. Otherwise, leave the
field name set to the default (X-ClientIP).
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


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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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 206.
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 last 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
...

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
...
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 last one is replaced. Here is the result:
GET / HTTP/1.1
Cookie: a=1
Cookie: c=3
...
USING THE GUI

2. Click Header Insert.
3. To insert a request header:

a. In the Request section, 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-

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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.
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


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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 Header Erase.
3. To erase a request header:

a. In the Request section, enter the field name (the name portion 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
URL Redirect Rewrite
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
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:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 Redirect Rewrite.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Strict Transaction Switching
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
AX(config-slb virtual server-slb virtua...)#template http secureredirect

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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Enabling Strict Transaction Switching

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

2. In the HTTP section, 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-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Log Message Format
Web Logging for HTTP and RAM Caching
This chapter describes the AX support for logging to external servers over
TCP.
The AX device supports web logging for HTTP virtual ports. You can use
web logging with HTTP load balancing or RAM caching. Web logging for
load-balanced HTTP servers provides information about client access to the
servers. Likewise, web logging for RAM caching provides information
about client access to content that is cached on the AX device.
Web logging to external log servers is supported over TCP and UDP.
Note: In the current release, logging over TCP is applicable to web logging for
HTTP virtual ports. The rest of this chapter describes this use of the fea-
ture.
Log Message Format

Web logs generated by the AX device use the following format:
Client-Src-IP -- Timestamp-on-AX-device Request-info Payload-length
Referer-info User-agent Virtual-server-name:Virtual-port
Here is an example:
20.20.20.23 - - Mon Apr 23 23:38:13 2012 "GET / HTTP/1.0" 177
"-" "Wget/1.12 (linux-gnu)" vs:80
Configuration
To configure web logging:
1. Create a server configuration for each log server. On each server, add a
TCP port with the port number on which the log server listens for log
messages.
2. Add the log servers to a service group. Make sure to use the round-robin
load-balancing method. (This is the default method.)
3. (Optional) Configure a TCP-proxy template to customize TCP settings

for connections between the AX device and log servers. For example,
you can enable use of keepalive probes, to ensure that the TCP connec-

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
tions with the log servers remain established during idle periods
between logs. (See the CLI example below.)
4. Configure a logging template. Add the service group containing the log
servers to the logging template. If you configure a custom TCP-proxy
template, also add that template to the logging template.
5. To log web traffic sent to load-balanced HTTP servers, create a custom

HTTP template and add the logging template to it.
6. To log web traffic served from the AX device’s local RAM cache, create
a custom RAM Caching template and add the logging template to it.
7. On the VIP, add the HTTP or RAM Caching template (or both) to the
HTTP virtual port.
USING THE GUI

This section describes the GUI steps related to logging templates. The con-
figuration steps for the real servers, service groups, and VIPs are the same
as without use of logging templates.
Configuring a Logging Template

1. Select Config Mode > Service > Template > Application > Logging.
2. Click Add.
4. Select the service group that contains the log servers.
5. If you configured a custom TCP-proxy template for logging, select it.
6. Click OK.
Applying a Log Template to an HTTP Template

On the configuration page for the HTTP template, select the logging
template from the Logging Template drop-down list.
Applying a Log Template to a RAM Caching Template

On the configuration page for the RAM Caching template, select the
logging template from the Logging Template drop-down list.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
USING THE CLI
Configuring a Logging Template

To configure a logging template, use the following commands:
slb template logging template-name
This command changes the CLI to the configuration level for the template,
where the following commands are available:
This command specifies the name of the service group that contains the log
servers.
template tcp-proxy template-name
This command specifies the name of the TCP-proxy template to use for
managing the TCP sessions between the AX device and the log servers.
Applying a Log Template to an HTTP Template

Use the following command at the configuration level for the HTTP
template:
template logging template-name
Applying a Log Template to a RAM Caching Template

Use the following command at the configuration level for the RAM
Caching template:
template logging template-name
CLI Example
The following commands configure web logging for an IPv4 virtual port
and an IPv6 virtual port. On each virtual port, web logging is enabled both
for HTTP load-balanced client-server traffic and for client access to content
that is cached in the AX device's RAM cache.
In this example, two real servers are used as HTTP content servers and as
logging servers. Clients send requests for HTTP content to port 80. The AX
device either serves the requested from the local RAM cache, if available,
or sends the request to one of the servers.
In this example, the AX device uses the same servers as the content servers
and as the logging servers. Client requests for HTTP content are sent to port
80. Log traffic is sent to one of the following ports:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
• 4999 – TCP port listening for log traffic sent over IPv4.
• 5999 – TCP port listening for log traffic sent over IPv6.
To begin, the following commands configure the servers:

AX(config)#slb server rs 10.10.10.11
AX(config-real server-node port)#slb server rs6 3030::3011
The following commands configure the service groups for the applications
clients will access:
AX(config-slb svc group)#slb service-group sg tcp
AX(config-slb svc group)#member rs:80
AX(config-slb svc group)#slb service-group udpsg udp
AX(config-slb svc group)#member rs:5140
AX(config-slb svc group)#slb service-group v6sg tcp
AX(config-slb svc group)#member rs6:80
AX(config-slb svc group)#slb service-group udpsg6 udp
The following commands configure the service groups for the log servers:
AX(config-slb svc group)#slb template logging logtemp
AX(config-logging)#service-group logsg
AX(config-logging)#template tcp-proxy logtcp
AX(config-logging)#slb template logging udplog
AX(config-logging)#service-group udpsg
AX(config-logging)#slb template logging logtemp6
AX(config-logging)#service-group v6logsg
AX(config-logging)#template tcp-proxy logtcp
AX(config-logging)#slb template logging udplog6
AX(config-logging)#service-group udpsg6
The following commands configure the TCP-proxy template, to enable kee-

palive probes:
AX(config-logging)#slb template tcp-proxy logtcp
AX(config-TCP proxy template)#keepalive-probes 4

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
The following commands configure the RAM caching templates:
AX(config-TCP proxy template)#slb template cache logcache
AX(config-ram caching)#min-content-size 20
AX(config-ram caching)#template logging udplog
AX(config-ram caching)#slb template cache logcache6
AX(config-ram caching)#min-content-size 20
AX(config-ram caching)#template logging udplog6
The following commands configure the HTTP templates:

AX(config-ram caching)#slb template http loghttp
AX(config-http)#template logging logtemp
AX(config-http)#slb template http loghttp6
AX(config-http)#template logging logtemp6
The following commands configure the VIPs:

AX(config-http)#slb virtual-server vs 20.20.20.25
AX(config-slb vserver-vport)#source-nat pool snat
AX(config-slb vserver-vport)#service-group sg
AX(config-slb vserver-vport)#template http loghttp
AX(config-slb vserver-vport)#template cache logcache
AX(config-slb vserver-vport)#slb virtual-server vs6 2020::2025
AX(config-slb vserver-vport)#source-nat pool snat6
AX(config-slb vserver-vport)#service-group v6sg
AX(config-slb vserver-vport)#template http loghttp6
AX(config-slb vserver-vport)#template cache logcache6

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Load Balancing for SIP over UDP
SIP Load Balancing
This chapter describes Session Initiation Protocol (SIP) load balancing and
how to configure it.
You can configure load balancing for SIP over UDP or SIP over TCP/TLS.

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 86 shows an example of a SIP load balancing configuration. The
commands to implement this configuration are shown in “Configuring Load
Balancing for SIP over UDP” on page 226.
FIGURE 86 SIP Load Balancing

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Application Layer Gateway Support
In releases earlier than 2.6.0 that support SIP load balancing, ALG support
is automatically enabled for SIP load balancing. In 2.6.1-P1 and later, SIP
ALG support is available only if you enable it.
The status of ALG support does not affect address translation at the IP layer.
Address translation at the IP layer is still performed, if applicable, even if
ALG support is disabled.
Configuring Load Balancing for SIP over UDP

To configure load balancing for SIP over UDP:
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 Mode > Service > Health Monitor.
b. Select Health Monitor on the menu bar.
c. Click Add.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
d. In the Health Monitor section, enter a name for the health monitor.
e. In the Method section, 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.)
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. In the Health Monitor section, enter a name for the health monitor.
c. In the Method section, 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. In the General section, enter a name for the Registrar server.
e. Enter the IP address of the server.
f. In the Port section, 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The steps are the same as the steps for adding the Registrar servers. (See
Figure 90.)
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. In the Service Group section, enter a name for the group.
d. In the Type drop-down list, select UDP.
e. In the Port section, 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.
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 Mode > 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. In the General section, 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
f. In the Port section, 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.
GUI CONFIGURATION EXAMPLE
The following GUI examples show the configuration steps.
(example for Registrar servers)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
(example for other SIP servers)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 90 Config Mode > Service > SLB > Server - Registrar and Proxy
servers added

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 91 Config Mode > Service > Service Group (registrar group)
FIGURE 92 Config Mode > Service > Service Group - groups added

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 93 Config Mode > Service > Template > Application > SIP
FIGURE 94 Config Mode > Service > Template > Application > SIP -
template added

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 95 Config Mode > Service > Virtual Server - Port section
FIGURE 96 Config Mode > Service > Virtual Server - server added
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
Enter this command at the global configuration level of the CLI to
access the configuration level for the template, where the following
commands are available:
registrar service-group group-name
timeout minutes
keep-real-server-ip-if-match-acl acl-id
alg-dest-nat
alg-source-nat

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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.
The keep-real-server-ip-if-match-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 258.)
Header Insert Commands:
client-request-header insert header-name
client-response-header insert header-name
server-request-header insert header-name
server-response-header insert header-name
Use a colon between the header name and the value. To use a blank
space between the header name and the value, use double quotation
marks.
Examples:
header-insert Max-Forwards:15
header-insert “Max-Forwards: 15”
Header Erase Commands:
client-request-header erase header-name [all]
client-response-header erase header-name [all]
server-request-header erase header-name [all]
server-response-header erase header-name [all]
Note: The commands for inserting or erasing information in the SIP header are
applied to each SIP packet before it is sent to the service group. Each
command erases, inserts, or replaces the value in a single header field.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
The commands in the following example implement the SIP load balancing
configuration shown in Figure 86 on page 225.
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-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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Load Balancing for SIP over TCP/TLS

SIP over TCP/TLS enables the AX device to act as a secure SIP proxy for
SIP servers. Figure 97 shows an example of this feature.
FIGURE 97 SIP over TCP / TLS
SIP clients send secure SIP requests over TLS. The requests are addressed
to a VIP configured on the AX device. The AX device forwards the requests
to the SIP servers over TCP. Likewise, when the AX device receives SIP
traffic from the SIP servers, the AX device forwards the traffic to the appro-
priate clients over TLS.
SIP Multiplexing
You can use the AX device to multiplex SIP connections. This is useful in
cases where the SIP servers do not have enough capacity to maintain sepa-
rate connections for each SIP client. Figure 98 shows an example.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 98 SIP Multiplexing
In this example, each SIP server can handle a maximum of 256 client con-
nections. However, there are 1000 SIP clients that use the VIP as their SIP
server.
To enable the SIP servers to be used with this many clients, the connection-
reuse feature is configured on the AX device. The AX device is allowed to
open a maximum of 100 connections to each server, but uses each connec-
tion for multiple clients.
While the AX device is sending a client request on a connection, the con-

nection is in use. However, as soon as the request has been sent, the AX
device frees the connection to be used again. The connection can be used for
the same client or another client. The AX device does not wait for a reply to
the client’s request before freeing the connection. Figure 99 shows an exam-
ple.
FIGURE 99 SIP Connection Reuse

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
In this example, the AX device sends requests for 3 different clients before
receiving the reply to the first request.
To identify the client to which to forward the reply, the AX device examines
the X-Forwarded-For header in the reply.
Note: The operation of connection reuse for SIP over TCP is different from the
operation of connection reuse for HTTP. For HTTP, the AX device does
not free a connection after sending a client’s request. Instead, the AX
device frees the connection only after receiving a response to the request.
AX Requirements for SIP Multiplexing

In addition to the requirements for any SIP over TCP / TLS configuration
(described in the configuration section), the following items are required for
SIP multiplexing:
• Connection-reuse template – Connection-reuse templates have the fol-
lowing options:
• Timeout – Specifies how long a reusable connection can remain idle
before being terminated.
• Limit per server – Specifies the maximum number of connections to
the server. (In Figure 98, this option would be set to 100.)
• Keep-alive connections – Specifies the number of new reusable
connections to open before beginning to reuse the existing connec-
tions for new clients.
• Client IP insertion – When this SIP template feature is enabled, the AX
device inserts an X-Forwarded-For header into the client’s request
before forwarding the request to the SIP server. The header contains the
client’s IP address and client port number. The AX device expects the
server to send back this header, and uses the header to identify the client
to which to send replies from the SIP server.
• Server keepalive (described in “Client Keepalive and Server Keepalive”
on page 242)
Client and Server Requirements for SIP Multiplexing
In order for the AX device to be used as a multiplexer for SIP over TCP/
TLS, the clients and SIP servers must meet certain requirements:
• The SIP clients must be able to send SIP pings.
• The SIP server must be able to reply to SIP pings, with SIP pongs.
• The SIP server must be able to include the X-Forward-For header added
to the client’s request by the AX device, in replies to the client.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Client Keepalive and Server Keepalive

The AX device can send and receive SIP keepalive messages:
• Ping – A SIP ping is a 4-byte message containing a double carriage
return line feed (CRLF).
• Pong – The reply to a SIP ping is called a “pong”. A pong is a 2-byte
message containing a single CRLF.
Client keepalive enables the AX device to reply to SIP pings sent by clients
instead of forwarding them to the SIP server. This feature is applicable
regardless of whether you use the AX device to multiplex SIP connections.
Server keepalive enables the AX device to generate SIP pings and send
them to the server. The AX device uses server keepalive to prevent the reus-
able connections to the server from aging out. If the AX device does not
receive a pong before the connection-reuse timeout expires, the AX device
closes the connection. Server keepalives apply only to configurations that
include connection reuse, such as a configuration that uses the AX device as
a SIP multiplexer.
Figure 100 shows an example of a configuration that uses both SIP keepal-
ive features.
FIGURE 100 SIP Keepalive
Note: If connection reuse is configured, even if client keepalive is disabled, the

AX device will respond to a client SIP ping with a pong.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX Actions if Selection of a Client or SIP Server Fails

You can configure the action the AX device takes if selection of a SIP client
or a SIP server fails. The action can be one of the following:
• Reset the connection. This is the default for client-selection failures and
server-selection failures.
• Drop the SIP message.
• Send a message string.

• Example message string sent to client when server can not be
reached: “504 Server Time-out”
• Example message string sent to server when client can not be
reached: “480 Temporarily Unavailable”
SLB Network Address Translation for SIP over TCP / TLS

SLB Network Address Translation (NAT) is used for SIP over TCP / TLS
load balancing in much the same way SLB NAT is used for load balancing
other types of traffic.
When a client sends a SIP request, the request is addressed to the virtual IP
address (VIP) and protocol port number configured on the AX device for
the SIP servers. The AX device translates the destination IP address and
port of the request from the VIP to the real IP address and port of a SIP
server. The AX device does not change the client IP address or source proto-
col port number.
Likewise, when the AX device receives a SIP packet from a SIP server, the
AX device translates the source IP address and port from the server’s real IP
address and SIP port to the VIP address and port, then sends the packet to
the client.
By default, the AX device also translates the client IP address and protocol
port number where they are used in some other parts of the SIP packet.
However, the AX device does not translate server addresses or protocol port
numbers in the following headers:
• Call-ID header
• X-Forwarded-For header
• Via headers, except for the top Via header

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
You can disable translation in any of the following places in the packet:
• Start line
• Individual headers
• Body
For example, if the client is required to be authenticated before registration,

and the authentication realm is the VIP instead of a domain name, the AX
device must not translate the virtual IP address and port into a real server
address and port in the Authorization header. Otherwise, authentication will
fail.
Configuring SIP over TCP / TLS for SIP Multiplexing

To configure an AX device for secure SIP multiplexing:
• Optionally, configure a health monitor for SIP over TCP.
• Configure a real server for each SIP server. Use the SIP protocol port
number on the server (for example, 5060) as the port number.
Use TCP as the protocol type. Use a Layer 4 TCP health monitor. When
you add the TCP port, the default TCP health monitor is automatically
applied to the port and enabled.
• Configure a service group containing the real servers.
• Configure a SIP template with at least the following options enabled:

• Client IP insertion
• Client keepalive
• Server keepalive
• Configure a connection-reuse template. Set the limit-per-server option

to the maximum number of SIP connections to allow on each SIP server.
• If clients will use SIP over TLS, import the certificates and keys the SIP
server would use to authenticate clients. Configure a client-SSL tem-
plate and add the certificates and keys to the template.
• Configure a virtual server with the IP address to which clients will send
SIP requests. For SIP over TLS Clients, add a protocol port with service
type “sips”. For SIP over TCP Clients, add a protocol port with service
type “sip-tcp”. Bind the port to the service group, and to the SIP and
connection-reuse templates. If a client-SSL template is used, bind the
port to the client-SSL template too.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE GUI
The following figures show examples of the GUI configuration pages for
implementing the SIP multiplexing configuration shown in Figure 98 on
page 240.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 103 Config Mode > Service > Template > Application > SIP
FIGURE 104 Config Mode > Service > Template > Connection Reuse

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 105 Config Mode > Service > SSL Management - import
FIGURE 106 Config Mode > Service > Template > SSL > Client SSL

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 108 Config Mode > Service > SLB > Virtual Server - port section
contains virtual port configured on Virtual Server Port page (above)
USING THE CLI

This section shows the CLI commands that are specific to SIP configura-
tion.
To Configure a SIP over TCP Health Monitor

[no] health monitor monitor-name

Use this command at the global configuration level of the CLI. This com-
mand changes the CLI to the configuration level for the health monitor,
where the following command is available:
[no] method sip tcp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To Configure Real Servers

Use this command at the global configuration level of the CLI. For the
ipaddr, use the SIP server’s real IP address. This command changes the CLI
to the configuration level for the server, where the following command is
available:
port port-num tcp
For the port-num, use the protocol port number on which the SIP server lis-
tens for SIP traffic. This command changes the CLI to the configuration
level for the port, where the following command is available:
[no] healthcheck monitor-name
Use this command to apply the SIP over TCP health monitor to the port.
To Configure a Service Group


mand changes the CLI to the configuration level for the service group,
where the following command is available:
member server-name:port-num
For the server-name, use the name specified in the real server configuration.
For the port-num, use the SIP port number specified in the real server con-
figuration.
To Configure a SIP Template

Use the following commands.
Note: In the current release, the SIP template options described below are valid
only for SIP over TCP/TLS. Other SIP template options, such as header-
insert, header-erase, and so on are valid only for SIP over UDP.
slb template sip template-name

mand changes the CLI to the configuration level for the template, where the
following commands are available.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
insert-client-ip
This command inserts an “X-Forwarded-For: IP-address:port” header into
SIP packets from the client to the SIP server. The header contains the client
IP address and source protocol port number. The AX device uses the header
to identify the client when forwarding a server reply. This option is disabled
by default.
client-keep-alive
This command enables the AX device to respond to SIP pings from clients
on behalf of SIP servers. When this option is enabled, the AX device
responds to a SIP ping from a client with a “pong”. This option is disabled
by default.
Note: If connection reuse is configured, even if client keepalive is disabled, the

AX device will respond to a client SIP ping with a pong.
server-keep-alive seconds
This command specifies how often the AX device sends a SIP ping on each
reusable connection with the SIP server. The AX device silently drops the
server’s pong reply.
If the server does not reply to a SIP ping within the connection-reuse time-
out, the AX device closes the connection. (The connection-reuse timeout is
configured by the timeout command at the configuration level for the con-
nection-reuse template.)
You can specify 5-300 seconds.
failed-client-selection {string | drop}

failed-server-selection {string | drop}
These commands change the AX response when selection of a SIP client or
server fails. By default, the AX device resets the connection. To change the
response when a client can not be reached, use the failed-client-selection
command. To change the response when a SIP server can not be reached,
use the failed-server-selection command.
You can specify one of the following actions:
• string – Send a message string. If the message string contains a blank,
use double quotation marks around the string.
• drop – Drops the traffic.
exclude-translation
{body | header string | start-line}
This command disables translation of the virtual IP address and virtual port
in specific portions of SIP messages:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• body – Does not translate virtual IP addresses and virtual ports in the
body of the message.
• header string – Does not translate virtual IP addresses and virtual ports
in the specified header.
• start-line – Does not translate virtual IP addresses and virtual ports in
the SIP request line or status line.
(For default information, see “SLB Network Address Translation for SIP
over TCP / TLS” on page 243.)
timeout minutes
This command specifies the number of minutes a SIP session can remain
idle before the AX device terminates it. You can specify 1-250 minutes. The
default is 30 minutes.
alg-dest-nat, alg-source-nat
These commands enable SIP ALG support. SIP ALG support is disabled by
default.
To Configure a Connection-Reuse Template
slb template connection-reuse template-name

following commands are available.
limit-per-server number
This command specifies the maximum number of reusable connections per
server port. You can specify 0-65535. 0 means unlimited. The default is
1000.
keep-alive-conn number
This command specifies the number of new reusable connections to open
before beginning to reuse existing connections. You can specify 1-1024
connections.
timeout seconds
This command specifies the maximum number of seconds a connection can
remain idle before it times out. You can specify 1-3600 seconds. The default
is 2400 seconds.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To Configure a Client-SSL Template
Before configuring the template, use the following command to import the
certificates and keys. Use this command at the global configuration level of
the CLI.
[no] slb ssl-load

{certificate file-name | private-key file-name}
[use-mgmt-port]
url
The use-mgmt-port option uses the AX device’s management route table
and management port to communicate with the remote server. Without this
option, the AX device uses the main route table and a data interface to com-
municate with the remote server.
The url specifies the file transfer protocol (tftp:, ftp:, scp:, or rcp:), user-
name (if required), and directory path. You can enter the entire URL on the
command line or press Enter to display a prompt for each part of the URL.
If you enter the entire URL and a password is required, you will still be
prompted for the password. To enter the entire URL:
• tftp://host/file
• ftp://[user@]host[:port]/file
• scp://[user@]host/file
• rcp://[user@]host/file
• http://[user@]host/file
• https://[user@]host/file
• sftp://[user@]host/file
To configure the client-SSL template, use the following commands:

slb template client-ssl template-name
Use this command at the global configuration level of the CLI. The com-
mand changes the CLI to the configuration level for the template. For infor-
mation about the template options, see the AX Series CLI Reference.
To Configure a Virtual Server


Use this command at the global configuration level of the CLI. For the
ipaddr, use the IP address to which clients will send SIP traffic. This com-
mand changes the CLI to the configuration level for the virtual server,
where the following commands are available:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
port port-number sips
port port-number sip-tcp
Use the sips option to add a port for SIP over TLS clients. Use the sip-tcp
option to add a port for SIP over TCP clients. This command changes the
CLI to the configuration level for the virtual port, where the following com-
mands are available:
This command binds a service group to the virtual port.
template sip template-name

template connection-reuse template-name
template client-ssl template-name
These commands bind templates to the virtual port.
CLI Example
The commands in this example implement the SIP multiplexing configura-
tion shown in Figure 98 on page 240, and show SIP SLB statistics.
The following commands access the configuration level of the CLI and con-
figure a SIP over TCP health monitor:
AX>enable
AX#config
AX(config)#health monitor sip-over-tcp
AX(config-health:monitor)#method sip tcp

AX>enable
AX#config
AX(config)#slb server siptls-rs1 10.4.2.1
AX(config-real server)#healthcheck sip-over-tcp
AX(config)#slb server siptls-rs2 10.4.2.2
AX(config-real server)#healthcheck sip-over-tcp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX(config)#slb service-group siptls-sg tcp
AX(config-slb service group)#member siptls-rs1 10.4.2.1:5060
AX(config-slb service group)#member siptls-rs2 10.4.2.2:5060
The following commands configure the SIP template:

AX(config)#slb template sip siptls-tmplt
AX(config-SIP LB template)#insert-client-ip
AX(config-SIP LB template)#client-keep-alive
AX(config-SIP LB template)#failed-client-selection "480 Temporarily Unavaila-
ble"
AX(config-SIP LB template)#failed-server-selection "504 Server Time-out"
AX(config-SIP LB template)#exclude-translation header Authentication
AX(config-SIP LB template)#exit
The following commands configure the connection-reuse template:

AX(config)#slb template connection-reuse siptls-tmplt
AX(config-connection reuse template)#limit-per-server 100
AX(config-connection reuse template)#keep-alive-conn 64
AX(config-connection reuse template)#exit
The following commands import the certificates and keys to use for authen-
ticating SIP clients:
AX(config)#slb ssl-load certificate ca-cert.pem scp:
Address or name of remote host []?192.168.1.1
User name []?admin
Password []?*********
File name [/]?ca-cert.pem
AX(config)#slb ssl-load private-key ca-certkey.pem scp:
User name []?admin
Password []?*********
File name [/]?ca-certkey.pem
AX(config)#slb ssl-load certificate cert.pem scp:
User name []?admin
Password []?*********
File name [/]?cert.pem
AX(config)#slb ssl-load private-key certkey.pem scp:
User name []?admin
Password []?*********
File name [/]?certkey.pem

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands configure the client-SSL template:
AX(config)#slb template client-ssl siptls-tmplt
AX(config-client SSL template)#ca-cert ca-cert.pem
AX(config-client SSL template)#cert cert.pem
AX(config-client SSL template)#key certkey.pem
AX(config-client SSL template)#exit

AX(config)#slb virtual-server siptls-vip 10.1.54.4
AX(config-slb virtual server)#port 5061 sips
AX(config-slb virtual server-slb virtua...)#service-group siptls-sg
AX(config-slb virtual server-slb virtua...)#template sip siptls-tmplt
AX(config-slb virtual server-slb virtua...)#template connection-reuse
siptls-tmplt
AX(config-slb virtual server-slb virtua...)#template client-ssl siptls-tmplt
Displaying SIP SLB Statistics

To display SIP SLB statistics, use the following command:
show slb sip [detail]
The detail option shows statistics separately for each CPU. Without this
option, aggregate statistics are shown for all CPUs.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Disabling Reverse NAT Based on Destination IP Address
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.
FIGURE 109 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Disabling Reverse NAT Based on Destination IP 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.
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] keep-real-server-ip-if-match-acl acl-id
The acl-id specifies an extended ACL ID (100-199).
CLI Example
The commands in this section are applicable to Figure 109.
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)#keep-real-server-ip-if-match-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-0026 - Ver. 2.7.0 11/1/2012
IP NAT for SIP
IP NAT for SIP

The AX device supports IP NAT for SIP. This feature allows clients in a pri-
vate network to make SIP calls to outside SIP servers, without revealing the
IP addresses of the clients to the servers. Dynamic NAT and static NAT are
both supported.
Note: Only the SIP signalling packets are NATted. The media packets are not
NATted.
To configure IP NAT for SIP:

1. Configure a pool, range list, or static inside source NAT mapping, that
includes the real IP address(es) of the inside clients.
2. Enable inside NAT on the interface connected to the inside clients.
3. Enable outside NAT on the interface connected to the external SIP serv-
ers.
CLI Example
The following configuration excerpt uses dynamic NAT.
access-list 1 permit any
!
interface ethernet 3
ip address 171.1.1.1 255.255.255.0
ip nat inside
!
interface ethernet 5
ip address 2.2.2.1 255.255.255.0
ip nat outside
!
ip nat pool xin 2.2.2.100 2.2.2.100 netmask /32
ip nat inside source list 1 pool xin

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Generic TCP-Proxy
The generic TCP-proxy service type provides full TCP-stack service for
load-balanced Layer 7 applications.
The TCP-proxy service type is useful in cases where the standard service
type for an application does not provide a superior user experience. For
example, in a Real Time Streaming Protocol (RTSP) deployment where per-
formance is slow because the server or client enables a large TCP window
size, ACKs are delayed, and so on, using the tcp-proxy service type instead
of the rtsp service type can improve performance.
USING THE GUI
On the Virtual Server Port configuration page, select TCP-Proxy from the
Type drop-down list.
USING THE CLI

To assign the TCP-proxy service type to a virtual port, use the following
command at the configuration level for the virtual server:
[no] port portnum tcp-proxy
CLI Example
The following commands configure the real servers, service groups, and
VIPs for an IPv4/IPv6 RTSP application using the tcp-proxy service type.
These commands configure the real servers:

AX(config)#slb server ipv6 2001::1113

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
These commands configure the service groups:

AX(config)#slb service-group http tcp
AX(config)#slb service-group rtsp tcp
AX(config)#slb service-group ipv6http tcp
AX(config-slb svc group)#member ipv6:80
AX(config)#slb service-group ipv6rtsp tcp
AX(config-slb svc group)#member ipv6:554
These commands configure the VIPs:

AX(config)#slb virtual-server vip-1 10.153.60.200
AX(config-slb virtual server)#port 554 tcp-proxy
AX(config-slb virtual server-slb virtua...)#service-group rtsp
AX(config-slb virtual server)#exit
AX(config)#slb virtual-server vipipv6 2001::9999
AX(config-slb virtual server)#port 554 tcp-proxy
AX(config-slb virtual server-slb virtua...)#service-group ipv6rtsp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Diameter AAA Load Balancing
This chapter describes SLB for the Diameter AAA protocol. Diameter is a
successor to RADIUS that provides security and other enhancements not
supported in RADIUS.
Overview
Diameter load balancing enables the AX device to act as a proxy between
Diameter clients and servers. Figure 110 shows an example.
FIGURE 110 Diameter Load Balancing

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Diameter operates over TCP or SCTP. The AX device terminates the cli-
ent’s Diameter connection, and opens another Diameter connection with the
selected server.
Note: The current release supports Diameter over TCP only.
Clients send Diameter messages, such as authentication requests, to the VIP

configured on the AX device. The AX device uses SLB to select a Diameter
server and forwards the client’s request to the server. The AX device then
forwards the server’s reply to the client.
The clients and real servers can be connected to the AX device on Layer 2
or Layer 3.
Source NAT
Source NAT is required for traffic between the AX device and the Diameter
servers. The AX device establishes a separate connection to each Diameter
server before any client requests arrive. The NAT address(es), consisting of
source IP address and source TCP port, uniquely identify the connections.
Load-Balancing
Diameter load balancing requires the strict round-robin load balancing
method.
Session-ID persistence is automatically enabled for Diameter virtual ports.

After a server is selected for a given client session, all requests for that ses-
sion go to the same real server.
Note: You do not need to configure a session-ID persistence template. Session

persistence is enabled automatically for Diameter virtual ports.
Optionally, you can configure multiple sets of service-group members

(server:port pairs) that differ based on member priority. In this case, the AX
device uses only the members with the highest priority as long as they are
available, and uses lower-priority members only if the high-priority mem-
bers become unavailable.
An additional option allows lower-priority members to temporarily be ele-

vated to high priority to compensate for high-priority members that are
unavailable.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Health Monitoring
You can use the Layer 3 health method (ICMP ping) to test the IP reachabil-
ity of each server. Layer 3 health monitoring is enabled by default.
You do not need to configure any Layer 4 or Layer 7 health monitors on the
AX device for Diameter load balancing. The Diameter protocol includes its
own Layer 7 health method, the Device-Watchdog-Request message. The
AX device periodically sends Device-Watchdog-Request messages to each
Diameter real server. Each server must respond to its message within a con-
figurable number of seconds or the server is marked Down.
Note: You will need to disable Layer 4 health monitoring, which is enabled by
default. You can disable it individually in each server’s configuration, or
create a real port template for Diameter, disable the Layer 4 health moni-
tor in the template, and assign the template to the TCP port in each real
server configuration.
Application Templates
The following types of application templates are applicable to Diameter
load balancing:
• TCP – Contains settings used for TCP connections between the AX
device and Diameter clients and servers.
• Diameter – Contains the Diameter settings. (See “Diameter Parameters”
on page 266.)
Accounting Message Duplication

Optionally, you can configure the AX device to duplicate Accounting-
Request messages and send them to a separate service group. This option is
useful for logging, accounting, and so on.
Session-ID persistence is used to send all duplicate messages for a given cli-
ent’s session to the same server in the service group.
The AX device does not send Accounting-Answer messages in response to

duplicate Accounting-Request messages sent to the duplication service
group.
High Availability
You can use a set of AX devices configured for High Availability (HA) to
provide redundancy for Diameter load balancing. Make sure to enable ses-
sion synchronization (also called “connection mirroring”) on the Diameter
virtual port, to ensure that session-ID persistence is maintained across
failovers. (For a configuration example, see “CLI Example—High Avail-
ability Pair” on page 277.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Diameter Parameters
Note: The Diameter template parameter origin-host-id is not included in HA
configuration synchronization. The other Diameter template parameters
are included in HA configuration synchronization.
Diameter Parameters
The following parameters are configurable in Diameter templates.
Diameter Attribute-Value Pairs

You can configure the following Diameter Attribute-Value Pair (AVP)
options:
• Origin-host – Sets the value of Diameter AVP 264. This AVP can be a
character string and specifies the identity of the originating host for
Diameter messages. Since the AX device acts as a proxy for Diameter,
this AVP refers to the AX device itself, not to the actual clients. From
the Diameter server’s standpoint, the AX device is the Diameter client.
Specify the origin-host in the following format: host.realm
The host is a string unique to the client (AX device). The realm is the
Diameter realm, specified by the origin-realm option (described below).
There is no default.
• Multiple-origin-host – Prepends the AX CPU ID onto the origin-host
string to identify the CPU used for a given Diameter peer connection.
By default, this option is disabled and the CPU ID is not prepended onto
the origin-host string.
The AX device establishes a separate peer connection with each Diame-
ter server on each CPU. The multiple-origin-host option does not enable
or disable this behavior. The option simply shows or hides the CPU ID
in the origin-host string.
• Origin-realm – Sets the value of Diameter AVP 296. This AVP can be a
character string and specifies the Diameter realm from which Diameter
messages, including requests, are originated. There is no default.
• Product-name – Sets the value of Diameter AVP 269. This AVP can be a
character string and specifies the product; for example, “a10dra”. There
is no default.
• Vendor-ID – Sets the value of Diameter AVP 266. This AVP can be a
numeric value and specifies the vendor; for example, “156”. Make sure
to use a non-zero value. Zero is reserved by the Diameter protocol.
There is no default.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Diameter Parameters
• AVP insertion – Specifies custom AVP values to insert into Capabilities-
Exchange-Request messages sent by the AX device to Diameter servers.
For each custom AVP value to insert, you must specify the following
information:
avp-num [mandatory] {int32 | int64 | string} value
• avp-num – Diameter AVP number.
• mandatory – Sets the AVP mandatory flag on. By default, this flag
is off (not set).
• int32 | int64 | string – Specifies the data format of the value to
insert.
• value – Specifies the value to insert.
You can configure up to 6 custom AVP values.
• Customize-CEA – Replaces the AVPs in Capabilities-Exchange-Answer
(CEA) messages with the custom AVP values you configure before for-
warding the messages. By default, this option is disabled.
Load Balancing for Specific Message Codes

By default, Diameter load balancing applies only to the following message
codes (also called “command codes”):
• Accounting-Request (code 271)
• Accounting-Answer (code 271)
• Capabilities-Exchange-Request (code 257)
• Capabilities-Exchange-Answer (code 257)
• Device-Watchdog-Request (code 280)
• Device-Watchdog-Answer (code 280)
• Session-Termination-Request (code 275)
• Session-Termination-Answer (code 275)
• Abort-Session-Request (code 274)
• Abort-Session-Answer (code 274)
• Disconnect-Peer-Request/Disconnect-Peer-Answer (code 282)
The AX device drops all other Diameter message codes by default.
Optionally, you can use the message-code option to enable load balancing
of additional Diameter message codes, on an individual message-code
basis. You can enable load balancing of up to 10 additional message codes.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Diameter Parameters
Timers
You can configure the following Diameter timers:
• Idle timeout – Specifies the number of minutes a Diameter session can
remain idle before the session is deleted. You can specify 1-65535 min-
utes. The default is 5 minutes.
• Session-age – Specifies the absolute limit for Diameter sessions. Any
Diameter session that is still in effect when the session age is reached is
removed from the AX session table. You can specify 1-65535 minutes.
The default is 10 minutes.
• DWR-time – Specifies the maximum number of seconds the AX device
will wait for the reply to a device-watch-dog message sent to a Diameter
server before marking the server Down. You can specify 0-2147483647
milliseconds (ms), in 100-ms increments. The default is 10 seconds.
Accounting-Request Message Duplication

To configure message duplication, configure real servers and the service
group, and configure the following option in the Diameter template:
• Duplicate AVP – Specifies the Accounting-Request messages to dupli-
cate, and the service group to which to send the duplicates. You must
specify the following information:
avp-num pattern service-group
• pattern – String pattern within the message.
• service-group – The duplication service group, which is the service
group to which to send the duplicate messages.
Notes
• To place the message duplication configuration into effect, you must
unbind the Diameter template from the Diameter virtual port, then
rebind it.
• A Diameter template in which message duplication is configured can be
bound to only a single virtual port.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configuration
To configure Diameter load balancing:
1. Configure a source NAT pool containing addresses in the same subnet
as the Diameter servers.
2. Configure the real servers.
3. Configure the service group.
4. (Optional) Configure the real servers and service group for Accounting-
Request message duplication.
5. Configure the Diameter template.
6. Configure the virtual server.
USING THE GUI

To configure a source NAT pool containing addresses in the
same subnet as the Diameter servers:
1. Select Config Mode > Service > IP Source NAT > IPv4 Pool .
2. Enter a name for the pool.
3. In the Start IP Address field, enter the beginning (lowest) IP address in

the range.
4. In the End IP Address field, enter the ending (highest) IP address in the
range.
5. Enter the network mask in the Netmask field.
6. In the Gateway field, enter the default gateway to use for NATted traffic.
7. If using HA, select the HA group from the HA group ID field.
8. Click OK.
To configure the real servers:
1. Select Config Mode > Service > SLB > Server .
2. Enter a name for the server.
3. Enter the IP address of the server.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
4. In the Port section, enter the Diameter port number in the Port field.
5. From the Health Monitor(HM) drop-down list, select blank (none).
6. Click Add.
7. Click OK. The server appears in the real server table.
8. For each additional server, click Add and repeat the steps above.
To configure the service group:
1. Select Config Mode > Service > SLB > Service Group .
2. Enter a name for the service group.
3. In the Algorithm drop-down list, select Round Robin Strict.
4. (Optional) To enable the Min Active Members option, select the check-
box.
5. In the Server section, select the server from the Server drop-down list.
6. Enter the Diameter port number in Port field and click Add.
7. Click OK.
8. Repeat the steps above for each server.
(Optional) To configure the real servers and service group for

Accounting-Request message duplication:
Use the same steps as those for configuring the real servers and service
group above. Make sure to also specify the duplication service group in the
Diameter template.
To configure the Diameter template:

1. Select Config Mode > Service > Template > Application >
Diameter .
3. Enter the template values applicable to your deployment. (See “Diame-

ter Parameters” on page 266.)
4. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
To configure the virtual server:
1. Select Config Mode > Service > SLB > Virtual Server .
2. Enter a name for the virtual server.
3. In the IP address field, enter the virtual IP (VIP) address. This is the IP
address to which Diameter clients will send requests.
4. If using HA, select the HA group from the HA Group drop-down list.
5. In the Port section, click Add. The Virtual Server Port page appears.
6. From the Type drop-down list, select Diameter.
7. Enter the Diameter port number in the Port field.
8. Select the service group from the Service Group drop-down list.
9. Select Enabled next to HA Connection Mirror.
10. From the Source NAT Pool drop-down list, select the source NAT pool.
11. From the Diameter drop-down list, select the Diameter template.
USING THE CLI

1. To configure the source NAT pool, use the following command at the
global configuration level of the CLI:
ip nat pool pool-name
start-ipaddr end-ipaddr
netmask {subnet-mask | /mask-length}
[gateway ipaddr]
[vrid {num | default}]
[ha-group-id group-id [ha-use-all-ports]]
The start-ipaddr specifies the beginning (lowest) address in the pool.
The end-ipaddr specifies the ending (highest) address in the pool. The
pool address(es) must be in the same subnet as the AX interface con-
nected to the Diameter servers.
For information about the other options, see the AX Series CLI Refer-
ence or AX Series System Configuration and Administration Guide.


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
server, where you can use the following command to add the TCP port
to the server:
port port-num tcp
The port-num specifies the protocol port number; for example, 3868
(the default Diameter protocol port).
level for the port. At this level, use the following command to disable
the Layer 4 health monitor:
no health-check
Instead, the AX device uses Diameter Device-Watchdog-Request mes-
sages to test the health of the Diameter protocol on the servers.

method round-robin-strict
This command sets the load-balancing method required for Diameter
load balancing.
member server-name:portnum [priority num]
anced. Use the same port number specified in the server configuration in
step 2. Repeat the command for each real server.
The priority num option specifies the preference for using this server
and port. You can specify 1-16. The highest priority value is 16 and the
lowest is 1. The default is 1.
Normally, only the highest-priority members are used. Lower-priority
members backups and are used only if the active members become
unavailable. Optionally, you can use the following command to specify
a minimum number of active members that are required. In this case, the
AX device uses lower-priority servers even if some primary servers are
still up.
[no] min-active-member num [dynamic-priority]
The num option specifies the minimum number of primary servers that
can still be active (available), before the backup servers are used. You
can specify 1-63. There is no default.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
The dynamic-priority option helps ensure that the minimum number of
high-priority servers is maintained, by temporarily increasing the prior-
ity of lower-priority servers if needed. This option is disabled by default.
4. To configure Accounting-Request message duplication, use the follow-

ing commands to configure the real servers and service group:
port port-num tcp
no health-check
For information, see the following:
• “Accounting Message Duplication” on page 265
• “Diameter Parameters” on page 266
5. To configure the Diameter template, use the following commands:

slb template diameter template-name
This command changes the CLI to the configuration level for the tem-
plate, where the following commands are available:
origin-host host.realm
multiple-origin-host
origin-realm string
product-name string
vendor-id num
avp avp-num [mandatory] {int32 | int64 | string}
value
customize-cea
message-code num
idle-timeout minutes
session-age minutes
dwr-time ms
duplicate avp-num pattern service-group
For information, see “Diameter Parameters” on page 266.
6. To configure the virtual server and virtual port, use the following com-
mands:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
to the server:
port port-number diameter
virtual port.
Use the following command to bind the virtual port to the source NAT
pool:
source-nat pool pool-name
Use the following command to bind the virtual port to the Diameter tem-
plate:
template diameter template-name
Use the following command to bind the virtual port to the service group:
7. To verify and monitor Diameter load balancing operation, use the fol-
lowing commands:
show slb diameter [detail]
show slb server server-name portnum detail

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
CLI EXAMPLE—BASIC CONFIGURATION ON SINGLE AX DEVICE
The commands in this example configure the Diameter load-balancing

deployment shown in Figure 110 on page 263.
The following command configures the source NAT pool:

AX(config)#ip nat pool snat.1 20.20.20.251 20.20.20.251 netmask /24

AX(config)#slb server diameter-rs1 20.20.20.1
AX(config-real server-node port)#no health-check
The following commands configure the service group. In this example,

diameter-rs3 is a backup.
AX(config)#slb service-group sg-tcp3868 tcp
AX(config-slb service group)#method round-robin-strict
AX(config-slb service group)#member diameter-rs1:3868 priority 1
The following commands configure the Diameter template:

AX(config)#slb template diameter diameter1
AX(config-diameter template)#origin-host 2diameter.a10com
AX(config-diameter template)#origin-realm a10com
AX(config-diameter template)#product-name a10dra
AX(config-diameter template)#vendor-id 156
AX(config-diameter template)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
The following commands configure the VIP:
AX(config)#slb virtual-server vip-diameter.1 10.10.10.101
AX(config-slb virtual server)#port 3868 diameter
AX(config-slb virtual server-slb virtua...)#source-nat pool snat.1
AX(config-slb virtual server-slb virtua...)#template diameter diameter1
AX(config-slb virtual server-slb virtua...)#service-group sg-tcp3868
CLI EXAMPLE—ACCOUNTING-REQUEST MESSAGE DUPLICATION
The following commands configure an additional set of real servers and a

service group for duplicate Accounting-Request messages:
AX(config)#slb server diameter-acr-dup1 20.20.20.4
AX(config)#slb server diameter-acr-dup2 20.20.20.5
AX(config)#slb service-group diameter-duplicate-group tcp
AX(config-slb service group)#method round-robin-strict
AX(config-slb service group)#member diameter-acr-dup1:3868
AX(config-slb service group)#member diameter-acr-dup2:3868
The following commands add the duplicate option to the Diameter tem-
plate:
AX(config)#slb template diameter diameter1
AX(config-diameter template)#duplicate 30 “acct” diameter-duplicate-group
This option duplicates Accounting-Request messages with AVP 30 that con-

tain the string “acct”, and sends the duplicate messages to service group
“diameter-duplicate-group”.
The duplicate service group does not need to be bound to the Diameter vir-
tual port. Instead, the duplicate option in the Diameter template takes care
of this.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
CLI EXAMPLE—HIGH AVAILABILITY PAIR
The following commands configure global HA parameters on a pair of AX
devices. These parameters are standard for all HA deployments.
The following commands configure global HA parameters on the first AX

device (AX-1):
AX-1(config)#ha group 1 priority 50
AX-1(config)#ha interface ethernet 1 no-heartbeat
AX-1(config)#ha interface ethernet 3
AX-1(config)#ha conn-mirror ip 30.30.30.2
AX-1(config)#ha preemption-enable
The following commands configure global HA parameters on the second

AX device (AX-2):
The ha group command specifies the HA group. Use the same HA group
ID on each AX device. Use the priority values to specify the AX device to
use as the Active device by default.
The ha interface commands specify the interfaces used to exchange HA-

related information between AX devices.
The ha conn-mirror command specifies the IP address on the other AX

device, to which to send session synchronization information.
The ha preemption-enable command enables HA failover to be triggered

by configuration changes. (This is optional.)
The following commands enable HA session synchronization on the Diam-

eter virtual port. Session synchronization is required to ensure that the same
server continues to be used for all traffic for a given session.
AX(config)#slb virtual-server vip-diameter.1
AX(config-slb virtual server)#port 3868 diameter
AX(config-slb virtual server-slb virtua...)#ha-conn-mirror
For more information, see the “High Availability” chapter in the AX Series
System Configuration and Administration Guide.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 175.
• 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 also supports STARTTLS acceleration and encryption.

See “STARTTLS for Secure SMTP” on page 299.
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-0026 - Ver. 2.7.0 11/1/2012
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 789.
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. 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 the certificate location:
• Local – The file is on the PC you are using to run the GUI, or is
on a PC or server in the local network.
• Remote – The file is on a remote server.
d. Select the format of the certificate from the Certificate Format drop-
down list.
e. If you selected Local, click Browse next to the Certificate Source
field and navigate to the location of the certificate.
If you selected Remote:
– To use the management interface as the source interface for the
connection to the remote device, select Use Management Port. Oth-
erwise, the AX device will attempt to reach the remote server
through a data interface.
– Select the file transfer protocol: HTTP, HTTPS, FTP, TFTP, RCP,
or SCP.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
– In the URL field, enter the directory path and filename.
– If needed, change the protocol port number n the port field. By
default, the default port number for the selected file transfer proto-
col is used.
– In the User and Password fields, enter the username and password
required for access to the remote server.
f. Click Open. The path and filename appear in the Source field.
g. If applicable, repeat the steps above for the private key.
h. Click OK. The certificate and key appear 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 111 Configure > Service > SSL Management - Import (for the
certificate)
FIGURE 112 Configure > Service > Template > SSL > Client SSL
USING THE CLI

1. To import a certificate and key, use the following commands at the
global Config level of the CLI:
slb ssl-load certificate file-name url
slb ssl-load private-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-0026 - Ver. 2.7.0 11/1/2012
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:
2. To configure a client SSL template, use the following commands:

cert cert-name
Enter this command at the configuration level for the client SSL tem-
plate.
key key-name [passphrase passphrase-string]
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:
User name []?axadmin
Password []?*********
File name [/]?sslcert1.crt
AX(config)#slb ssl-load private-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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 280.)
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 175.)
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.
Note: If traffic between the servers and AX device also will be encrypted, you
also need to configure a server-SSL template and bind it to the virtual
port. In configurations that use both client-SSL and server-SSL, use the
HTTPS/SSL port number in the real server configuration.
If only client-SSL is used, use the HTTP port number in the real server
configuration. Use the HTTPS/SSL port number in the virtual server con-
figuration.
Beginning in AX Release 2.4.x, server-SSL without client-SSL is sup-
ported. However, in this case, the service type of the virtual port must be
HTTP, not HTTPS.
Note: The AX device allocates processing resources to HTTPS virtual ports

when you bind them to an SSL template. This results in increased CPU
utilization, regardless of whether traffic is active on the virtual port.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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 175.
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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 113 Configure > Service > SLB > Server

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 114 Configure > Service > SLB > Service Group

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 115 Configure > Service > SLB > Virtual Server

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 116 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:
3. To configure HTTP template options, see “HTTP Options for SLB” on

page 175.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
4. To configure a virtual server and HTTPS virtual port, use the following
commands:
port port-number https
template http 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:80
AX(config-slb service group)#member HTTPS2:80

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-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 280.)
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:
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 117 Configure > Service > SLB > Server

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 118 Configure > Service > SLB > Service Group

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 119 Configure > Service > SLB > Virtual Server

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 120 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-0026 - Ver. 2.7.0 11/1/2012
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
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 121 shows an example of the STARTTLS feature.
FIGURE 121 STARTTLS

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 122 STARTTLS Domain Switching

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
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 291.)
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 section appears.
4. In the SMTP section, 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. In the Client Domain Switching section, 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-0026 - Ver. 2.7.0 11/1/2012
To configure a virtual server for STARTTLS (step 6 above):
1. Select Configure > Service > SLB.
3. Click Add.
4. In the General section, 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. In the Port section, click Add. The Virtual Server Port section
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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 123 Config Mode > Service > Template > Application > SMTP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 124 Config Mode > Service > SLB > Virtual Server - Port section
USING THE CLI

1. To import a certificate and its key, use the following commands at the
slb ssl-load certificate file-name url
slb ssl-load private-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-0026 - Ver. 2.7.0 11/1/2012
2. To configure a client SSL template, use the following commands:

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
The disable option of the starttls command disables STARTTLS sup-
port on the VIP that uses the SMTP template.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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]
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 private-key tlscertkey.pem ftp:
Password []?*********
File name [/]?tlscertkey.pem

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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
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-0026 - Ver. 2.7.0 11/1/2012
Overview
SNMP-based Load Balancing
This chapter describes SNMP-based load balancing.
Overview
You can use the results of SNMP queries to real servers to dynamically set
the weight values of the servers. When used along with a a load-balancing
method that includes server weight in the selection process, this option
allows servers to be selected based on metrics such as the following:
• CPU utilization
• System memory utilization
• Connection capacity
• Hard drive utilization
Requirements
• External health monitor – SNMP-based load balancing uses an external
health monitor (a script) to periodically send SNMP queries to each of
the real servers. The script must return a numeric value. The following
values are valid for SNMP-based load balancing:
• 0-124 – Server is up. The server’s weight value (1-100) is dynami-
cally changed to the value returned by the script. If the script returns
0, the value is set to 1. If the script returns value 101-124, the value
is set to 100.
• -1 – Server is down.
• 125 or higher – Server is down.
Exit codes 1 and 2 are reserved. Please make sure the script does not
have general errors.
When configuring the external health monitor on the AX device, make
sure to use the preference option. This option enables the server weight
values to be dynamically set based on the values returned by the health
monitor’s script.
• Weighted load-balancing method – The server weight is used for server
selection only if the service group uses either of the following load-bal-
ancing methods:
• Weighted-least-connection
• Weighted-rr (weighted round robin)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Weight-based Load Balancing
When a weight-based load-balancing method is used, the AX device selects
servers with higher weight values more often than servers with lower
weight values.
For example, assume the SNMP-based health check of a group of 4 real

servers results in the following dynamically assigned weight values:
• Server1 – weight 1
The AX device selects the servers s for new connections as follows:

• Server1 – 1 connection
• Server1 – 0 connections

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
...
The pattern of selection repeats until the server weight values are changed
based on the next health check.
Sample External Health Monitor Script for SNMP-based Load

Balancing
Here is an example of a Shell script for SNMP-based load balancing. This
script uses the results from queries to the UCD-SNMP-MIB MIB module
from U.C. Davis.
#!/bin/sh
dst="$HM_SRV_IPADDR"
#dst="$HM_SRV_IPADDR:$HM_SRV_PORT"
# Community String
community="public"
# UCD-SNMP-MIB::extResult.1
oid=".1.3.6.1.4.1.2021.8.1.100.1"
function check_value {
echo "$output"
value=`echo $output | sed 's/INTEGER: //'`
echo "value" = "$value"
if [[ "$value" =~ "^[[:digit:]]*$" ]]; then
# echo "digit string"

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
if [ $value -ge 0 -a $value -lt 125 ]; then
echo "Good"
exit $value
fi
fi
}
echo "/usr/bin/snmpget -v2c -c \"$community\" -Ov \"$dst\" $oid"

output=$(/usr/bin/snmpget -v2c -c "$community" -Ov "$dst" $oid)
if [ 0 != $? ]; then
exit -1
fi
check_value
# success
echo "Mark server down"
exit -1
Configuration
To configure SNMP-based load balancing:
1. Create a script such as the one shown above.
2. Import the script onto the AX device.
3. Configure an external health monitor to use the script. Make sure to use
the preference option.
4. Configure the service group to use a weighted load-balancing method.
Note: These steps apply specifically to SNMP-based load balancing. The other
configuration steps standard to all types of load balancing are also
required: configure the real servers and add them to a service group, con-
figure the virtual server (VIP), bind the service group to a virtual port on
the VIP, and so on.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
USING THE GUI
To import an external health monitor script onto the AX device:

1. Select Config Mode > Service > Health Monitor > External Program.
2. Click Add.
3. Enter a name and description in the Name and Description fields,

respectively.
4. Copy-and-paste the script into the Definition field.
5. Click OK.
To configure an external health monitor that uses the script:

1. Select Config Mode > Service > Health Monitor > Health Monitor.
2. Click Add.
3. Enter a name in the Name field.
4. Select External next to Method.
5. Select the script from the Program drop-down list.
6. Select the Preference checkbox.
7. Click OK.
To set the service group to use a load-balancing method based

on server weight:
On the configuration page for the service group, select one of the following
from the Algorithm drop-down list:
• Weighted Least Connection
• Weighted Round Robin

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
USING THE CLI

1. To import an external health monitor script onto the AX device, use the
following command at the global configuration level of the CLI:
health external
import [use-mgmt-port] [description] url
2. To configure an external health monitor that uses the script, use the fol-
lowing command at the global configuration level of the CLI:
This command changes the CLI to the configuration level for the moni-
tor, where the following command is available:
[no] method external [port port-num]
program script-name [arguments argument-string]
preference
3. To set the service group to use a load-balancing method based on server

weight, use the following command at the configuration level for the
service group:
[no] method
{weighted-least-connection | weighted-rr}
Verifying that All Servers Are Up

To verify that all servers are up, use the following command:
show health stat
Displaying Dynamically Assigned Server Weights

To display the current weight values of the servers, use the following com-
mand:
show running-config | section slb server

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
SSL Intercept
This chapter describes the SSL Intercept feature and how to configure it.
Note: SSL Intercept also is referred to as “SSL Forward Proxy”.
Overview
SSL Intercept is an AX solution that allows third-party traffic inspection
devices to examine encrypted traffic “in the clear”. The traffic inspection
devices can be firewalls, Data Loss Prevention (DLP) appliances, email
protection systems, and so on.
To perform SSL Intercept, a pair of AX devices is placed on either side of

the traffic inspection devices.
One of the inside AX devices intercepts traffic from inside clients, decrypts
the traffic, and sends it to the traffic inspection devices. If the traffic inspec-
tion devices allow the traffic, they forward the traffic to the external AX
device. The external AX device re-encrypts the traffic before sending it to
its destination.
Note: You can deploy a single AX device on either side of the traffic inspection
devices or, for redundancy, you can deploy an HA / VRRP-A set on either
side.
Figure 125 shows an example of an SSL Intercept deployment.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 125 SSL Intercept
In this example, an inside client sends an email using an external, web-

based email service.
The inside AX device uses SLB load balancing to select a traffic inspection
device, decrypts the email, and sends the decrypted email to the selected
traffic inspection device.
If the policies on the traffic inspection device permit the email to be sent,
the external AX device re-encrypts the email and sends it to the external
email server.
Optionally, you can attach a protocol analyzer to the AX device and use the
traffic mirroring feature to send the unencrypted traffic to the traffic ana-
lyzer as well. (This is not shown in the figure.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
SSL Operation
Figure 126 shows a more detailed view of the SSL Intercept process.
FIGURE 126 SSL Intercept (walkthrough)
This figure shows the process for SSL Intercept:

1. Client sets up an SSL connection with the inside AX device, and sends
an encrypted request. In this example, the client’s request consists of an
email to be sent using an external email service.
2. Inside AX device selects a traffic inspection device, decrypts the

request, and sends the request to the traffic inspection device.
3. Traffic inspection device inspects request data. In this example, the traf-
fic inspection device allows the traffic and forwards it to the external
AX device.
4. External AX device encrypts the request and sends it to the external

server.
5. Server sends encrypted reply.
6. External AX device decrypts reply and sends it back though the same
traffic inspection device.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
7. If the reply traffic is allowed by the traffic inspection device, the reply is
forwarded to the inside AX device.
8. The inside AX device encrypts the reply and sends it to the client.
SSL Operation on Inside AX Device
The inside AX device performs the following SSL operations for SSL Inter-
cept:
• Negotiates SSL sessions with inside clients
• Decrypts client traffic before sending the traffic to a traffic inspection

device
From the inside client’s perspective, the SSL session is directly between the
client and the external server. However, the SSL session is actually between
the inside AX device and the client.
SSL Intercept requires inside client devices to trust the credentials of the
AX device. Typically, this is accomplished by importing the same self-
signed certificate and private key onto the inside AX device that are
installed on other inside resources that need to be trusted by clients. In the
client browser certificate store, the self-signed certificate functions as a CA-
signed certificate.
The inside AX device uses the certificate during the SSL handshake with
inside clients, as shown in Figure 127 on page 319.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 127 SSL Operation on Inside AX Device
As shown in this example:

1. The client sends a request to set up an SSL session with the external
server (not shown).
2. The inside AX device presents the enterprise’s self-signed certificate to

the client.
If the client browser’s certificate store contains a copy of the self-signed
certificate, the client is able to trust the device at the other end of the ses-
sion (the inside AX device) and allows the SSL session to be set up.
Server Name Extension Support

The AX device supports the Server Name Indication (SNI) extension for
TLS. The SNI extension enables servers that manage content for multiple
domains at the same IP address to use a separate server certificate for each
domain.
In an SSL Intercept deployment, SNI support allows multiple self-signed

certificates to be used. In this case, during configuration, you can map each
certificate to the domain name of an external resource accessed by inside
clients.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
(For more information, see “Support for TLS Server Name Indication” on
page 818.)
SSL Operation on Outside AX Device
The outside AX device performs the following SSL operations for SSL
Intercept:
• Negotiates SSL sessions with external servers
• Decrypts traffic from external servers before sending the traffic to the
traffic inspection devices
• Encrypts client requests before sending them to external servers
Packet Flow for SSL Intercept
Figure 128 shows a more detailed example of the packet flow for SSL Inter-
cept.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 128 SSL Intercept Packet Flow
Laptop AX AX
Firewall
Server
Encrypted Zone Clear Text Zone Encrypted Zone
SYN
SYN/ACK
ACK
Client-Hello
1
SYN
SYN/ACK
ACK
Client-Hello
Server-Hello
(Server Cert – Public Key
Signed by well known CA)
Server-Hello SSL-Handshake Messages
(Server Cert + 2 + Finished
Local Public Key +
Signed by Local CA) RST
SSL-Handshake
Messages
+ Finished
Encrypted
Application Data 3
Clear Text 4
Application Data SYN
SYN/ACK
ACK
Client-Hello
SSL Handshake
messages +
Finished
Encrypted
Application Data
5 Encrypted Application
Response
6 Clear Text
Encrypted
Application Response
Application Response
If the certificate exist in cache, send it to client and

move to (2). Otherwise, establish SSL connection Data Decrypted and sent in clear text through
1 3
with the remote server and get the certificate from firewall
the remote server
SSL-Reverse-Proxy:
4 New SSL session initiated with remote server. Data
Extract header information from server certificate. encrypted and sent to remote server
Change Issuer and the Public Key as exist in Client-
2 SSL-Template. Resign the new certificate using the 5 Response is decrypted and sent through firewall
CA-Private Key as exist in the Client-SSL-Template.
Send the reconstructed Server-Hello to client 6 Response is encrypted again and sent to the client

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configuration
This section describes the configuration items required for SSL Intercept
and gives procedures for configuring them.
For configuration examples, see “Configuration Example” on page 337.
Virtual Ethernet Interfaces
The IP interfaces on the AX device are configured as Virtual Ethernet (VE)

interfaces.
VE interfaces on outside AX devices:

• VE 10 – Connects the outside AX devices to the Internet
• VE 15 – Connects the outside AX devices to traffic inspection device

PSG1
• VE 16 – Connects the outside AX devices to traffic inspection device
PSG2
VE interfaces on inside AX devices:

• VE 20 – Connects the inside AX devices to the inside clients
• VE 15 – Connects the inside AX devices to traffic inspection device

PSG1
• VE 16 – Connects the inside AX devices to traffic inspection device
PSG2
The outside AX devices, the inside AX devices, and the traffic inspection
devices all are in the same subnet.
Note: For simplicity, the management interfaces are not shown.
Promiscuous VIP Support

On each VE on the inside and outside AX devices, promiscuous VIP
support is enabled. This option is required for wildcard VIPs.
When you enable promiscuous VIP support on a VE, the option is automat-
ically enabled on each Ethernet data port contained in the VE.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Wildcard VIPs
SSL Intercept uses wildcard VIPs. A wildcard VIP is a VIP with one of the
following addresses:
• 0.0.0.0 (IPv4)
• :: (IPv6)
A wildcard VIP can intercept traffic for any destination IP address.

Figure 129 shows how wildcard VIPs are used in SSL Intercept.
FIGURE 129 SSL Intercept - wildcard VIPs
Each pair of AX devices has the following wildcard VIPs:

• Outbound – Intercepts traffic sent from the inside network to the Inter-
net.
• Inbound – Intercepts traffic sent from the Internet to a client on the
inside network.
Traffic Flow Through Wildcard VIPs
Figure 129 shows the following traffic flow through the wildcard VIPs:
1. Inside client 172.16.242.36 sends encrypted request to mail.exam-
ple.com.
2. The outbound wildcard VIP on the inside AX device intercepts the SSL
request. The AX device decrypts the traffic and sends it to a traffic
inspection device.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
3. The traffic inspection device sends the approved traffic in the clear to an
outside AX device.
4. The outbound wildcard VIP on the outside AX device intercepts the

traffic. The AX device encrypts it, and sends it to the server.
5. The server sends an encrypted reply.
6. Encrypted response traffic from the server is decrypted by the outside

AX device and sent to the traffic inspection device.
7. The traffic inspection device sends the approved reply in the clear to the
inside AX device.
8. The decrypted response traffic from the traffic inspection device is

encrypted and sent to the client.
The following subsections describe each wildcard VIP in detail.
Wildcard VIPs on Inside AX Devices

The following subsections describe the wildcard VIPs on the inside AX
devices.
Inside AX Device – Outbound VIP

The outbound VIP on the inside AX devices intercepts traffic from inside
clients. The following virtual ports are configured on this VIP:
• 443 (HTTPS) – Intercepts SSL-encrypted traffic from clients.
Port 443 is bound to a service group that contains the paths through the
traffic inspection devices to the outside AX devices. (See “Service
Groups” on page 327.)
Destination NAT is disabled. The AX device does not change the source
or destination IP addresses of the traffic. However, port translation is
enabled. Port translation is required because the AX device needs to
change the destination protocol port from 443 to the port number on
which the traffic inspection devices listen for traffic decrypted by the
AX device.
The SSL options required for SSL Intercept are configured in a client-
SSL template that is bound to this virtual port. (See “Configure the Cli-
ent-SSL Template” on page 331.)
• 0 (TCP), 0 (UDP), and 0 (Others) – These wildcard ports intercept all
client traffic other than SSL-encrypted traffic. The TCP port intercepts
all other TCP traffic from clients. Likewise, the UDP port intercepts all
other UDP traffic from clients. The Others port intercepts client traffic
of types other than those listed above.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
The TCP and Others wildcard ports are bound to a TCP service group
that contains the paths through the traffic inspection devices to the out-
side AX devices. Likewise, the UDP wildcard port is bound to a UDP
service group that contains the paths through the traffic inspection
devices to the outside AX devices.
Destination NAT is disabled. Port translation also is disabled.
Inside AX Device – Inbound VIP

The inbound VIP on the inside AX devices intercepts inbound traffic
allowed by the traffic inspection devices. The following virtual ports are
configured on this VIP: 0 (TCP), 0 (UDP), and 0 (Others).
On each of these virtual ports, destination NAT is disabled. Port translation

also is disabled.
These virtual ports do not use a service group, as explained below.
Each of these ports also uses the following options:

• Use-rcv-hop-for-resp – This option sends reply traffic for the session
back through the same traffic inspection device to the outside AX
devices.
• Use-default-if-no-server – This option overrides the default AX behav-
ior when selection of a service-group member fails. By default, the AX
device drops the traffic. However, since these ports do not use a service
group, this option is required to change the default behavior in this case
is to forward the traffic at Layer 3. Thus, inbound traffic that is inter-
cepted by these virtual ports is forwarded to clients at Layer 3.
Wildcard VIPs on Outside AX Devices

The following subsections describe the wildcard VIPs on the outside AX
devices.
Outside AX – Outbound VIP

The outbound VIP on the outside AX devices intercepts outbound traffic
allowed by the traffic inspection devices. The following virtual ports are
configured on this VIP:
• 8080 (HTTP) – Intercepts decrypted client traffic allowed by the traffic
inspection devices.
Port 8080 is bound to a service group that contains a member for the
gateway router to the Internet. The service group member consists of the
router’s IP address and protocol port 443.
Destination NAT is disabled. Port translation is enabled. Port translation
is required because the AX device needs to change the destination proto-

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
col port to 443 before sending the re-encrypted traffic to the gateway
router.
The SSL option required for SSL Intercept is configured in a server-SSL
template that is bound to this virtual port. (See “Configure the Server-
SSL Template” on page 335.)
• 0 (TCP), 0 (UDP), and 0 (Others) – These wildcard ports intercept all
client traffic other than SSL-encrypted traffic. The TCP port intercepts
all other TCP traffic from clients. Likewise, the UDP port intercepts all
other UDP traffic from clients. The Others port intercepts client traffic
of types other than those listed above.
The TCP and Others wildcard ports are bound to a TCP service group
that contains a member for the gateway router to the Internet. Likewise,
the UDP wildcard port is bound to a UDP service group that contains a
member for the gateway router .
Destination NAT is disabled. Port translation also is disabled.
Each of these ports also uses the use-rcv-hop-for-resp option, which
sends reply traffic for the session back through the same hop.
Outside AX – Inbound VIP

The inbound VIP on the outside AX devices intercepts inbound traffic from
the Internet. The following virtual ports are configured on this VIP:
0 (TCP), 0 (UDP), and 0 (Others).
On each of these virtual ports, destination NAT is disabled. Port translation

also is disabled.
The TCP and Others ports are bound to a TCP service group that contains
members for the paths through the traffic inspection devices. Likewise, the
UDP port is bound to a UDP service group that contains members for the
paths through the traffic inspection devices.
Access Control Lists

You can apply an Access Control List (ACL) to a wildcard VIP. The ACL
controls the IP addresses and protocol ports that are allowed to access the
VIP.
The AX device can have only one wildcard VIP that does not have an ACL
applied to it. The wildcard VIPs in the example deployment in this chapter
all use ACLs.
ACLs on outside AX device’s wildcard VIPs:

• Outbound – Permits IP traffic from IP addresses in the range
172.16.24.32-63 to any destination IP address. This is the client address
range.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
• Inbound – Permits IP traffic from any source IP address to destination IP
addresses in the range 172.16.24.32-63.
ACLs on inside AX device’s wildcard VIPs:

• Outbound – Denies traffic from any IP address in the range
172.16.24.32-63 to host address 172.16.242.33, which is the floating IP
address used by VRRP-A in the sample deployment.
Permits traffic from addresses in the range 172.16.24.32-63 to any desti-
nation.
• Inbound – Permits IP traffic from any source IP address to destination IP
addresses in the range 172.16.24.32-63. This is the client address range.
How Non-matching Traffic Is Handled

The AX device handles traffic that does not match the ACL as follows:
• If the AX device’s configuration contains a wildcard VIP that does not
use an ACL, the traffic is handled by that wildcard VIP. (The configura-
tion can contain one wildcard VIP that does not use an ACL. The AX
device does not support more than one wildcard VIP without an ACL.)
• If the configuration does not contain a wildcard VIP with no ACL, the
traffic is routed at Layer 3.
Service Groups
The sample deployment in this chapter uses the following service groups.
Note: The service groups for the traffic inspection devices contain members that
represent the paths through the traffic inspection devices. When you cre-
ate the real server configuration for a traffic inspection device, use the IP
address of the AX interface on the other side of the traffic inspection
device. Do not use the IP address of the traffic inspection device itself.
Service Groups on Inside AX Devices:

• TCP and UDP service groups that each contain members that consist of
the following:
• Name of a real server configuration that consists of the IP address of
the outside AX device on the other end of the traffic inspection
device
• Port 0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Service Groups on Outside AX Devices:
• TCP service group containing a member that consists of the default
gateway’s IP address and port 443.
• TCP and UDP service groups that each contain a member that consists
of the default gateway’s IP address and port 0.
• TCP and UDP service groups that each contain members that consist of
the following:
• Name of a real server configuration that consists of the IP address of
the outside AX device on the other end of the traffic inspection
device
• Port 0
Configuration Tasks
To configure SSL Intercept, perform the following tasks.
Note: Some configuration tasks differ depending on whether the AX device is

on the external side of the firewalls or on the inside side. For example, the
AX device on the external side of the firewalls uses a client-SSL template,
whereas the AX device on the inside side of the firewalls uses a server-
SSL template.
Configuration on Inside AX Devices

Perform the following steps on the AX device that is connected to the inside
side of the traffic inspection devices. This is the side that connects to the
Internet.
1. Enable promiscuous VIP mode on the Ethernet interfaces connected to
the firewalls. This is required by the wildcard VIPs.
2. Import the root CA-signed certificate for the content servers, and the
certificate’s private key. This certificate must be one that is trusted by
inside clients.
3. Configure the client-SSL template. The following options are required:

• Enable SSL Intercept support.
• Add the root certificate for your content servers.
• Add the root certificate’s private key.
4. Create real server configurations for the paths through the traffic inspec-
tion devices, and add them to TCP and UDP service groups.
5. Configure the wildcard VIPs.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
GUI Configuration
Configuration on Outside AX Devices
Perform the following steps on the AX device that is connected to the
external side of the firewalls. This is the side that connects to servers.
1. Enable promiscuous VIP mode on the Ethernet interfaces connected to
the firewalls. This is required by the wildcard VIPs.
2. Configure the server-SSL template. The option to enable SSL Intercept

support is required.
3. Create real server configurations for the paths through the traffic inspec-
tion devices, and add them to TCP and UDP service groups.
4. Create a real server configuration for the default gateway router to the
Internet. Create a separate service groups for ports 443, TCP port 0, and
UDP port 0.
5. Configure the wildcard VIPs.
GUI Configuration
For GUI configuration steps for SSL Intercept, see the SSL Intercept
Deployment Guide from A10 Networks.
CLI Configuration
The following sections show the CLI syntax for configuring SSL Intercept.
Configuring the Inside AX Devices

This section shows the CLI syntax for configuring SSL Intercept on the out-
side AX devices.
Enable Promiscuous VIP Mode on Ethernet Interfaces
On each Ethernet interface that is connected to a firewall, use the following

command at the configuration level for the interface:
ip allow-promiscuous-vip
Note: If you use a Virtual Ethernet (VE) interface to connect to the traffic
inspection device, you need to enable promiscuous mode only on the VE

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Configuration
itself. The AX device then automatically enables promiscuous mode on
each of the Ethernet ports in the VLAN that belongs to the VE.
Import the Root CA-signed Certificate for the Content Servers
Use the following commands at the global configuration level to import the
root CA-signed certificate used by the content servers, and the certificate’s
private key:
slb ssl-load certificate file-name

[type {der | p7b |pem | pfx [password string]}]
[use-mgmt-port]
url
slb ssl-load private-key file-name

[use-mgmt-port]
url
The type option specifies the certificate file type. The default is pem. This
option is not applicable when importing the private key.
In each command, the use-mgmt-port uses the AX device’s management

port to import the certificate. If you omit this option, the AX device uses a
data interface instead.
The url option can be one of the following:


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Configuration
Configure the Client-SSL Template
To begin configuration of the client-SSL template, use the following com-

At this level, use the following commands:
forward-proxy-ca-cert certificate-name
This command specifies the CA-signed certificate to use for SSL
connections with clients.
forward-proxy-ca-key private-key-name
This command specifies the private key for the CA-signed certificate.
forward-proxy-enable
This command enables SSL Intercept support.
Map the Domain Names to the Server Certificates (if applicable)

If the servers manage more than one domain at the same IP address, you
must map the domain names to the certificates after importing them onto the
AX device.
To map a certificate to a domain, use the following command at the config-

uration level for the client-SSL template:
[no] server-name domain-name
cert certificate-name key private-key-name
[partition shared]
[pass-phrase string]
Configure the Paths Through the Traffic Inspection Devices
To begin configuration of a path, use the following command at the global

For the ipaddr, enter the IP address of the AX interface on the other side of
the traffic inspection device.
This command changes the CLI to the configuration level for the path. At
this level, use the following command to add a TCP port:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Configuration
port portnum tcp
For the portnum, specify the HTTP port number you plan to add to the wild-
card VIP on the inside AX device. This command changes the CLI to the
configuration level for the port. At this level, use the following command to
disable the Layer 4 health check:
no health-check
Note: Do not use the fire-wall command. The command is not applicable to
SSL Intercept.
To create a service group, use the following command at the global configu-
ration level of the CLI:
group. At this level, use the following command to add each path:
For the server-name, enter the name used for the real server configuration
for the path. For the portnum, use the same port number specified in the
Configure the Wildcard VIPs
First, configure the ACLs for the wildcard VIPs. For syntax information,
see the AX Series CLI Reference.
Outbound VIP
To configure the outbound VIP, use the following command at the global
slb virtual-server name 0.0.0.0 [acl acl-id]
This command changes the CLI to the configuration level for the VIP. At
this level, use the following command to add an HTTPS virtual port to the
VIP:
port portnum https
For the portnum, specify the HTTPS port number (typically, 443). This
command changes the CLI to the configuration level for the virtual port. At
this level, use the following commands:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Configuration
This command binds the service group of paths through the traffic
inspection devices to the wildcard VIP.

This command binds the client-SSL template to the wildcard VIP.
no-dest-nat port-translation
This command disables destination NAT. The port-translation option
enables the AX device to translate the destination protocol port in a client
HTTPS request before sending the request to the selected firewall. For SSL
Intercept, the option is required since the AX device decrypts the client
request, then sends the request to the firewall in the clear as an HTTP
request instead of an HTTPS request.
Wildcard Ports
Exit back one level to return to the server configuration level. Use the
following command to add the wildcard ports:
port 0 {tcp | udp | others}
Use the service-group command to bind the TCP and Others ports to the
TCP service group for the paths through the traffic inspection devices. Like-
wise, bind the UDP port to the UDP service group.
Use the following command to disable destination NAT. Also leave port
translation disabled:
no-dest-nat
Inbound VIP
To configure the inbound VIP, use the following commands:
use-rcv-hop-for-resp
use-default-if-no-server
no-dest-nat

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Configuration
Configuring the Outside AX Devices

This section shows the CLI syntax for configuring SSL Intercept on the out-
side AX devices.
Enable Promiscuous VIP Mode on Ethernet Interfaces
On each Ethernet interface that is connected to a firewall, use the following

command at the configuration level for the interface:
ip allow-promiscuous-vip
Configure the Paths Through the Traffic Inspection Devices
To begin configuration of a path, use the following command at the global

For the ipaddr, enter the IP address of the AX interface on the other side of
the traffic inspection device.
This command changes the CLI to the configuration level for the path. At
this level, use the following commands to add wildcard TCP and UDP
ports:
port 0 tcp
port 0 udp
For each port, use the following command to disable the Layer 4 health
check:
no health-check
Note: Do not use the fire-wall command. The command is not applicable to
SSL Intercept.
To create a service group, use the following command at the global configu-
group. At this level, use the following command to add each path:
member server-name:0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Configuration
Configure the Service Groups for the Gateway Router
Configure a service group for the HTTPS port, and service groups that use
wildcard ports for TCP and UDP.
slb server gw-name ipaddr
port 443 tcp
port 0 tcp
port 0 udp
On each port, disable the Layer 4 health check.

no health-check
Add the member for port 443 to a TCP service group. Add TCP port 0 to
another TCP service group. Add UDP port 0 to a UDP service group.
Configure the Server-SSL Template

To begin configuration of the server-SSL template, use the following com-
slb template server-ssl template-name
At this level, use the following command to enable SSL Froward Proxy sup-
port:
forward-proxy-enable
To configure the outbound VIP, use the following command at the global
This command changes the CLI to the configuration level for the VIP. At
this level, use the following command to add an HTTPS virtual port to the
VIP:
port portnum http
For the portnum, specify the HTTP port number (8080 in the sample
deployment). This command changes the CLI to the configuration level for
the virtual port. At this level, use the following commands:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Configuration
This command binds the service group for the SSL port on the gateway
router to the wildcard VIP.
template server-ssl template-name

This command binds the server-SSL template to the wildcard VIP.
no-dest-nat port-translation
This command disables destination NAT and enables port translation.
Wildcard Ports
Exit back one level to return to the server configuration level. Use the
following command to add the wildcard ports:
Use the service-group command to bind the TCP and Others ports to the
TCP service group for the gateway router. Likewise, bind the UDP port to
the UDP service group for the gateway router.

no-dest-nat
Inbound VIP
To configure the inbound VIP, use the following commands:
no-dest-nat
Use this command to bind the port to the service group for the paths through
the traffic inspection devices.
Displaying Certificate Hash Entries

To display hash entries for server certificates created by the AX device for
SSL Intercept, use the following command:
show slb ssl-forward-proxy-cert

virtual-server-name portnum {all | ipaddr}

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following sections show how to use the CLI to implement the SSL
Intercept deployment shown in Figure 130.
FIGURE 130 SSL Intercept Topology Example

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: For an example of configuration using the GUI, see the SSL Intercept
Deployment Guide from A10 Networks.
CLI Example—Inside AX Devices

The commands shown in this section configure the inside AX devices
Inside Primary AX Device
The following commands access the configuration level of the CLI, and
change the hostname:
AX>enable
Password:********
AX#config
AX(config)#hostname AX-Inside-Primary
Layer 2/3 Configuration

The following commands configure the VLANs:
AX-Inside-Primary(config)#vlan 10
AX-Inside-Primary(config-vlan:10)#untagged ethernet 20
AX-Inside-Primary(config-vlan:10)#router-interface ve 10
AX-Inside-Primary(config-vlan:10)#vlan 15

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands assign IP addresses to the VEs (router interfaces)
configured on the VLANs. Since VE 10 is the VE connected to the inside
clients, promiscuous VIP mode is enabled on this VE. The other VEs do not
use promiscuous VIP mode in this deployment.
AX-Inside-Primary(config-vlan:99)#interface ve 10
AX-Inside-Primary(config-if:ve10)#ip address 10.1.1.2 255.255.255.0
AX-Inside-Primary(config-if:ve10)#ip allow-promiscuous-vip
AX-Inside-Primary(config-if:ve10)#interface ve 15
AX-Inside-Primary(config-if:ve99)#exit
The following commands configure static routes to the network on the side
of the outside AX devices that connects to the Internet. The next-hop IP
address of each route is the floating IP address of a VRID on the outside AX
devices. Specifically, these are the floating IP addresses that belong to the
VRIDs for the VLANs that contain the traffic inspection devices.
AX-Inside-Primary(config)#ip route 20.1.1.0 /24 10.1.240.11
AX-Inside-Primary(config)#ip route 20.1.1.0 /24 10.1.250.11
SSL Configuration
The following commands import the root CA-signed certificate used by the
content servers, and the certificate’s private key:
AX-Inside-Primary(config)#slb ssl-load certificate ca.cert.pem scp:
User name []?admin
Password []?*********
AX-Inside-Primary(config)#slb ssl-load private-key ca.key.pem scp:
User name []?admin
Password []?*********
The following commands configure the client-SSL template:

AX-Inside-Primary(config)#slb template client-ssl SSLIntercept_ClientSide
AX-Inside-Primary(config-client SSL template)#forward-proxy-enable
AX-Inside-Primary(config-client SSL template)#forward-proxy-ca-cert ca.cert
AX-Inside-Primary(config-client SSL template)#forward-proxy-ca-key ca.key

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Path Configuration
The following commands configure the paths through the traffic inspection
devices:
AX-Inside-Primary(config-client SSL template)#slb server PSG1_Path 10.1.240.11
AX-Inside-Primary(config-real server)#port 0 tcp
AX-Inside-Primary(config-real server-node port)#no health-check
AX-Inside-Primary(config-real server-node port)#port 0 tcp
AX-Inside-Primary(config-real server-node port)#slb server PSG2_Path
10.1.250.11
AX-Inside-Primary(config-real server)#port 0 tcp
AX-Inside-Primary(config-real server-node port)#slb service-group LB_Paths_UDP
udp
AX-Inside-Primary(config-slb svc group)#member PSG1_Path:0
AX-Inside-Primary(config-slb svc group)#slb service-group LB_Paths_TCP tcp
AX-Inside-Primary(config-slb svc group)#slb service-group SSL tcp
AX-Inside-Primary(config-slb svc group)#member PSG_Path:8080
AX-Inside-Primary(config-slb svc group)#exit
The following commands configure the wildcard VIP to intercept all out-
bound traffic that originates from the inside network:
AX-Inside-Primary(config)#access-list 100 permit ip any any vlan 10
AX-Inside-Primary(config)#slb virtual-server outbound_wildcard 0.0.0.0 acl 100
AX-Inside-Primary(config-slb vserver)#port 0 tcp
AX-Inside-Primary(config-slb vserver-vport)#name Inside1_in_to_out
AX-Inside-Primary(config-slb vserver-vport)#service-group LB_Paths_TCP
AX-Inside-Primary(config-slb vserver-vport)#no-dest-nat
AX-Inside-Primary(config-slb vserver-vport)#port 0 udp
AX-Inside-Primary(config-slb vserver-vport)#name Inside1_in_to_out_UDP
AX-Inside-Primary(config-slb vserver-vport)#service-group LB_Paths_UDP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Inside-Primary(config-slb vserver-vport)#no-dest-nat
AX-Inside-Primary(config-slb vserver-vport)#port 443 https
AX-Inside-Primary(config-slb vserver-vport)#name Inside1_in_to_out_443
AX-Inside-Primary(config-slb vserver-vport)#service-group SSL
AX-Inside-Primary(config-slb vserver-vport)#template client-ssl
SSLIntercept_ClientSide
AX-Inside-Primary(config-slb vserver-vport)#no-dest-nat port-translation
VRRP-A Configuration
The following commands specify the VRRP-A device ID for this AX
device, add the AX device to VRRP-A set 1, and enable VRRP-A on the
device:
AX-Inside-Primary(config)#vrrp-a device-id 1
AX-Inside-Primary(config)#vrrp-a set-id 1
AX-Inside-Primary(config)#vrrp-a enable
The following commands configure the VRID for the inside AX devices’
interface with the inside client network:
AX-Inside-Primary(config)#vrrp-a vrid default
AX-Inside-Primary(config-vrid-default)#floating-ip 10.1.1.1
AX-Inside-Primary(config-vrid-default)#priority 200
AX-Inside-Primary(config-vrid-default)#tracking-options
AX-Inside-Primary(config-vrid-tracking)#interface ethernet 1 priority-cost 60
The following commands configure the VRID for the VLAN that contains
the first traffic inspection device (PSG1):
AX-Inside-Primary(config-vrid-tracking)#vrrp-a vrid 15
AX-Inside-Primary(config-vrid)#floating-ip 10.1.240.1
AX-Inside-Primary(config-vrid)#priority 200
AX-Inside-Primary(config-vrid)#tracking-options

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
the second traffic inspection device (PSG2):
AX-Inside-Primary(config-vrid-tracking)#vrrp-a vrid 16
AX-Inside-Primary(config-vrid)#floating-ip 10.1.250.1
AX-Inside-Primary(config-vrid)#priority 200
AX-Inside-Primary(config-vrid)#tracking-options
AX-Inside-Primary(config-vrid-tracking)#exit
AX-Inside-Primary(config-vrid)#exit
The following command configures the VRRP-S interface that connects this
AX device to its VRRP-A peer:
AX-Inside-Primary(config)#vrrp-a interface ethernet 18 vlan 99
Inside Secondary AX Device

The configuration on the inside secondary AX device is the same as that on
the inside primary AX device, with the exception of the following device-
specific parameters:
• Hostname – The hostname is configured with a unique value to make it
simpler to identify the device.
• VRRP-A device ID – This value must be unique within the set of AX
devices backed up by VRRP-A (the VRRP-A set).
• Interface IP addresses – The VLAN IDs are the same on both AX
devices, but the router interface on each VLAN has a unique IP address.
The IP address is unique on each AX device.
• Priority values of the VRIDs – To specify the AX device’s default
VRRP-A role (active or backup), each VRID on this AX device is con-
figured with a lower priority value than the same VRID on the inside
primary AX device.
Hostname Configuration
AX(config)#hostname AX-Inside-Secondary

AX-Inside-Secondary(config)#vlan 10
AX-Inside-Secondary(config-vlan:10)#untagged ethernet 20
AX-Inside-Secondary(config-vlan:10)#router-interface ve 10
AX-Inside-Secondary(config-vlan:10)#vlan 15

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Inside-Secondary(config-vlan:99)#interface ve 10
AX-Inside-Secondary(config-if:ve10)#ip address 10.1.1.3 255.255.255.0
AX-Inside-Secondary(config-if:ve10)#ip allow-promiscuous-vip
AX-Inside-Secondary(config-if:ve10)#interface ve 15
AX-Inside-Secondary(config-if:ve99)#exit
AX-Inside-Secondary(config)#ip route 20.1.1.0 /24 10.1.240.11
AX-Inside-Secondary(config)#ip route 20.1.1.0 /24 10.1.250.11
SSL Configuration
AX-Inside-Primary(config)#slb ssl-load certificate ca.cert.pem scp:
User name []?admin
Password []?*********
AX-Inside-Primary(config)#slb ssl-load private-key ca.key.pem scp:
User name []?admin
Password []?*********
AX-Inside-Secondary(config)#slb template client-ssl SSLIntercept_ClientSide
AX-Inside-Secondary(config-client SSL template)#forward-proxy-enable
AX-Inside-Secondary(config-client SSL template)#forward-proxy-ca-cert ca.cert
AX-Inside-Secondary(config-client SSL template)#forward-proxy-ca-key ca.key
Path Configuration
AX-Inside-Secondary(config-client SSL template)#slb server PSG1_Path
10.1.240.11
AX-Inside-Secondary(config-real server)#port 0 tcp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Inside-Secondary(config-real server-node port)#no health-check
AX-Inside-Secondary(config-real server-node port)#port 0 tcp
AX-Inside-Secondary(config-real server-node port)#slb server PSG2_Path
10.1.250.11
AX-Inside-Secondary(config-real server)#port 0 tcp
AX-Inside-Secondary(config-real server-node port)#slb service-group
LB_Paths_UDP udp
AX-Inside-Secondary(config-slb svc group)#member PSG1_Path:0
AX-Inside-Secondary(config-slb svc group)#slb service-group LB_Paths_TCP tcp
AX-Inside-Secondary(config-slb svc group)#slb service-group SSL tcp
AX-Inside-Secondary(config-slb svc group)#exit
AX-Inside-Secondary(config)#access-list 100 permit ip any any vlan 10
AX-Inside-Secondary(config)#slb virtual-server outbound_wildcard 0.0.0.0 acl
100
AX-Inside-Secondary(config-slb vserver)#port 0 tcp
AX-Inside-Secondary(config-slb vserver-vport)#name Inside1_in_to_out
AX-Inside-Secondary(config-slb vserver-vport)#service-group LB_Paths_TCP
AX-Inside-Secondary(config-slb vserver-vport)#no-dest-nat
AX-Inside-Secondary(config-slb vserver-vport)#port 0 udp
AX-Inside-Secondary(config-slb vserver-vport)#name Inside1_in_to_out_UDP
AX-Inside-Secondary(config-slb vserver-vport)#service-group LB_Paths_UDP
AX-Inside-Secondary(config-slb vserver-vport)#no-dest-nat
AX-Inside-Secondary(config-slb vserver-vport)#port 443 https
AX-Inside-Secondary(config-slb vserver-vport)#name Inside1_in_to_out_443
AX-Inside-Secondary(config-slb vserver-vport)#service-group SSL
AX-Inside-Secondary(config-slb vserver-vport)#template client-ssl
SSLIntercept_ClientSide
AX-Inside-Secondary(config-slb vserver-vport)#no-dest-nat port-translation

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Inside-Secondary(config)#vrrp-a device-id 2
AX-Inside-Secondary(config)#vrrp-a set-id 1
AX-Inside-Secondary(config)#vrrp-a enable
AX-Inside-Secondary(config)#vrrp-a vrid default
AX-Inside-Secondary(config-vrid-default)#floating-ip 10.1.1.1
AX-Inside-Secondary(config-vrid-default)#priority 180
AX-Inside-Secondary(config-vrid-default)#tracking-options
AX-Inside-Secondary(config-vrid-tracking)#interface ethernet 1 priority-cost
60
60
60
AX-Inside-Secondary(config-vrid-tracking)#vrrp-a vrid 15
AX-Inside-Secondary(config-vrid)#floating-ip 10.1.240.1
AX-Inside-Secondary(config-vrid)#priority 180
AX-Inside-Secondary(config-vrid)#tracking-options
60
60
60
AX-Inside-Secondary(config-vrid-tracking)#vrrp-a vrid 16
AX-Inside-Secondary(config-vrid)#floating-ip 10.1.250.1
AX-Inside-Secondary(config-vrid)#priority 180
AX-Inside-Secondary(config-vrid)#tracking-options
60
60
60
AX-Inside-Secondary(config)#vrrp-a interface ethernet 18 vlan 99

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Outside Primary AX Device
The following commands access the configuration level of the CLI, and
change the hostname:
AX>enable
Password:********
AX#config
AX(config)#hostname AX-Outside-Primary

AX-Outside-Primary(config)#vlan 15
AX-Outside-Primary(config-vlan:15)#untagged ethernet 1
AX-Outside-Primary(config-vlan:15)#router-interface ve 15
AX-Outside-Primary(config-vlan:15)#vlan 16
The following commands assign IP addresses to the VEs (router interfaces)

configured on the VLANs. Promiscuous VIP mode is enabled on the VEs
that are in the VLANs that contain the traffic inspection devices. The other
VEs do not use promiscuous VIP mode in this deployment.
AX-Outside-Primary(config-vlan:99)#interface ve 15
AX-Outside-Primary(config-if:ve15)#ip address 10.1.240.12 255.255.255.0
AX-Outside-Primary(config-if:ve15)#ip allow-promiscuous-vip
AX-Outside-Primary(config-if:ve15)#interface ve 16
AX-Outside-Primary(config-if:ve16)#ip allow-promiscuous-vip
AX-Outside-Primary(config-if:ve99)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands configure static routes to the network on the cli-
ent side of the inside AX devices. The next-hop IP address of each route is
the floating IP address of a VRID on the inside AX devices. Specifically,
these are the floating IP addresses that belong to the VRIDs for the VLANs
that contain the traffic inspection devices.
AX-Outside-Primary(config)#ip route 10.1.1.0 /24 10.1.240.1
AX-Outside-Primary(config)#ip route 10.1.1.0 /24 10.1.250.1
SSL Configuration
The following commands configure the server-SSL template:
AX-Outside-Primary(config)#slb template server-ssl SSLIntercept_ServerSide
AX-Outside-Primary(config-server SSL template)#forward-proxy-enable
Path Configuration
The following commands configure the paths through the traffic inspection
devices to the router on the inside client network:
AX-Outside-Primary(config-client SSL template)#slb server server-gateway
20.1.1.253
AX-Outside-Primary(config-real server)#port 0 tcp
AX-Outside-Primary(config-real server-node port)#no health-check
AX-Outside-Primary(config-real server-node port)#port 0 udp
AX-Outside-Primary(config-real server-node port)#port 443 tcp
AX-Outside-Primary(config-real server-node port)#slb service-group SG_TCP tcp
AX-Outside-Primary(config-slb svc group)#member server-gateway:0
AX-Outside-Primary(config-real server-node port)#slb service-group SG_UDP udp
AX-Outside-Primary(config-real server-node port)#slb service-group SG_443 tcp
AX-Outside-Primary(config-slb svc group)#exit
The following commands configure the wildcard VIP to intercept all out-
bound traffic that originates from the inside network:
AX-Outside-Primary(config)#access-list 100 permit ip any any vlan 15
AX-Outside-Primary(config)#access-list 100 permit ip any any vlan 16
AX-Outside-Primary(config)#slb virtual-server outside_in_to_out 0.0.0.0 acl
100
AX-Outside-Primary(config-slb vserver)#port 0 tcp
AX-Outside-Primary(config-slb vserver-vport)#service-group SG_TCP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Outside-Primary(config-slb vserver-vport)#use-rcv-hop-for-resp
AX-Outside-Primary(config-slb vserver-vport)#no-dest-nat
AX-Outside-Primary(config-slb vserver-vport)#port 0 udp
AX-Outside-Primary(config-slb vserver-vport)#service-group SG_UDP
AX-Outside-Primary(config-slb vserver-vport)#no-dest-nat
AX-Outside-Primary(config-slb vserver-vport)#port 8080 http
AX-Outside-Primary(config-slb vserver-vport)#name ReverseProxy_Wildcard
AX-Outside-Primary(config-slb vserver-vport)#service-group SG_443
AX-Outside-Primary(config-slb vserver-vport)#template server-ssl outside-
intercept
AX-Outside-Primary(config-slb vserver-vport)#no-dest-nat port-translation
The following commands specify the VRRP-A device ID for this AX
device, add the AX device to VRRP-A set 2, and enable VRRP-A on the
device:
AX-Outside-Primary(config)#vrrp-a device-id 3
AX-Outside-Primary(config)#vrrp-a set-id 2
AX-Outside-Primary(config)#vrrp-a enable
The following commands configure the VRID for the interface with the
inside client network:
AX-Outside-Primary(config)#vrrp-a vrid default
AX-Outside-Primary(config-vrid-default)#floating-ip 20.1.1.1
AX-Outside-Primary(config-vrid-default)#priority 200
AX-Outside-Primary(config-vrid-default)#tracking-options
AX-Outside-Primary(config-vrid-tracking)#interface ethernet 1 priority-cost 60
AX-Outside-Primary(config-vrid-tracking)#interface ethernet 20 priority-cost
60

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
the first traffic inspection device (PSG1):
AX-Outside-Primary(config-vrid-tracking)#vrrp-a vrid 5
AX-Outside-Primary(config-vrid)#floating-ip 10.1.240.11
AX-Outside-Primary(config-vrid)#priority 200
AX-Outside-Primary(config-vrid)#tracking-options
60
the second traffic inspection device (PSG2):
AX-Outside-Primary(config-vrid-tracking)#vrrp-a vrid 6
AX-Outside-Primary(config-vrid)#floating-ip 10.1.250.11
AX-Outside-Primary(config-vrid)#priority 200
AX-Outside-Primary(config-vrid)#tracking-options
60
The following command configures the VRRP-A interface that connects

this AX device to its VRRP-A peer:
Outside Secondary AX Device
The configuration on the outside secondary AX device is the same as that

on the inside outside AX device, with the exception of the following device-
specific parameters:
• Hostname
• VRRP-A device ID
• Interface IP addresses
• Priority values of the VRIDs
Hostname Configuration
AX(config)#hostname AX-Outside-Secondary

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Outside-Secondary(config)#vlan 15
AX-Outside-Secondary(config-vlan:15)#untagged ethernet 1
AX-Outside-Secondary(config-vlan:15)#router-interface ve 15
AX-Outside-Secondary(config-vlan:15)#vlan 16
AX-Outside-Secondary(config-vlan:99)#interface ve 15
AX-Outside-Secondary(config-if:ve15)#ip address 10.1.240.13 255.255.255.0
AX-Outside-Secondary(config-if:ve15)#ip allow-promiscuous-vip
AX-Outside-Secondary(config-if:ve15)#interface ve 16
AX-Outside-Secondary(config-if:ve16)#ip allow-promiscuous-vip
AX-Outside-Secondary(config-if:ve99)#exit
AX-Outside-Secondary(config)#ip route 10.1.1.0 /24 10.1.240.1
AX-Outside-Secondary(config)#ip route 10.1.1.0 /24 10.1.250.1
SSL Configuration
AX-Outside-Secondary(config)#slb template server-ssl SSLIntercept_ServerSide
AX-Outside-Secondary(config-server SSL template)#forward-proxy-enable
Path Configuration
AX-Outside-Secondary(config-client SSL template)#slb server server-gateway
20.1.1.253
AX-Outside-Secondary(config-real server)#port 0 tcp
AX-Outside-Secondary(config-real server-node port)#no health-check
AX-Outside-Secondary(config-real server-node port)#port 0 udp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Outside-Secondary(config-real server-node port)#port 443 tcp
AX-Outside-Secondary(config-real server-node port)#slb service-group SG_TCP
tcp
AX-Outside-Secondary(config-slb svc group)#member server-gateway:0
AX-Outside-Secondary(config-real server-node port)#slb service-group SG_UDP
UDP
AX-Outside-Secondary(config-real server-node port)#slb service-group SG_443
tcp
AX-Outside-Secondary(config-slb svc group)#exit
AX-Outside-Secondary(config)#access-list 100 permit ip any any vlan 15
AX-Outside-Secondary(config)#access-list 100 permit ip any any vlan 16
AX-Outside-Secondary(config)#slb virtual-server outside_in_to_out 0.0.0.0 acl
100
AX-Outside-Secondary(config-slb vserver)#port 0 tcp
AX-Outside-Secondary(config-slb vserver-vport)#service-group SG_TCP
AX-Outside-Secondary(config-slb vserver-vport)#use-rcv-hop-for-resp
AX-Outside-Secondary(config-slb vserver-vport)#no-dest-nat
AX-Outside-Secondary(config-slb vserver-vport)#port 0 udp
AX-Outside-Secondary(config-slb vserver-vport)#service-group SG_UDP
AX-Outside-Secondary(config-slb vserver-vport)#no-dest-nat
AX-Outside-Secondary(config-slb vserver-vport)#port 8080 http
AX-Outside-Secondary(config-slb vserver-vport)#name ReverseProxy_Wildcard
AX-Outside-Secondary(config-slb vserver-vport)#service-group SG_443
AX-Outside-Secondary(config-slb vserver-vport)#template server-ssl outside-
intercept
AX-Outside-Secondary(config-slb vserver-vport)#no-dest-nat port-translation

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-Outside-Secondary(config)#vrrp-a device-id 4
AX-Outside-Secondary(config)#vrrp-a set-id 2
AX-Outside-Secondary(config)#vrrp-a enable
AX-Outside-Secondary(config)#vrrp-a vrid default
AX-Outside-Secondary(config-vrid-default)#floating-ip 20.1.1.1
AX-Outside-Secondary(config-vrid-default)#priority 180
AX-Outside-Secondary(config-vrid-default)#tracking-options
AX-Outside-Secondary(config-vrid-tracking)#interface ethernet 1 priority-cost
60
60
60
AX-Outside-Secondary(config-vrid-tracking)#vrrp-a vrid 5
AX-Outside-Secondary(config-vrid)#floating-ip 10.1.240.11
AX-Outside-Secondary(config-vrid)#priority 180
AX-Outside-Secondary(config-vrid)#tracking-options
60
60
60
AX-Outside-Secondary(config-vrid-tracking)#vrrp-a vrid 6
AX-Outside-Secondary(config-vrid)#floating-ip 10.1.250.11
AX-Outside-Secondary(config-vrid)#priority 180
AX-Outside-Secondary(config-vrid)#tracking-options
60
60
60

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview of FTP and SIP
ALG Protocol FWLB Support for FTP and SIP
In simple FWLB deployments, the AX device does not support the ability to
load balance Application Layer Gateway (ALG) protocols, which have mul-
tiple connections that can originate from either side of the firewall deploy-
ment. This lack of predictability that occurs with ALG protocols can result
in the protocol’s control connection and data connection being sent to differ-
ent firewalls, which can cause the application to stop working.
To handle some of the more complex ALG protocols, you can configure the
AX device to load balance ALG protocols, such as FTP and SIP, through a
firewall deployment consisting of paired firewalls through the use of persis-
tent session templates.

When dealing with ALG protocols such as FTP and SIP, sessions can origi-
nate from either side of the firewalls. This unpredictable quality can pose a
challenge to the load balancer(s) inside the FWLB deployment when they
are tasked with setting up the persistent sessions that these protocols
require.
This ALG protocol FWLB feature resolves such issues with session persis-
tence across a firewall deployment for FTP and SIP traffic.
FTP Support
Figure 131 on page 354 shows FTP traffic passing back and forth between a
client and an FTP server. The AX device uses standard SLB server selection
methods to choose a firewall that will handle the client’s traffic.
The FTP protocol requires two separate sessions, or connections, which are
represented in Figure 131 with red and green arrows:
• The red arrow represents the control connection.
• The green arrows represent the data connections (or “out of band” con-
nections).

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 131 FTP Traffic Flows
The control connection (red arrow) is usually initiated by the client, while
the data connections (green arrows) can be initiated from either side of the
FWLB deployment and can be initiated by either the client or the FTP
server.
If the client initiates the data connection, then the FTP transaction is said to
be in “passive” mode. This is because the FTP server remains passive.
However, if the data connection is initiated by the FTP server, then the FTP
connection is said to be in “active” mode because the FTP server is taking
action.
SIP Support
As is the case with FTP, Session Initiation Protocol (SIP) poses unique chal-
lenges for the AX load balancers that are attempting to create persistent ses-
sions across a pair of firewalls in an FWLB deployment.
Figure 132 on page 355 shows two separate SIP transactions side by side.
Both scenarios involve a SIP server and two or more SIP clients.
The SIP protocol requires two separate sessions, which are represented in
the figure with red and green arrows:
• The green arrow represents the Communication Session.
• The red arrows represent the SIP Sessions.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 132 SIP traffic originating from both sides of FWLB deployment
Communication Session
originates from SIP Client1
Communication Session
originates from SIP Client2
The initial communication session is launched from a SIP client (as opposed
to the SIP server). This communication session can be launched from either
side of the FWLB deployment.
In the leftmost scenario shown in Figure 132, the communication session

originates from SIP client 1, while the scenario on the right shows the com-
munication session originating from SIP client 2, (in which case SIP client 2
is on the same side of the firewall as the SIP server).
Once the communication session is established between the SIP server and
client, then the SIP clients can communicate through a separate SIP session.
The load balancers in the FWLB deployment must be able to handle the SIP
sessions, regardless of which side of the FWLB deployment those sessions
might originate from.
When the communication session and SIP session are launched from differ-
ent sides of the FWLB Deployment, the AX device can load balance the
sessions through the same firewall by using a persistent session template.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Topologies for ALG Protocols FTP and SIP

With a brief overview of FTP and SIP protocols out of the way, this next
section provides a more in-depth illustration of sample network topologies.
These topologies provide the foundation for configuration examples that
appear toward the end of this chapter.
FTP Network Diagram

Figure 133 shows an example of a network topology for FTP FWLB.
FIGURE 133 Topology for FTP FWLB
The network diagram has the following characteristics:

• A client is located at the top of a firewall deployment and an FTP server
is located at the bottom. The firewalls are located at the center of the
topology.
• The firewall deployment uses one external AX device (“Ex-AX”) on the
public side of the firewalls and an internal AX device (“In-AX”) to han-
dle traffic from the private side of the firewalls.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: Real-world scenarios often use two AX devices in High Availability (HA)
mode. However, for the sake of simplicity, the topology discussed in this
chapter shows a single AX device on each side of the firewalls.
Note: Stateless load-balancing methods like Stateless Source IP Hash and State-
less Per-Packet Round Robin, are not supported for ALG protocols
FWLB.
SIP Network Diagram

Figure 134 shows another example of a network topology, but this illustra-
tion shows the network elements that would appear in a situation in which
SIP traffic is being load balanced across a firewall deployment.
FIGURE 134 Topology for SIP FWLB

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The network diagram has the following characteristics:
• A SIP client is located at the top of the firewall deployment.
• A SIP client and a SIP server are located at the bottom of the firewall
deployment.
• The firewall deployment uses one external AX device (“Ex-AX”) on the
public side of the firewalls and an internal AX device (“In-AX”) to han-
dle traffic from the private side of the firewalls.
Persistent Sessions for ALG Protocol FWLB

This section shows persistent session information for FTP and SIP. The per-
sistent session information shown in the tables below correlates to the net-
work topologies shown for FTP in Figure 133 on page 356, and for SIP in
Figure 134 on page 357.
FTP Persistent Sessions

The two session tables below show persistent sessions for FTP FWLB.
• Table 3 on page 358 displays persistent sessions for the client-side ses-
sion, from the perspective of the external-facing AX device.
• Table 4 on page 359 displays persistent sessions for the server-side ses-
sion, from the perspective of the internal-facing AX device.
External-facing AX Device (client-side)

The session information shown below represents the control connection of
an FTP transaction in passive FTP mode. The session (initiated from the cli-
ent) is shown from the perspective of the external-facing device, “Ex-AX”.
TABLE 3 ‘show session persist’ output for persistent FTP session through FWLB (“Ex-AX”)
Forward Source Forward Dest Reverse Source
10.1.1.2 10.4.1.2:65535 10.2.1.2:65535
• Forward Src – This leftmost column in the table above shows the IP
address of the client (10.1.1.2). As with standard SLB scenarios, the
Forward Source is the IP address of the client.
• Forward Dest – The Forward Destination, (middle column above), is the
real server’s IP address (10.4.1.2). Note that this is different from stan-
dard SLB situations, in which the Forward Destination would usually be
a VIP on the AX device instead of a real server.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• Reverse Source – The Reverse Source, (rightmost column above), repre-
sents the IP address (10.2.1.2) for the firewall interface connected to the
external-facing AX device, “Ex-AX”. The fact that the firewall’s IP
address is the Reverse Source is different from standard SLB scenarios
where the Reverse Source would typically be the IP address of the VIP
on the AX device.
Internal-facing AX Device (server-side)

The control connection for the server-side session, from the client to the
server, opens a persistent session through the firewall. Subsequent TCP traf-
fic, such as the data connection, has the same source IP and destination IP as
the control connection, so it follows the same path and selects the same fire-
wall as the persistent session selected by the control session.
Table 4 below displays output from the show session persist command for
the persistent sessions for passive FTP from the perspective of the internal-
facing AX device (“In-AX”).
TABLE 4 ‘show session persist’ output for persistent FTP sessions through FWLB (“In-AX”)
10.1.1.2 10.4.1.2:65535 10.4.1.2:65535
10.4.1.2 10.1.1.2:65535 10.3.1.2:65535
The first session in the table is for the control session, and the second ses-
sion is for the data session. The session output has the following noteworthy
properties:
• (Prot) Forward Src – This is the IP address of the client (10.1.1.2). As
with standard SLB scenarios, the Forward Source is also the IP address
of the client.
• Forward Dest – The Forward Destination is the real server’s IP address
(10.4.1.2). This is different from a standard SLB situation, in which the
Forward Destination would usually be a VIP on the AX device.
• Reverse Source – This is the IP address of the real FTP server (10.4.1.2).
Note: The second session in the table can be disregarded because it belongs to
the data connection, and the data connection is simply following the con-
trol connection that was opened up by the first persistent session.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SIP Persistent Sessions

The two session tables below show persistent sessions for SIP firewall load
balancing, as shown in the topology diagram in Figure 134 on page 357.
• Table 5 on page 360 displays persistent sessions for the server-side ses-
sion, from the perspective of the internal-facing AX device.
• Table 6 on page 360 displays persistent sessions for the client-side ses-
sion, from the perspective of the external-facing AX device.
Internal-facing AX Device (server-side)

The session tables below show persistent sessions for SIP FWLB. The
server-side sessions are seen from the perspective of the internal-facing “In-
AX” (AX5100A).
TABLE 5 ‘show session persist’ output for persistent SIP session through FWLB (“In-AX” - AX5100A)
N/A 1.0.7.2:65535 1.0.1.2:65535
• Forward Src – This is a destination-IP persistent session. Therefore,

there is no "Forward Source" port.
• Forward Dest – The Forward Destination, (middle column above), is the
SIP client 1 in the public network (1.0.7.2). (See Figure 132 on
page 355.)
• Reverse Source – The Reverse Source, (rightmost column above), repre-
sents the IP address (1.0.1.2), which is the IP of the firewall interface
connected to the internal-facing AX device, “AX5100A”.
External-facing AX Device (client-side)

The session information shown below represents the communication con-
nection for a SIP transaction. The session (initiated from the client) is
shown from the perspective of the external-facing device, “Ex-AX”.
Note: When configuring SIP for FWLB, the source-IP persistence template and
the destination-IP persistence template should be configured with the
netmask option (with the value set to “/24”), in order to make the SIP
server and SIP client 2 traffic follow the same persistent session. The net-
mask option is needed because the two sessions have different IP
addresses but are located within the same subnet.
TABLE 6 ‘show session persist’ output for persistent SIP sessions through FWLB (“Ext-AX” - AX5100B)
1.0.7.2 1.0.9.3:65535 1.0.2.2:65535
1.0.7.2 1.0.9.2:65535 1.0.2.2:65535

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The output for the two persistent sessions (from the perspective of the exter-
nal-facing AX device, “AX5100B”) has the following noteworthy proper-
ties:
• (Prot) Forward Src – The Forward Source is the IP address (1.0.7.2)
associated with SIP client 1 on the public network.
• Forward Dest – The Forward Source is the IP address (1.0.9.3), which is
associated with the SIP server in Figure 134 on page 357. (The second
session in the table has an IP of 1.0.9.2, which is associated with SIP cli-
ent 2.)
• Reverse Source – This address represents the IP (1.0.2.2) for the firewall
interface connected to the external-facing AX device, “AX5100B”.
Configuration Parameters for ALG Protocol FWLB

Regardless of whether you are configuring FWLB for FTP or SIP, the fol-
lowing items must be configured:
• Wildcard VIP – See “Wildcard VIP” on page 361
• Session persistence – See “Session Persistence for FTP and SIP” on

page 364
• Health monitoring – See “Health Monitoring for FWLB Paths” on
page 366
Wildcard VIP
A wildcard VIP is a VIP that does not have a specific IP address. Instead,
wildcard VIPs have IP address 0.0.0.0 (for IPv4) or “ :: ” (for IPv6). Client
requests sent to any IP address will be accepted when they are received at a
a wildcard VIP.
Wildcard VIPs use Access Control Lists (ACLs) to filter client requests,
thus preventing potential miscreants from causing damage to network
resources located behind the wildcard VIP.
To load balance ALG protocols through the firewalls, wildcard VIPs are
necessary to handle traffic heading in each direction (ingress and egress). A
pair of wildcard VIPs is needed for each AX device. One wildcard VIP is
needed for traffic coming to the firewall and another is needed to handle
traffic going from the firewall.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
ACLs for Identifying Valid Traffic
To specify the source and destination IP addresses that a wildcard VIP will
accept from clients, a pair of ACLs must be configured.*
Note: Each ACL has an implicit “deny any” rule at the end. Any traffic that is
not explicitly permitted by another rule in the ACL is denied by the
implicit “deny any” rule.
Note: The AX device can have only one wildcard VIP that is not bound to an
ACL. This unbound wildcard VIP is known as the default, and it is used
to process traffic that does not create a positive match on any of the other
ACLs that are bound to other wildcard VIPs.
From External AX Perspective (Client-Side Session):

• An ACL is configured to permit traffic from the client subnet
(10.1.1.x/24) to pass to the server’s subnet (10.4.1.x/24). This ACL is
bound to the service group associated with the firewalls. (In the sample
configuration that follows, this ACL is called “ACL 100”.)
• An ACL is configured to permit traffic from the server subnet
(10.4.1.x/24) to pass to the client’s subnet (10.1.1.x/24). This ACL is
bound to the service group associated with the client. (In the sample
From Internal AX Perspective (Server-Side Session):

• An ACL is configured to permit traffic from the client subnet
(10.1.1.x/24) to pass to the server’s subnet (10.4.1.x/24). This ACL is
bound to the service group associated with the servers. (In the sample
• An ACL is configured to permit traffic from the server subnet
(10.4.1.x/24) to pass to the client’s subnet (10.1.1.x/24). This ACL is
bound to the service group associated with the firewalls. (In the sample
Wildcard Protocol Ports on the Wildcard

Each VIP on the AX devices in an ALG protocol FWLB deployment
(“Ex-AX” and “In-AX”) requires a wildcard TCP port (port 0). This wild-
card port 0 is required because the data session destination port is unknown
when dealing with ALG scenarios. Thus, simply configuring well-known
FTP ports 20 and 21 will not work and a wildcard port must be used instead.
*.
Extended ACLs, which can filter based on destination address, IP protocol, and TCP/UDP
port numbers, should be used to provide more granular control. The goal is to permit traffic
along the path from a specific client subnet to the IP addresses of the real servers.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
During configuration, the following parameters (enabled by default), must
be disabled for ALG protocol FWLB to work:
• Layer 4 health check – Layer 4 health checks are typically used to test
the TCP ports on a real server. The health check consists of a TCP SYN
request being sent to the TCP port on an AX device. If the TCP port
responds with a TCP SYN ACK, then it is determined that the TCP port
is healthy. If no response is received, then it is determined that the TCP
port is down.
The Layer 4 health check must be disabled in ALG protocol FWLB sce-
narios. If not disabled, then the default Layer 4 health check method will
be used, causing the SYN packet to be sent to the default port (“port
65535”) of the real server. The SYN packet will not be received on port
0, the SYN ACK response will not be sent, and the health check will fail
(because it will appear as though the real server status is down).
• Destination NAT – With destination NAT enabled, the AX device swaps
the destination address in the packet from the client with the VIP on the
AX device. However, destination NAT must be disabled at the wildcard
port level to prevent this swap from occurring, or else the traffic from
the client will have its destination IP changed to the IP address of the
service-group member. This would be the IP address of the firewall,
which would present problems because the firewall can not handle the
traffic.
Server and Service-group Requirements

On the external-facing AX device (“Ex-AX”), a service group is required
for the firewalls, and another service group is required for the client. How-
ever, in most deployments, the service group would be configured for the
next-hop router(s) instead of an actual client.
On the internal AX device (“In-AX”), a service group is required for the

firewalls, and another service group is required for the real server(s).
Note: When configuring the service groups, keep in mind that stateless load bal-
ancing algorithms, such as Stateless Source IP Hash, are not supported.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Details:
• All real servers in the service groups must use wildcard ports, such as
“port 0 tcp”. If this is not done, persistent FWLB for FTP will not work
correctly. The FTP protocol uses well-known ports 20 and 21, so speci-
fying just one of these ports would result in traffic from the other port
being denied.
• Layer 4 health checks on the wildcard ports must be disabled. If this is
not done, the configuration will fail because the Layer 4 health check
traffic will be sent to default port 65535 instead of port 0. No response
will be generated, and it will appear as though the port is down.
• When using the slb server command to configure the firewalls, you
must include the fire-wall option when using the CLI or select the fire-
wall checkbox in the GUI (under the Server create page), so the AX
device knows these are firewall devices and not “SLB servers”.
Promiscuous Mode
Promiscuous mode can be enabled on AX data interfaces. By default, the
option is disabled, but it must be enabled on the data interfaces that are con-
nected to the firewalls in an ALG FWLB configuration.
Note: When using a Virtual Ethernet (VE) interface to connect to the firewalls,
you must enable promiscuous mode only on the VE itself. The AX device
automatically enables promiscuous mode on each of the Ethernet ports in
the VLAN that belongs to that VE.
Session Persistence for FTP and SIP

Load balancing ALG protocols across a firewall requires session persis-
tence. For a given session, the same firewall must be used for traffic in both
directions. For example, if the AX device selects FW1 (see Figure 133 on
page 356) for a client’s FTP request, the AX device must continue to use
FW1 for all subsequent traffic on that control session.
FTP-Specific Configurations
FWLB for FTP requires the following configuration options for persistence:
• Source-IP persistence template – Within the source-IP persistence tem-
plate, the include destination-IP option is used to enable persistence of
the destination IP address. When the include destination-IP option is
enabled in a source-IP persistence template, the AX device uses the
same firewall for a given source-destination pair of IP addresses for the
entire session. This option is disabled by default.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: The internal AX device (“In-AX”), which is connected to the FTP serv-
ers, must have the persistence template configured on both wildcard VIPs.
However, the external AX device (“Ex-AX”), which is connected to the
clients, only needs to have the persistence template configured on the
wildcard VIP that is bound to the firewalls, but not on the wildcard VIP
that is bound to the client.
• Use-rcv-hop-for-resp – This option is configurable on individual virtual
ports. When this option is enabled, it forces the AX device to send a
reply back through the last hop from which the request was received.
• On the AX device connected to clients, FWLB ALG for FTP
requires this option on the wildcard virtual port for the server-to-cli-
ent direction. This is the virtual port on the wildcard VIP that uses
that ACL that matches on the client subnet.
• On the AX device connected to the servers, the use-rcv-hop-for-resp
option is required on the wildcard virtual port for the client-to-
server direction. In this case, the src-dst-ip-swap-persist suboption
also is required. The src-dst-ip-swap-persist suboption “swaps” the
source and destination addresses in the persistent session.
Note: The use-rcv-hop-for-resp option has several sub-options that can be used
with the SIP protocol that can use more than two sessions.
SIP-Specific Configuration
FWLB for SIP requires the following configuration options for persistence:
• Destination-IP session persistence should be configured on the AX
device that is connected to the SIP server and SIP client 2.
(See Figure 134 on page 357.)
• Source-IP session persistence should be configured (using the incl-dst-
ip command) on the AX device that is connected to SIP client 1.
In order to get both sessions (originating from different sides of the FWLB)
to go through the same firewall node, a special persistent session must be
configured on the AX device at the side of the SIP server and SIP client 2.
Note: The options: use-src-ip-for-dst-persist and use-date-ip-for-src-persist,

have the same operation mode as src-dst-ip-swap-persist.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Monitoring for FWLB Paths
Optionally, you can configure each AX device to regularly test the paths
through the firewalls to the other AX device. To test the paths, configure a
Layer 3 health monitor (ICMP ping) and enable the “transparent” option.
The transparent option includes a special payload in the health-check pack-

ets that is recognized by the other AX device. For example, in Figure 135, a
health-check packet from “Ex-AX” travels through FW1 to “In-AX”.
“In-AX” recognizes the special payload and replies to the health check.
The red arrow in Figure 135 below shows the path of this ICMP packet.
FIGURE 135 Health Monitoring for Firewall
In response, the external-facing AX device (“Ex-AX”) checks whether the

ICMP echo request packet has a special payload. If the special payload is
present, then “Ex-AX” sends an ICMP echo response packet to the source
MAC address of “FW1”, which was contained in the original echo request
packet. This ICMP echo response packet is represented by the blue arrow.
Note: The health check (ICMP ping) occurs at Layer 3. The health checks at
Layer 4 do not apply to FWLB ALG and must be disabled.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configuration
This section shows how to configure an AX device for ALG FWLB using
wildcard VIPs. Separate instructions are provided for FTP and SIP, and con-
figuration instructions are provided for the AX GUI and CLI.
The process of configuring a pair of AX devices to handle AGL traffic, such
as FTP and SIP, consists of the following high-level steps:
1. Create the ACLs that will be bound to the wildcard VIPs in order to per-
mit traffic from specific clients or subnets. It is recommended that you
use an extended ACL for greater granularity instead of a standard ACL.
2. Enable promiscuous mode on the Ethernet interfaces connected to the

firewalls, real servers, and clients.
3. Configure a Layer 3 ICMP health monitor with transparent mode

enabled.
4. Configure the firewall nodes and real servers, and then add wildcard
ports to the firewall nodes and disable the Layer 4 health checks on
those ports.
5. Create separate service groups for the firewall nodes, real servers, and
SIP or FTP clients.
6. Configure a source-IP persistence template and enable destination per-

sistence.
7. Configure the wildcard VIPs:

• Create a wildcard VIP for traffic in each direction.
• Bind the ACL that matches traffic from the servers to the wildcard
VIP for the servers.
• Bind the ACL that matches traffic from the clients to the wildcard
VIP for the firewalls.
• Disable destination NAT.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
USING THE GUI
The GUI example below is based on the network topology for FTP FWLB
shown in Figure 133 on page 356. To configure the ALG FWLB feature
using the GUI, follow the steps below:
Creating Access-Control Lists

1. Navigate to Config Mode > Network > Extended, and then click Add.
The Extended ACL create page appears, as shown in Figure 136 below.
FIGURE 136 Config Mode > Network > Extended > Add
2. Perform the following configurations in the Extended ACL window:

a. Enter “100” in the ID field.
b. Select Permit for the Action radio button.
c. Click the Protocol drop-down menu and select TCP.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
d. In the Source Address area, select the Address radio button and
enter the beginning of the range of IP addresses to be permitted.
In this example, enter 10.1.1.0, with filter mask 0.0.0.255.
e. In the Destination Address area, select the Address radio button and
enter the end of the range of IP addresses that will be permitted. In
this example, enter 10.4.1.0, with filter mask 0.0.0.255.
f. When finished, click OK to save your changes.
g. Repeat the steps above to create the following additional ACLs:
• ACL 101 permit tcp 10.4.1.0 /24 to 10.1.1.0 /24
(to be applied to the external-facing AX device)
• ACL 200 permit tcp 10.1.1.0 /24 to 10.4.1.0 /24
(to be applied to the internal-facing AX device)
• ACL 201 permit tcp 10.4.1.0 /24 to 10.1.1.0 /24
(to be applied to the internal-facing AX device)
Enabling Promiscuous Mode
3. To begin the process of configuring the Ethernet interfaces, navigate to

Config Mode > Network > Interface > LAN. Then, click on the hyper-
link for the interface you wish to configure, such as “e1”.
4. Enter an IP address and subnet for that interface (if not already config-
ured).
5. Click the arrow to expand the VIP section and then select the Enabled
radio button for Allow Promiscuous VIP, as shown in Figure 137
below.
FIGURE 137 Config Mode > Network > Interface > LAN > VIP
6. Repeat these steps to enable promiscuous mode for each Ethernet inter-
face that is connected to the firewalls, the real servers, or clients.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configure a Transparent Health Monitor
7. To begin the process of configuring a Layer 3 ICMP health monitor

(with transparent mode enabled), navigate to Config Mode > Service >
Health Monitor, and then click Add to display the Health Monitor cre-
ate page.
8. Click the arrow to expand the Method section. (See Figure 138.) The
method you configure will be used to perform a transparent health
check by sending a ping through the firewall to external-facing AX
device.
FIGURE 138 Config Mode > Service > Health Monitor
9. Configure the Layer 3 health monitor as follows:

a. Enter “FW-HC” in the Name field.
b. Click the Type drop-down menu and select ICMP, if not already
selected.
c. For the Mode field, select the Transparent checkbox.
d. For the Alias Address, select the IPv4 checkbox and enter the IP
address of the external-facing AX device (“Ex-AX”), the interface
at 10.2.1.1, which is connected to the firewall.
e. Click OK to save your changes.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configure the Firewall Nodes, Real Server, and Client
10. To begin the process of configuring a server configuration for the fire-
wall node, navigate to Config Mode > Service > SLB > Server. Then,
click Add to display the Server create page, as shown in Figure 139.
11. Make the following configurations:

a. Enter the name of the firewall in the Name field. In this example,
the firewall is called “FW1”.
b. Enter an IP address of 10.3.1.2. in the IP Address/ Host field.
c. Click the Health Monitor drop-down menu and select FW-HC.
d. Select the Firewall checkbox.
12. Next, click on the arrow to expand the Port section, as shown in

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
FIGURE 140 Server Port section

a. Enter “0” in the Port field.
b. Select TCP from the Protocol drop-down menu.
c. Select the Health Monitor drop-down menu and select none. (The
health monitor for this port should be disabled.)
d. Click the Add button.
e. Click OK to save your changes.
14. Repeat the steps in this section to create the following additional server
configurations:
• An additional server configuration for firewall “FW2” with IP
address of 10.3.1.3. This server configuration should have the same
properties as the first firewall node.
• A server configuration for the FTP real server “SRV” with IP
address of 10.4.1.2. This server configuration should have the same
properties as the first firewall node, but without health monitors.
• A server configuration for client “CL” with IP address of 10.1.1.2.
This server configuration (for the client) should have the same prop-
erties as the first firewall node, but without health monitors.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configure Service Groups for Firewalls, Real Server, and Client
15. To begin the process of configuring a service group for the firewall
nodes, navigate to Config Mode > Service > SLB > Server. Then, click
Add to display the Service Group create page, as shown in Figure 141.

a. Enter the name of the Service Group in the Name field. In this
example, the first service group is for the firewalls and is called
“FW-SG”.
b. Click the Type drop-down and select TCP (if not already selected).
c. Scroll down to the Server section and click the arrow to expand.
d. Click the Server drop-down menu and select “FW1” (and “FW2”).
e. Enter “0” in the Port field.
f. Click the Add button to add the firewall server configuration as a
member of this service group.
g. Click OK to store your changes.
17. Repeat the steps in this section to create the following additional service
groups:
• A service group “SRV-SG” with FTP real server, “SRV”, added as a
member at port 0.
• A service group “CL-SG” with the client’s server configuration,
“CL”, added as a member at port 0.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configure a Source IP Persistence Template
18. To begin the process of configuring a source-IP persistence template,

navigate to Config Mode > Service > Template > Persistent > Source IP
Persistence. Then, click Add to display the Source IP Persistence tem-
plate create page, as shown in Figure 142.
FIGURE 142 Config Mode > Service > Template > Persistent

a. Enter the Source IP Persistence template in the Name field.
b. Select the Include Destination IP checkbox (to enable destination
persistence).
c. Click OK to store your changes.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
20. To begin the process of configuring a source-IP persistence template,

navigate to Config Mode > Service > SLB > Virtual Server, and then
click Add to display the Virtual Server create page, as shown in
Figure 143.

a. Enter the name of the wildcard VIP in the Name field. In this exam-
ple, the name is “toFW” because the wildcard VIP will be used to
handle FTP traffic coming to the firewall (and to the external-facing
AX device) from the client on the public network.
b. Select the Wildcard checkbox.
c. Click the Access List drop-down and select ACL 100.
d. Click the Persistence Type drop-down menu and select Source IP
Persistence Template.
e. Click the source-IP persistence template and select “aaa”.
f. Click OK to save your changes.
g. Expand the Port area by clicking the arrow.
h. Ensure that TCP is selected as the port Type.
i. Enter “0” in the Port field.
j. Click the Service Group drop-down menu and select “FW-SG”.
k. Scroll down to the Direct Server Return area and select the Enabled
radio button to turn off destination NAT for this virtual port.
l. Click OK to save your changes.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
22. Repeat these steps to create another wildcard VIP, as follows:
a. Enter the name of the wildcard VIP in the Name field. In this exam-
ple, the name is “fromFW” because the wildcard VIP will be used to
handle FTP traffic coming from the firewall (and from the external-
facing AX device) going to the real servers on the private network.
b. Select the Wildcard checkbox.
c. Click the Access List drop-down and select ACL 101.
d. Click the Persistence Type drop-down menu and select Source IP
Persistence Template.
e. Click the Source IP Persistence Template and select “aaa”.
f. Expand the Port area by clicking the arrow.
g. Ensure that TCP is selected as the port Type.
h. Enter “0” in the Port field.
i. Click the Service Group drop-down menu and select “SRV-SG”.
j. Select the Use received hop for response checkbox, and then select
src-dst-ip-swap-persist from the drop-down that appears.
k. Scroll down to the Direct Server Return area and select the Enabled
radio button to turn off destination NAT for this virtual port.
l. Click OK to save your changes.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
USING THE CLI
Configuring Use-rcv-hop-for-resp
These CLI commands and sub-options are used at the virtual port level to
enable the AX device to support persistent sessions of ALG traffic across a
firewall deployment:
[
src-dst-ip-swap-persist |
use-src-ip-for-dst-persist |
use-dst-ip-for-src-persist
]
Configuring Src-dst-ip-swap-persist
This command is used at the virtual port level to create a persistent session
after the source IP and destination IP have been swapped. The new persis-
tent session that is created should match both the source IP and the destina-
tion IP. This option should be used with the incl-dst-ip option.
use-rcv-hop-for-resp [src-dst-ip-swap-persist]
Note: This option cannot be used for the SIP protocol, because a SIP transaction
may involve three or more parties.
Configuring Use-src-ip-for- dst-persist

This command is used at the virtual port level to create a destination persis-
tent session based on the source IP.
use-rcv-hop-for-resp [use-src-ip-for-dst-persist]
Configuring Use-dst-ip-for-src-persist
This command is used at the virtual port level. When this option is enabled,
the AX device uses the destination IP to create source-IP persistent sessions
for SIP or FTP sessions. With this option, the response packet will go
through the same firewall as the client’s request packet, and the SIP session
and communication sessions will be load balanced through the same fire-
wall node.
use-rcv-hop-for-resp [use-dst-ip-for-src-persist]

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configuring Include destination IP on Persistence
The following command is used within the source-IP persistence template
for ALG protocols, such as FTP. A special persistent session is used for this
feature, and this option helps ensure that the session will be matched on
both the source IP and destination IP addresses.
incl-dst-ip
Note: This option is not applicable to destination-IP persistence templates.
Configuring the Firewall

The following command is used at the SLB server config level to tell the
AX device that this real server is actually a firewall node configuration.
This option is allows the AX device to learn the MAC address of this fire-
wall.
fire-wall

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
CLI EXAMPLE FOR FTP
The CLI example below is based on the network topology for FTP FWLB
Configure ACLs
Note: It is recommended that you use extended ACLs, rather than standard
ACLs, in order to achieve greater granularity. Extended ACLs allow you
to specify both the source and destination IP, so you have explicit control
over which traffic is permitted and where it is allowed to go.
(From Perspective of External AX Device)
The following command creates extended “ACL 100”, which permits traffic
from the clients on subnet 10.1.1.0 and going to FTP servers on subnet
10.4.1.0. (This ACL will later be bound to the service group associated with
the firewalls.)
AX(config)#access-list 100 permit tcp 10.1.1.0 0.0.0.255 10.4.1.0 0.0.0.255
from the FTP servers on subnet 10.4.1.0 and going to clients on subnet
the clients.)
(From Perspective of Internal AX Device)

from the clients on subnet 10.1.1.0 and going to FTP servers on subnet
the FTP servers.)
from the FTP servers on subnet 10.4.1.0 and going to clients on subnet
the firewalls.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configure Ethernet Interfaces and Enable Promiscuity
The following commands create the Ethernet interfaces connected to the
firewalls and the real servers or clients, and then enable promiscuous mode:
AX(config-if:ethernet1)#ip address 10.3.1.1 255.255.255.0
AX(config-if:ethernet1)#ip allow-promiscuous-vip
Health Monitor for Internal AX device

The following command creates the health monitor “FW-HC”, which con-
tains the method ICMP transparent. The method is used to perform a trans-
parent health check, and it will send a ping through the firewall to the IP
address of the external-facing AX device (“Ex-AX”) at 10.2.1.1:
AX(config)#health monitor FW-HC
AX(config-health:monitor)#method icmp transparent 10.2.1.1
Configure Firewall Nodes and Real Server

Next, create a server configuration for the firewall node “FW1” (at IP
address 10.3.1.2) and another firewall node “FW2” (at IP address 10.3.1.3),
assign the “FW-HC” health check, and use the fire-wall command to tell the
AX device that these two new SLB servers are actually firewall nodes.
Then, add wildcard ports (port 0) to the firewall nodes.
Create a server configuration for the FTP server, “SRV”, at IP address

10.4.1.2, and add wildcard ports (port 0) to the server while disabling the
Layer 4 health checks, which are enabled by default.
While it may seem unusual to do so, create a server configuration for the cli-
ent, “CL” (at IP address 10.1.1.2). This is necessary to ensure the FTP ses-
sions can be correctly routed across the firewall while maintaining session
persistence. As with the other servers, you must add wildcard ports (port 0)
while disabling the Layer 4 health checks.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
AX(config)#slb server FW1 10.3.1.2
AX(config-real server)#health-check FW-HC
AX(config-real server)#fire-wall
AX(config)#slb server FW2 10.3.1.3

AX(config-real server)#health-check FW-HC
AX(config-real server)#fire-wall
AX(config)#slb server SRV 10.4.1.2

AX(config)#slb server CL 10.1.1.2


Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Create Service Groups for Firewalls, Real Server, and Clients
Use the following commands to create the service group, “FW-SG”, which
will be used to manage the two firewall nodes. Then, add the two firewall
nodes, “FW1” and “FW2”, as service group members, on port 0. Similarly,
create a separate service group “SRV-SG” to manage the FTP server, and
then add the server “SRV” on port 0. Lastly, create a separate service group
“CL-SG” to manage the clients, and then add the client “CL” on port 0.
AX(config)#slb service-group FW-SG tcp
AX(config-slb svc group)#member fw1:0
AX(config-slb svc group)#member fw2:0
AX(config)#slb service-group SRV-SG tcp
AX(config-slb svc group)#member SRV:0
AX(config)#slb service-group CL-SG tcp
AX(config-slb svc group)#member CL:0
Configure a Source IP Persistence Template

Create a source-IP persistence template “AAA” and use the incl-dst-ip
command to enable destination persistence:
AX(config)#slb template persist source-ip aaa
AX(config-source ip persist)#incl-dst-ip
Configure Wildcard VIPs

Use the following commands to create the wildcard VIPs at IP address
0.0.0.0, which will be used to handle FTP traffic coming to the external-fac-
ing AX device from the client on the public network. The previously-cre-
ated ACL (“ACL 100”) is bound to the wildcard VIP, port 0 is associated
with service group “FW-SG”, destination NAT is disabled, and persistence
is enabled.
AX(config)#slb virtual-server toFW 0.0.0.0 acl 100
AX(config-slb vserver-vport)#name _wildcard_v4_101_TCP_65535
AX(config-slb vserver-vport)#service-group FW-SG
AX(config-slb vserver-vport)#template persist source-ip aaa

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
0.0.0.0, which will be used to handle FTP traffic going from the external-
facing AX device to the real servers on the private network. The previously-
created ACL (“acl 100”) is bound to the wildcard VIP, port 0 is associated
with service group “FW-SG”, destination NAT is disabled, and persistence
is enabled.
AX(config)#slb virtual-server fromFW 0.0.0.0 acl 100
AX(config-slb vserver-vport)#name _wildcard_v4_100_TCP_65535
AX(config-slb vserver-vport)#service-group SRV-SG
AX(config-slb vserver-vport)#use-rcv-hop-for-resp src-dst-ip-swap-persist
AX(config-slb vserver-vport)#template persist source-ip aaa
Verifying FTP Configurations with Show Command
When finished with these configurations, you can use the “show session”
command to verify that an FTP control connection could create a src-dst-ip-
swap-persist session, as shown below:
Internal-AX(config)#show session
Port Forward Source Forward Dest Reverse Source
--------------------------------------------------------------------
src 10.4.1.2 10.1.1.2:65535 10.3.1.3:65535
Total Sessions: 1
Once the FTP control connection is established, the data connection can
select the right firewall using the persistent session that has already been
established.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
CLI EXAMPLES FOR SIP
The CLI example below shows the commands required to configure the AX
device to perform SIP FWLB.
Internal-facing Device
The configurations below are based on the network topology shown in
Figure 134 on page 357 and represent the configuration that must be made
on the internal-facing AX device*.
Configure ACLs
The following commands create a standard ACL, which will be applied to
the internal-facing AX device (“AX5100A”), and will permit traffic from
“SIP client 1”, which is located on the public subnet (1.0.7.0). At the same
time, this ACL will deny all other traffic.
Internal-AX(config)#access-list 2 10 permit 1.0.7.0 0.0.0.255 log
The following commands create standard ACL, which will be applied to the
internal-facing AX device (“AX5100A”), and will permit traffic from the
SIP client and SIP server on the internal subnet (1.0.9.0) while denying all
other traffic.
Internal-AX(config)#access-list 3 10 permit 1.0.9.0 0.0.0.255 log

The following commands create the Ethernet interfaces on the internal-fac-
ing AX device that is connected to the firewalls and to the real servers or
clients. Then, commands are used to enable promiscuous mode on those
interfaces:
Internal-AX(config)#interface ethernet 1
Internal-AX(config-if:ethernet1)#ip address 1.0.9.1 255.255.255.0
Internal-AX(config-if:ethernet1)#ip allow-promiscuous-vip
Internal-AX(config-if:ethernet1)#exit
Internal-AX(config)#interface ethernet 2
Internal-AX(config-if:ethernet1)#ip address 1.0.1.1 255.255.255.0
Internal-AX(config-if:ethernet1)#ip allow-promiscuous-vip
*.
The internal-facing AX device is “AX5100A”.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configure Health Monitor on Internal AX device
The following command creates the health monitor “fw-hc1”, which con-
parent health check, and it will send a ping through the firewall to the AX
interface on the far side of the firewall at IP 1.0.2.1:
Internal-AX(config)#health monitor fw-hc1
Internal-AX(config-health:monitor)#method icmp transparent 1.0.2.1
Configure SIP Clients, Firewall Nodes, and SIP Servers

Next, create a server configuration for the SIP client, “sip-client2”, which is
at IP address 1.0.9.2. This is necessary to ensure the SIP sessions can be
correctly routed across the firewall while maintaining session persistence.
Add wildcard ports at port 0 for both TCP and UDP, both of which are nec-
essary for SIP. In addition, disable Layer 4 health checks on both wildcard
ports.
Internal-AX(config)#slb server sip-client2 1.0.9.2
Internal-AX(config-real server)#port 0 tcp
Internal-AX(config-real server-node port)#no health-check
Internal-AX(config-real server-node port)#port 0 udp
Internal-AX(config-real server-node port)#exit
Internal-AX(config-real server)#exit
Create a server configuration for the firewall node “fw1” (at IP address
1.0.1.2) and firewall node “fw2” (at IP address 1.0.1.3), and assign the “fw-
hc1” health check to both firewall nodes. Use the fire-wall command to tell
the AX device that these two new “SLB servers” are actually firewall nodes.
Add wildcard ports (port 0) to the firewall nodes for TCP and UDP, and dis-
able the Layer 4 health checks for these wildcard ports.
Internal-AX(config)#slb server fw1 1.0.1.2
Internal-AX(config-real server)#health-check fw-hc1
Internal-AX(config-real server)#fire-wall

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Internal-AX(config)#slb server fw2 1.0.1.3

Internal-AX(config-real server)#health-check fw-hc1
Internal-AX(config-real server)#fire-wall
Next, create a server configuration for the SIP server “sip-srv” (at IP
address 1.0.9.3), and add wildcard ports (port 0) for TCP and UDP, while
disabling the Layer 4 health checks on port 0, which are enabled by default.
Internal-AX(config)#slb server sip-srv 1.0.9.3
Internal-AX(config-real server)#no health-check
Create the Service Groups for Clients, Firewalls, and Server

Create two service group “sg-sip-client2-tcp” and “sg-sip-client2-udp” to
manage the clients, and then add the client “sip-client2” to each service
group at port 0.
Internal-AX(config)#slb service-group sg-sip-client2-tcp tcp
Internal-AX(config-slb svc group)#member sip-client2:0
Internal-AX(config-slb svc group)#exit
Internal-AX(config)#slb service-group sg-sip-client2-udp udp
Internal-AX(config-slb svc group)#member sip-client2:0
Use the following commands to create the service groups “sg-fw-tcp1” for
TCP traffic and “sg-fw-udp2” for UDP traffic. These are the service groups

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
that will be used to manage the firewall nodes. Then, add the two firewall
nodes, “fw1” and “fw2”, on port 0 to each service group.
Internal-AX(config)#slb service-group sg-fw-tcp1 tcp
Internal-AX(config-slb svc group)#member fw1:0
Internal-AX(config)#slb service-group sg-fw-udp2 udp
Similarly, create two separate service groups to manage the SIP server. Cre-
ate service group “sg-sip-srv1” for TCP traffic and create “sg-sip-srv2”.
Then, add “sip-srv” as a member of each service group on port 0.
Internal-AX(config)#slb service-group sg-sip-srv1 tcp
Internal-AX(config-slb svc group)#member sip-srv:0
Internal-AX(config)#slb service-group sg-sip-srv2 udp
Internal-AX(config-slb svc group)#member sip-srv:0
Configure a Destination IP Persistence Template

Create a destination-IP persistence template “dtemp1”:
Internal-AX(config)#slb template persist destination-ip dtemp1
Configure Wildcard VIPs on the Internal-facing AX Device

0.0.0.0. This wildcard VIP will be assigned to the internal-facing AX device
(AX5100A), and will be used to handle SIP traffic coming from the firewall
(and from the SIP client on the public network), and going to the internal-
facing AX device.
The previously-created ACL is bound to the wildcard VIP, thus allowing

traffic from SIP client 1, while denying all other traffic.
In addition, port 0 is associated with service group “sg-sip-client2-tcp” and

“sg-sip-client2-udp”, and destination NAT is disabled.
Also, the use-rcv-hop-for-resp use-src-ip-for-dst-persist option is applied to

the wildcards ports for both TCP and UDP, to create a destination persistent

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
session based on the source IP. The no-dest-nat option is applied to the TCP
and UDP service groups to help ensure the session will be matched on both
the source IP and destination IP addresses.
Internal-AX(config)#slb virtual-server fromFW 0.0.0.0 acl 2
Internal-AX(config-slb vserver)#port 0 tcp
Internal-AX(config-slb vserver-vport)#service-group sg-sip-client2-tcp
Internal-AX(config-slb vserver-vport)#use-rcv-hop-for-resp use-src-ip-for-dst-persist
Internal-AX(config-slb vserver-vport)#no-dest-nat
Internal-AX(config-slb vserver-vport)#exit
Internal-AX(config-slb vserver)#port 0 udp
Internal-AX(config-slb vserver-vport)#service-group sg-sip-client2-udp
Internal-AX(config-slb vserver-vport)#use-rcv-hop-for-resp use-src-ip-for-dst-persist

0.0.0.0. This wildcard VIP will be assigned to the internal-facing AX device
(AX5100A), and will be used to handle SIP traffic going to the firewall
from the internal-facing AX device (and originally from the SIP client and
SIP server on the private/internal network).
The previously-created ACL is bound to the wildcard VIP, thus allowing

traffic from internal subnet (that is, SIP client 2 and the SIP server), while
denying all other traffic. In addition, port 0 is associated with service group
“sg-fw-tcp1” and “sg-fw-udp2”. Destination NAT is disabled.
Also, the no-dest-nat option is applied to the TCP and UDP service groups
to help ensure the session will be matched on both the source IP and desti-
nation IP addresses.
Internal-AX(config)#slb virtual-server toFW 0.0.0.0 acl 3
Internal-AX(config-slb vserver)#port 0 tcp
Internal-AX(config-slb vserver-vport)#service-group sg-fw-tcp1
Internal-AX(config-slb vserver-vport)#template persist destination-ip dtemp1
Internal-AX(config-slb vserver)#port 0 udp
Internal-AX(config-slb vserver-vport)#service-group sg-fw-udp2
Internal-AX(config-slb vserver-vport)#template persist destination-ip dtemp1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Verifying Internal-AX SIP Configurations with Show Command
command to verify that a SIP control connection could create a dst-ip-per-
sistent session, as shown below:
Prot Forward Dest Reverse Source Age
--------------------------------------------------------
dst 1.0.7.2:65535 1.0.1.2:65535 300
Total Sessions: 1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
External-facing Device
The configurations below are based on the network topology shown in
Figure 134 on page 357 and represent the configurations that must be made
on the external-facing AX device*.
Configure ACLs
The following command creates a standard ACL, which will be applied to
the external-facing AX device (“AX5100B”), and will permit traffic from
“SIP client 2”, which is located on the private subnet (1.0.9.0). This ACL
will deny all other traffic.
External-AX(config)#access-list 4 10 permit 1.0.9.0 0.0.0.255 log
The following command creates standard ACL, which will be applied to the
external-facing AX device (“AX5100B”), and will permit traffic from SIP
client 1 on the public subnet (1.0.7.0) while denying all other traffic.
External-AX(config)#access-list 5 10 permit 1.0.7.0 0.0.0.255 log

The following commands create the Ethernet interfaces on the external-fac-
ing AX device that is connected to the firewalls and to the SIP client. Pro-
miscuous mode is then enabled on those same interfaces:
External-AX(config)#interface ethernet 1
External-AX(config-if:ethernet1)#ip address 1.0.2.1 255.255.255.0
External-AX(config-if:ethernet1)#ip allow-promiscuous-vip
External-AX(config-if:ethernet1)#exit
External-AX(config)#interface ethernet 2
External-AX(config-if:ethernet1)#ip address 1.0.7.1 255.255.255.0
External-AX(config-if:ethernet1)#ip allow-promiscuous-vip
External-AX(config-if:ethernet1)#exit
*.
The external-facing AX device is “AX5100B”.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Configure Health Monitor on External AX device
The following command creates the health monitor “fw-hc2”, which con-
parent health check by sending a ping through the firewall to the AX
interface on the far side of the firewall at IP 1.0.1.1:
External-AX(config)#health monitor fw-hc2
External-AX(config-health:monitor)#method icmp transparent 1.0.1.1
Configure SIP Clients, Firewall Nodes, and SIP Servers

A server configuration is created for the SIP client, “sip-client1” (at IP
1.0.7.2). This is necessary to ensure the SIP sessions can be correctly routed
across the firewall while maintaining session persistence. Add wildcard
ports (port 0) for both TCP and UDP, both of which are necessary for SIP. In
addition, disable the Layer 4 health checks these wildcard ports.
External-AX(config)#slb server sip-client1 1.0.7.2
External-AX(config-real server)#port 0 tcp
External-AX(config-real server-node port)#exit
External-AX(config-real server)#port 0 udp
External-AX(config-real server)#exit
Create a server configuration for the firewall node “fw1” (at IP 1.0.2.2) and
firewall node “fw2” (at IP 1.0.2.3). Assign the health check created earlier
(“fw-hc2”). Use the fire-wall command to tell the AX device that these two
new SLB server configurations are firewall nodes, and then add wildcard
ports (port 0) to the firewall nodes for TCP and UDP, while disabling the
default layer 4 health checks.
External-AX(config)#slb server fw1 1.0.2.2
External-AX(config-real server)#health-check fw-hc2
External-AX(config-real server)#fire-wall
External-AX(config-real server-node port)#no health-check
External-AX(config-real server-node port)#port 0 udp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
External-AX(config)#slb server fw2 1.0.2.3

External-AX(config-real server)#health-check fw-hc2
External-AX(config-real server)#fire-wall
External-AX(config-real server-node port)#port 0 udp
Note: There is no server configuration required for the SIP server because that
device is connected to the AX5100A, the internal-facing AX device.
Create the Service Groups for Clients, Firewalls, and Server

Create a service group, “sg-sip-client1-tcp” to manage the TCP portion of
the SIP transaction on the client, and then add “sip-client1” on port 0 of the
service group.
External-AX(config)#slb service-group sg-sip-client1-tcp tcp
External-AX(config-slb svc group)#member sip-client1:0
External-AX(config-slb svc group)#exit
Repeat the process above for UDP. Create a service group, “sg-sip-client1-
udp” to manage the UDP portion of the SIP transaction on the client, and
then add “sip-client1” on port 0 of the service group.
External-AX(config)#slb service-group sg-sip-client1-udp udp
External-AX(config-slb svc group)#member sip-client1:0
The following commands create the service groups “sg-fw-tcp3” (TCP) and
“sg-fw-udp4” (UDP), which will be used to manage the firewall nodes. The
two firewall nodes, members “fw1” and “fw2”, are added to port 0 of each
service group.
External-AX(config)#slb service-group sg-fw-tcp3 tcp
External-AX(config-slb svc group)#member fw1:0
External-AX(config)#slb service-group sg-fw-udp4 udp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Note: There is no service group required for the SIP server because that device
is connected to the internal-facing AX device (AX5100A).
Configure a Destination IP Persistence Template

Use the following commands to create a source-IP persistence template
“stemp1” with the incl-dst-ip option enabled:
External-AX(config)#slb template persist source-ip stemp1
External-AX(config-source ip persist)#incl-dst-ip
Configure Wildcard VIPs on the External-facing AX Device

0.0.0.0. This wildcard VIP will be assigned to the external-facing AX
device (AX5100B), and will be used to handle SIP traffic coming from the
firewall, (and from the SIP client on the private network), and going to the
external-facing AX device.
The previously-created ACL is applied to the wildcard VIP, thus allowing

traffic from SIP client 2, while denying all other traffic.
In addition, port 0 is associated with service group “sg-sip-client1-tcp” and

“sg-sip-client1-udp”, and destination NAT is disabled. Also, the use-rcv-
hop-for-resp use-dst-ip-for-src-persist command is applied to the wildcard
ports (port 0), which will cause the response packets to go through the same
firewall as the client’s request packets. The communication and SIP ses-
sions will be load balanced through the same firewall node.
External-AX(config)#slb virtual-server fromFW 0.0.0.0 acl 4
External-AX(config-slb vserver)#port 0 tcp
External-AX(config-slb vserver-vport)#service-group sg-client1-tcp
External-AX(config-slb vserver-vport)#use-rcv-hop-for-resp use-dst-ip-for-src-persist
External-AX(config-slb vserver-vport)#no-dest-nat
External-AX(config-slb vserver-vport)#exit
External-AX(config-slb vserver)#port 0 udp
External-AX(config-slb vserver-vport)#service-group sg-sip-client1-udp
External-AX(config-slb vserver-vport)#use-rcv-hop-for-resp use-dst-ip-for-src-persist

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
0.0.0.0. This wildcard VIP will be assigned to the external-facing AX
device (AX5100B), and will be used to handle SIP traffic coming to the
external-facing AX device from the SIP client. The previously-created ACL
is bound to the wildcard VIP, thus allowing traffic from public network (that
is, SIP client 1), while denying all other traffic. In addition, port 0 is associ-
ated with service group “sg-fw-tcp” and “sg-fw-udp”. Destination NAT is
disabled.
External-AX(config)#slb virtual-server toFW 0.0.0.0 acl 5
External-AX(config-slb vserver)#port 0 tcp
External-AX(config-slb vserver-vport)#service-group sg-fw-tcp3
External-AX(config-slb vserver-vport)#template persist source-ip stemp1
External-AX(config-slb vserver)#port 0 udp
External-AX(config-slb vserver-vport)#service-group sg-fw-udp4
External-AX(config-slb vserver-vport)#template persist source-ip stemp1
Verifying AX5100B SIP Configurations with Show Command

command to see that a SIP session could create the following source-IP per-
sistent sessions, as shown below:
Prot Forward Source Forward Dest Reverse Source Age
------------------------------------------------------------------------------
src 1.0.7.2 1.0.9.3:65535 1.0.2.2:65535 300
src 1.0.7.2 1.0.9.2:65535 1.0.2.2:65535 300
Note that the two sessions in the table are the same. This is because the SIP
session is following the persistent session that has already been established
by the communication session.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Transparent Cache Switching
Overview
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 144 Transparent Cache Switching

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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-0026 - Ver. 2.7.0 11/1/2012
Overview
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 408.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring Layer 4 TCS
High Availability Support
You can deploy TCS in High Availability (HA) configurations. For an
example of TCS deployed in Layer 3 inline mode of HA, see “Configuring
IPv4 TCS in High Availability Layer 3 Inline Mode” on page 410.

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.
5. Configure a virtual server with virtual IP address 0.0.0.0 (the wildcard

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-0026 - Ver. 2.7.0 11/1/2012
CLI Example
The commands in this section implement the TCS configuration shown in

Figure 145.
FIGURE 145 Layer 4 TCS

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-if:ve4)#ip address 192.168.19.1 255.255.255.0
AX(config-if:ve4)#ip allow-promiscuous-vip
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
The following commands configure the interface to the cache server:

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-0026 - Ver. 2.7.0 11/1/2012
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-vport)#service-group sg-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 146 on page 402 shows an example of the first method, which does
not use URL switching rules. Figure 147 on page 403 shows an example of
the second method, which does use URL switching rules.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 146 Layer 7 TCS Without URL Switching Rules

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 147 Layer 7 TCS Using URL Switching Rules

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Service Type HTTP Without URL Switching Rules

To configure this type of Layer 7 TCS:
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 146 on page 402. 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-vport)#service-group sg-tcs

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Example

Figure 147 on page 403. 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
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 148. Only the commands specific to destination-IP persistence are
shown. The other commands are the same as those shown in the previous
sections.
FIGURE 148 TCS with Multiple Cache Servers

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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
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 148.
AX(config-if:ethernet5)#ip cache-spoofing-port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX(config)#slb server cache-rs 110.110.110.10
AX(config-real server)#spoofing-cache

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring IPv4 TCS in High Availability Layer 3 Inline Mode
Configuring IPv4 TCS in High Availability Layer 3 Inline

Mode
You can use High Availability (HA) to provide redundancy and failover for
TCS. This section shows an example for IPv4 Layer 3 inline mode HA.
Layer 3 HA for inline mode is beneficial in network topologies where the
AX interfaces with the clients and cache servers are in the same subnet.
FIGURE 149 TCS in HA Layer 3 Inline Mode

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Interface Parameters
In this configuration, each AX device connects to the client, cache servers,

and content server on a single IP interface:
• AX-1 – Connected on IP interface 10.10.10.1, which is assigned to VE 1
on VLAN 1 containing Ethernet data ports 3-11
• AX-2 – Connected on IP interface 10.10.10.2, which is assigned to VE 1
on VLAN 1 containing Ethernet data ports 3-11
The following interface parameters are required:

• Promiscuous VIP – Must be enabled on the interface connected to cli-
ents, and on the IP interface assigned to the VE on the VLAN containing
the interfaces to the clients, content servers, and cache servers.
• Cache spoofing – If the cache server will spoof client IP addresses when
requesting content from content servers, enable cache spoofing support
on the AX interface connected to the cache server.
• CPU processing – CPU processing is required for Layer 3 inline mode.
Enable it on all interfaces connected to clients, content servers, and
cache servers. Also enable it on the dedicated HA link and on the static
routes to the client and content server subnets.
HA Parameters
This configuration uses the following HA parameters. The last two in this
list apply specifically to inline mode. The other HA parameters apply to all
types of HA configurations.
• HA ID – AX-1 uses HA ID 1. AX-2 uses HA ID 2.
• HA group and priority – A single HA group is configured, with a higher

priority on AX-1.
• Pre-emption – Pre-emption is enabled, to force initial failover to the AX
device with the higher priority.
• HA interfaces – Ethernet interfaces 1, 3, and 6 are configured as HA
interfaces. Interfaces 1 and 3 are the lead interfaces in trunks, so all the
interfaces in these trunks are HA interfaces.
• Session synchronization (connection mirroring) – Each AX device is
enabled, when in Active role, to synchronize its sessions onto the other
AX device.
• Floating IP address – Both AX devices share floating IP address
10.10.10.250 for HA group 1.
• L3-inline mode – This must be enabled on each AX device.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• Restart port list – Interfaces 1 to 5 and interface 9 are designated as
inline-mode restart ports. This includes the AX interfaces with the cli-
ent, cache servers, and content server. Interface 6 is the dedicated HA
link between the AX devices and is not included in the restart list.
SLB Parameters
Real server parameters:

• Port type – A Layer 4 port type, such as TCP, should be used. HA ses-
sion synchronization is supported only for Layer 4 sessions.
• Cache spoofing – If the cache server will spoof client IP addresses when
requesting content from content servers, enable cache spoofing support
on the real server configuration for the cache server.
Service group parameters:

• Type – Typically, the type should be TCP.
• Members – Add the real servers configured for the cache servers.
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. (See “Configuring Layer 7 TCS” on
page 401.) The example in Figure 149 on page 410 does not use Layer 7
switching.
Virtual server parameters:

• VIP – The VIP address must be 0.0.0.0 (a wildcard VIP). The ACL
associated with the VIP must be 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:
• Service type – The service type of the TCS virtual port must be a
Layer 4 service type (TCP).
• HA group – Add the virtual server to the HA group.
• Destination NAT – Destination NAT must be disabled.
• Session synchronization – Enable this feature so that customer sessions

are synchronized from the Active AX device to the standby AX device.
Note: If spoof-caching is enabled, the AX device creates a transparent session

from the cache to the server. This session is not synchronized. However,
the main session from the client to the cache server is always synchro-
nized.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: In the current release, client sessions will be reset if an HA failover
occurs. In most cases, the reset will not be noticeable. However, if a client
is downloading a large file, the reset may be noticeable, because the
download progress is not retained after the session is reset.
Templates
For simplicity, the sample configuration in this section does not use any cus-
tom templates. For information about the templates that can be used with
TCS, see “Application Templates” on page 396.
The following CLI examples show how to implement the configuration

AX-1 Configuration
The following commands configure the links:
AX-1(config)#trunk 1
AX-1(config-trunk:1)#ethernet 1 to 2 ethernet 9
AX-1(config-trunk:1)#trunk 3
AX-1(config-trunk:3)#ethernet 3 to 4
AX-1(config-trunk:3)#vlan 11
AX-1(config-vlan:11)#untagged ethernet 3 to 6
AX-1(config-vlan:11)#tagged ethernet 1 to 2 ethernet 9
AX-1(config-vlan:11)#router-interface ve 1
AX-1(config-vlan:11)#interface ethernet 1
AX-1(config-if:ethernet1)#cpu-process
AX-1(config-if:ethernet1)#interface ethernet 3
AX-1(config-if:ethernet3)#ip allow-promiscuous-vip
AX-1(config-if:ethernet5)#ip cache-spoofing-port
AX-1(config-if:ethernet6)#interface ve 1
AX-1(config-if:ve1)#ip address 10.10.10.1 255.255.255.0
AX-1(config-if:ve1)#ip allow-promiscuous-vip
AX-1(config-if:ve1)#exit
The following commands configure static routes. One of the routes goes to
the subnet on the other side of the router that connects the AX device to the
content servers. The other static route goes to the subnet on the other side of

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
the router that connects the AX device to the client. CPU processing is also
enabled on the routes.
AX-1(config)#ip route 20.20.20.0 /24 10.10.10.20 cpu-process
The following command configures 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:
AX-1(config)#access-list 198 permit ip any host 20.20.20.11 log
The following commands configure the global HA parameters:

AX-1(config)#ha id 1
AX-1(config)#floating-ip 10.10.10.250 ha-group 1
AX-1(config)#ha l3-inline-mode
AX-1(config)#ha restart-port-list ethernet 1 to 5 ethernet 9
The following commands configure real servers for the cache servers:
AX-1(config)#slb server cache1 10.10.10.10
AX-1(config-real server)#spoofing-cache
AX-1(config-real server)#port 80 tcp
AX-1(config-real server-node port)#exit
AX-1(config-real server)#exit
The following commands configure a service group for the real servers:
AX-1(config)#slb service-group sg-cache-80 tcp
AX-1(config-slb svc group)#member cache1:80
AX-1(config-slb svc group)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-1(config)#slb virtual-server wildcard 0.0.0.0 acl 198
AX-1(config-slb vserver)#ha-group 1
AX-1(config-slb vserver)#port 80 tcp
AX-1(config-slb vserver-vport)#service-group sg-cache-80
AX-1(config-slb vserver-vport)#no-dest-nat
AX-1(config-slb vserver-vport)#ha-conn-mirror
AX-2 Configuration
Most of the commands on AX-2 are the same as the ones on AX-1, with the
following exceptions:
• The ip address command on the VE adds a unique IP address (not the
address of the other AX device).
• The ha id command assigns HA ID 2 instead of HA ID 1.
• The ha group command assigns a lower priority to the group.
• The ha conn-mirror command refers to the IP address of AX-1.

AX-2(config-trunk:1)#ethernet 1 to 2 ethernet 9
AX-2(config-trunk:1)#trunk 3
AX-2(config-vlan:11)#tagged ethernet 1 to 2 ethernet 9
AX-2(config-if:ethernet3)#ip allow-promiscuous-vip

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-2(config)#access-list 198 permit ip any host 20.20.20.11 log
AX-2(config)#ha id 2
AX-2(config)#floating-ip 10.10.10.250 ha-group 1
AX-2(config)#ha restart-port-list ethernet 1 to 5 ethernet 9
AX-2(config)#slb service-group sg-cache-80 tcp
AX-2(config)#slb virtual-server wildcard 0.0.0.0 acl 198
AX-2(config-slb vserver-vport)#service-group sg-cache-80

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring IPv6 TCS in High Availability Layer 3 Inline

Mode
Figure 150 shows an example of a TCS deployment in HA Layer 3 Inline
mode.
FIGURE 150 TCS – HA Layer 3 Inline Mode

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The configuration requirements and syntax are the same as for IPv4. The
only difference is use of IPv6 addresses instead of IPv4 addresses.
AX-1 Configuration
The following commands configure the links.
AX-1(config-vlan:21)#vlan 22
AX-1(config-vlan:22)#untagged ethernet 2
AX-1(config-if:ve1)#ipv6 address 2309:e90::2/64
AX-1(config-if:ve1)#interface ve 22
AX-1(config-if:ve22)#ipv6 address 2409:c90::1/64
Note: The cpu-process command is applicable only to models AX 2200,

AX 3200, AX 3200-11, AX 3200-12, AX 3400, AX 5100, AX 5200,
AX 5200-11, and AX 5630. The command is required for TCS HA on
those models. The command does not appear in the CLI on other models
and is not required on those models.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
On models AX 5100, AX 5200, AX 5200-11, and AX 5630, when config-
ured in HA inline mode, all traffic going through the system is examined
by the CPU for processing. Packets are not directly forwarded by the
Layer 2/3 ASIC before examination by the CPU.
The following commands configure static routes. One of the routes goes to
the subnet on the other side of the router that connects the AX device to the
content servers. The other static route goes to the subnet on the other side of
the router that connects the AX device to the client. CPU processing is also
enabled on the routes.
AX-1(config)#ipv6 route 2309:d90::/32 2309:e90::1
AX-1(config)#ipv6 route 2309:f90::/32 2309:e90::3
The following commands configure an IPv6 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:
AX-1(config)#ipv6 access-list ipv6-101
AX-1(config-access-list:ipv6-101)#permit ipv6 any host 2309:f90::10 log
AX-1(config-access-list:ipv6-101)#exit
The following commands configure the global HA parameters:

AX-1(config)#ha id 1 set-id 1
AX-1(config)#ha interface ethernet 1 server-interface no-heartbeat
AX-1(config)#ha interface ethernet 3 router-interface no-heartbeat
AX-1(config)#ha restart-port-list ethernet 1 ethernet 3
AX-1(config)#floating-ip 2409:c90::100 ha-group 1
AX-1(config)#floating-ip 2309:e90::100 ha-group 1
The following commands configure a custom ICMP health monitor with

very short interval and timeout values. In Layer 3 inline HA configurations,
the short interval and timeout values help eliminate traffic disruption fol-
lowing HA failover.
AX-1(config)#health monitor icmp interval 1 timeout 1
The following commands configure ICMP health checking for the upstream
and downstream routers. The health checks help ensure rapid HA failover.
(See the “High Availability” chapter in the AX Series System Configuration
and Administration Guide.) The custom ICMP health monitor configured
above is also used.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-1(config)#slb server up-router 2309:e90::1
AX-1(config-real server)#health-check icmp
AX-1(config)#slb server down-router 2309:e90::3
The following commands configure real servers for the cache servers:
AX-1(config)#slb server cache1-ipv6 2409:c90::5
The following commands configure a service group for the real servers
(cache servers):
AX-1(config)#slb service-group cache-ipv6 tcp
AX-1(config-slb svc group)#member cache1-ipv6:80

AX-1(config)#slb virtual-server wildcard-ipv6 :: ipv6-acl ipv6-101
AX-1(config-slb vserver-vport)#service-group cache-ipv6

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-2 Configuration
Here are the configuration commands for AX-2. Most of the commands are
exactly the same as on AX-1. Only the following values differ:
• IP addresses of the VEs
• HA priority
• IP address for session synchronization (ha conn-mirror)
AX-2(config-vlan:22)#untagged ethernet 2
AX-2(config-if:ve1)#ipv6 address 2309:e90::4/64
AX-2(config)#ipv6 route 2309:d90::/32 2309:e90::1
AX-2(config)#ipv6 route 2309:f90::/32 2309:e90::3

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX-2(config)#ipv6 access-list ipv6-101
AX-2(config-access-list:ipv6-101)#permit ipv6 any host 2309:f90::10 log
AX-2(config-access-list:ipv6-101)#exit
AX-2(config)#ha id 2 set-id 1
AX-2(config)#ha interface ethernet 1 server-interface no-heartbeat
AX-2(config)#ha interface ethernet 3 router-interface no-heartbeat
AX-2(config)#ha restart-port-list ethernet 1 ethernet 3
AX-2(config)#floating-ip 2409:c90::100 ha-group 1
AX-2(config)#floating-ip 2309:e90::100 ha-group 1
AX-2(config)#health monitor icmp interval 1 timeout 1
AX-2(config)#slb server up-router 2309:e90::1
AX-2(config)#slb server down-router 2309:e90::3
AX-2(config)#slb service-group cache-ipv6 tcp
AX-2(config)#slb virtual-server wildcard-ipv6 :: ipv6-acl ipv6-101
AX-2(config-slb vserver-vport)#service-group cache-ipv6

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring TCS for FTP

You can configure the AX device to use cache servers for FTP traffic.
FIGURE 151 Transparent Cache Switching for FTP
When a client sends a request to the FTP server, the AX device intercepts
the request and forwards it to the FTP cache server. The cache server then
forwards the requested content to the AX device, if the content is cached.
The AX device forwards the content to the client.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
If the requested content is not already cached, the cache server obtains the
content from the FTP server and caches it. The AX device forwards the con-
tent to the client.
Each cache server in this example has two physical interfaces. One of the
interfaces receives client requests forwarded by the AX device. The other
interface communicates with the FTP server, and forwards cached content
to the AX device. Only the interfaces that receive client requests from the
AX device need to be configured as real servers.
Note: In this example, the content transferred by FTP is cached on the cache
servers. However, this feature also can be used if the device is a firewall
instead of an FTP cache server. In that case, the firewall is used to exam-
ine the traffic that is transferred to or from the FTP server by the client.
Configuration
To configure TCS for FTP:
and the cache server.
• Enable promiscuous VIP on the AX interface(s) connected to the
clients.
• Enable cache spoofing on the interface(s) connected to the cache
server.
Unless you are using AX model 3000, you also must enable CPU pro-
cessing on each interface. On this AX model, CPU processing is auto-
matically used.
3. Configure a real server for the cache server. Add an FTP port to the
server.
If the cache server will spoof client IP addresses when requesting con-
tent from content servers, enable cache spoofing support.
If the cache server has multiple interfaces, configure a separate real
server for each one.
4. Configure a real server for the next-hop router through which the AX
device will reach the content servers. Add the same FTP port number as
the one on the cache server (for example, port 21). Disable health check-
ing on the port.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
5. Configure a service group for the cache servers and add them to it.
6. Configure a separate service group for the router, and add the router to
it.

Add an FTP virtual port and bind it to the service group containing the
cache server, and to the service group containing the router. Disable des-
tination NAT on the virtual port.
CLI Example
The following commands configure the AX interfaces to the FTP server, the
FTP client, and the cache servers.
AX(config-if:ethernet1)#cpu-process

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.11 log
The following commands configure real servers for FTP on each of the
cache servers. Cache spoofing is enabled and TCP port 21 is added to each
real server.
AX(config)#slb server ftps1 11.11.11.10
AX(config)#slb server ftps2 11.11.11.11
The following commands configure an FTP service group for the cache
server:
AX(config)#slb service-group sg-ftps tcp
AX(config-slb svc group)#member ftps1:21
AX(config-slb svc group)#member ftps2:21
The following commands configure a wildcard VIP traffic and bind it to the
ACL. The FTP virtual port is bound to the FTP and router service groups.
Also, destination NAT is disabled.
AX(config-slb vserver)#port 21 ftp
AX(config-slb vserver-vport)#service-group sg-ftps

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Destination-based Hashing with Wildcard VIPs
The AX device provides a more optimal TCS solution that is based on hash
of the destination IP address for persistence instead of session persistence
based on destination IP address. With this feature, the AX does not create a
persistent session. Instead, the AX device uses a hash based on the available
number of servers that are in an “UP” state in the service group.
Note: Destination persistence templates can be attached only to wildcard VIPs.
Example of How this Feature Works

1. Three cache servers (cache server 1, cache server 2, and cache server 3)
are configured with destination IP hash persistence and bound to a vir-
tual port.
2. Cache server 1 temporarily goes down.
3. Traffic that was persisting to cache server 1 will be distributed between

the remaining two cache servers, cache server 2 and cache server 3 (with
a hash base of 2, since only 2 servers are operational and available to
calculate persistence).
4. Traffic sent to cache server 2 and cache server 3 will continue to be sent
to the servers. This traffic will not be recalculated. Only traffic that is
configured to “persist” to cache server 1 gets recalculated. Redistribu-
tion is resumed and traffic is distributed among the total number of func-
tional servers.
USING THE GUI
To configure destination IP address hash persistence using the GUI, do the

following:
1. Go to Config Mode > Service > Template > Persistent > Destination IP
Persistence.The following screen appears:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
2. Click on Add to view the option to create a template:
3. Enter the following information:
Note: While the template window currently displays several fields, these fields
are not supported in Release 2.7.0 when hash-persistence is enabled.
m. Provide a name for your template.
n. In the Match Type drop down menu, choose Port, Server, or Service
Group. If you choose Server or Service Group, you will also be able
to select a checkbox (that will appear) to be able to Scan All Mem-
bers. The Scan All Members option allows you to select a service-
group member on the same server as the member that is out of ser-
vice. For example, a service group called sg-tcp has the follow-
ing members:
service-group sg-tcp
member s1:80
member s2:8080
member s3:80
member s3:8080
member s3:8081
If s3:80 is designated for a certain request, when port 80 goes
down, the AX device will typically choose an alternate member
among all the remaining options (s1:80, s2:8080, s3:8080,
and s3:8081). With Scan-All-Members enabled, because the orig-
inal persist session had designated server s3:80 for the task, the
AX device will make its choice only between s3:8080 and
s3:8081, because s3 was the original server that was selected
first. Other servers will only be considered if there is a problem with
server S3.
o. Specify a timeout value in minutes for a persist session. In normal
cases of persistence not using hash, the AX will create a persist ses-
sion on the AX, using this persist session, traffic is sent to a specific
server based on this session. Persist templates allow users to specify
the duration of how long they want this session to remain on the
AX. As long as this persist session remains on the AX, a particular
IP (whether it maybe src-ip or dst-ip) will remain persisted to the

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
server shown in the persist session. With that said, because hash-
persist does not create a session on the AX, the timeout value will
actually have no effect when using hash persist.
p. Select the Don’t Honor Conn Rules to ignore the connection limit
rules that are set by a server template. Typically, the AX device
allows users to configure server templates that can limit the connec-
tions allowed per server. However, when you enable the Don’t
Honor Conn Rules option, the AX device will ignore the connection
limit rules that are set by a server template. For example, if server s1
has a template that only allows a maximum of 5 connections, and s1
has been configured for persistence, when10 connections are sent
from the same source IP or to the same destination ip, the 10 con-
nections will go through to server s1. The template limit is ignored
because of enabling the Don’t Honor Conn Rules option.
q. Select the Hash Persistent option to enable destination-ip address
hash persistence.
r. Indicate the Netmask (for your IPv4 Address) in the box provided.
s. Indicate the IPv6 Address Netmask in the box provided.
t. Click on OK. Your new template will be added to the list of Destina-
tion-IP-Persistence templates. In the following example, the newly
added template is called dest-ip-template:
USING THE CLI
From the destination‐ip persist template, configure this TCS feature to

allow for destination IP address hash persistence.
[no] slb template persist destination-ip template-

name

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Example
To configure, view, or remove this feature, follow these steps:

1. To ensure that the destination IP address hash calculation will persist
even after a server fails, enter the following commands, where “dhash”
is the name of the template that you are creating for destination IP hash
persistence:
AX-Active(config)#slb template persist destination-ip dhash
AX-Active(config-destination ip persist)#hash-persist
2. To view the existing configuration, use the show running command:

AX-Active(config-destination ip persist)#show running | section dhash
slb template persist destination-ip dhash
hash-persist
match-type server
3. To remove IP address hash persistence, issue the following command:

AX-Active(config)#no slb template persist destination-ip dhash

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SLB Protocol Translation
SLB Protocol Translation (SLB-PT) enables IPv4 servers to be used for

serving content to IPv6 clients. Likewise, SLB-PT enables IPv6 servers to
be used for serving content to IPv4 clients. Server farms can contain both
IPv4 and IPv6 servers.
SLB-PT is supported for the following virtual port types:

• UDP
• TCP
• HTTP
• HTTPS
• SSL-proxy
• SMTP
Figure 152 shows an example of a SLB-PT deployment that uses a mixed

server farm of IPv4 and IPv6 servers to serve IPv6 clients.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 152 SLB Protocol Translation
In this example, a server farm consisting of IPv6 and IPv4 servers is config-
ured with an IPv6 VIP address. IPv6 clients send requests to the IPv6 VIP.
The AX device then selects an IPv6 or IPv4 server and forwards the client’s
request to the selected server. If the server is an IPv4 server, the AX device
translates the IP protocol of the client’s request from IPv6 to IPv4 before
forwarding it to the IPv4 server. Likewise, when the AX device receives the
servers’s reply, the AX device translates the reply from IPv4 to IPv6, then
forwards the reply to the client.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Source NAT Requirement
In addition to the standard SLB configuration items (servers, service

groups, the VIP, and so on), SLB-PT requires IP source NAT.
As a minimum requirement, a single NAT pool is required, for the IP type

(IPv4 or IPv6) that differs from the IP type of clients. In this example, an
IPv4 pool is required. The pool is used if the AX device selects an IPv4
server for an IPv6 client’s request. The pool must be bound to each of the
virtual ports that has a corresponding real port on an IPv4 server.
If the deployment also will send IPv4 client requests to IPv6 servers, an
IPv6 pool is also required.
For simplicity, the CLI example below uses a single IPv4 NAT pool. Fol-
lowing the example, the “Examples Using Multiple Source NAT Pools” on
page 437 section describes how to use multiple pools.
CLI Example
The following commands configure the SLB-PT deployment shown in

Figure 152 on page 432. All of the CLI commands are also present in AX
2.2.x releases. Unlike previous releases, the AX device does not require the
VIP and real server IP addresses to be of the same IP type (IPv4 or IPv6).
The following commands configure the Ethernet interfaces connected to the

clients and servers:
AX(config-if:ethernet1)#ipv6 address 2001:558:ff4e:2::100/64
AX(config-if:ethernet2)#ipv6 address 2001:32::2020:2001/64
The following command configures an IPv4 source NAT pool.

AX(config)#ip nat pool v4natpool-1 192.168.217.200 192.168.217.202 netmask /24
Note: For simplicity, this example uses only a single pool. If multiple pools are
used, ACLs are also required. The ACLs must match on the client IP
address(es) as the source address. If the real servers and VIP are in differ-
ent subnets, the ACLs also must match on the real server IP address(es) as
the destination address. (For more information, see “Examples Using
Multiple Source NAT Pools” on page 437. Also see the “Network

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Address Translation” chapter in the AX Series System Configuration and

Administration Guide.)
The following commands configure the IPv4 real servers. For simplicity, all
the IPv4 and IPv6 servers have the same real ports.
AX(config)#slb server v4server-1 192.168.217.10
AX(config)#slb server v4server-2 192.168.217.11
The following commands configure the IPv6 real servers:

AX(config)#slb server v6server-1 2001:558:ff4e:2::1
AX(config)#slb server v6server-2 2001:558:ff4e:2::2

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

The following commands configure the service groups. A separate service

group is configured for each application (real port):
AX(config)#slb service-group sgv4v6-http
AX(config-slb service group)#member v4server-1:80
AX(config)#slb service-group sgv4v6-dns
AX(config)#slb service-group sgv4v6-https
AX(config)#slb service-group sgv4v6-smtp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands import an SSL certificate and key, and configure
a client-SSL template to use them. The AX device will use the certificate
and key to terminate SSL sessions between clients and the VIP.
AX(config)#slb ssl-load certificate sslcert.pem scp:
Password []?*********
File name [/]?sslcert.pem
AX(config)#slb ssl-load private-key certkey.pem scp:
Password []?*********
File name [/]?certkey.pem
AX(config)#slb template client-ssl cssl
AX(config-client SSL template)#certsslcert.pem
AX(config-client SSL template)#key certkey.pem

AX(config)#slb virtual-server v6vip 2001:32::2020:2000
AX(config-slb virtual server-slb virtua...)#source-nat pool v4natpool-1
AX(config-slb virtual server-slb virtua...)#service-group sgv4v6-http
AX(config-slb virtual server)#port 53 udp
AX(config-slb virtual server-slb virtua...)#service-group sgv4v6-dns
AX(config-slb virtual server-slb virtua...)#template client-ssl cssl
AX(config-slb virtual server-slb virtua...)#service-group sgv4v6-https
AX(config-slb virtual server)#port 25 smtp
AX(config-slb virtual server-slb virtua...)#service-group sgv4v6-smtp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
EXAMPLES USING MULTIPLE SOURCE NAT POOLS
The example shown above uses only a single NAT pool, for access to the
IPv4 servers. If multiple pools are used, then different CLI syntax is
required.
Multiple IPv4 Pools
Here is an example that uses multiple IPv4 pools.
First, IPv6 ACLs that match on the client IP address(es) are configured. A
separate ACL is required for each NAT pool.
AX(config)#ipv6 access-list v6acl-1
AX(config-access-list:v6acl-1)#permit ipv6 2001:32::/96 any
AX(config-access-list:v6acl-1)#exit
AX(config)#ipv6 access-list v6acl-2
AX(config-access-list:v6acl-2)#permit ipv6 2001:64::/96 any
AX(config-access-list:v6acl-2)#exit
The following commands configure the IPv4 NAT pools:

The following commands access the configuration level for a virtual port on
the VIP and configure the port to use the IPv4 pools:
AX(config)#slb virtual-server v6vip 2001:32::2020:2000
AX(config-slb virtual server-slb virtua...)#access-list name v6acl-1 source-
nat-pool v4natpool-1
Each of the access-list commands binds one of the IPv6 ACLs to the virtual
port. The source-nat-pool option used with each command binds an IPv4
pool to the ACL. When the AX device receives a request for the VIP, the
AX device matches the client address against the source addresses in the
ACLs. The AX device then uses the IPv4 NAT pool bound to the first
matching ACL.
The AX device translates the client’s request from an IPv6 packet into an
IPv4 packet. The AX device replaces the client’s IPv6 address with an IPv4
address from the selected pool. The IPv6 VIP address is replaced with the
server’s IPv4 address.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
If the client’s address does not match the source address in any of the ACLs,
the request is dropped.
Note: This is different from the behavior if a single NAT pool is used. If only
one NAT pool is bound to the virtual port, the pool is used if the client’s
IP type (IPv4 or IPv6) is not the same as the IP type of the selected server.
Otherwise, if the IP type of the client and the selected server is the same,
SLB-PT is not required for the request. The request is sent to the server
with the client’s original IP address.
Multiple IPv4 and IPv6 Pools
It is not required to use pools of the same IP type as the IP type used by cli-
ents. For example, IPv6 pools are not required for IPv6 clients.
Using pools of the same IP type as the client IP type provides a way to con-
trol access to the real servers. When multiple pools are bound to a virtual
port, the client’s IP address must match the source address in at least one of
the ACLs associated with the pools. Otherwise, the client’s traffic is
dropped.
Note: In the case of IPv4, IPv4 pools are still required if the VIP and the real
servers are in different IPv4 subnets. For more information, see the
“Source NAT for Servers in Other Subnets” section in the “Network
Address Translation” chapter of the AX Series System Configuration and
Administration Guide.
This example builds on the example in “Multiple IPv4 Pools” on page 437.
The virtual port will have 4 pools: 2 IPv4 pools and 2 IPv6 pools. Each of
the IPv6 ACLs will be bound to an IPv4 pool and an IPv6 pool. If SLB
selects an IPv4 server, the IPv4 pool bound to the ACL that matches the cli-
ent’s IP address will be used. Likewise, if SLB selects an IPv6 server, the
IPv6 pool bound to the ACL will be used.
The following commands configure the IPv6 NAT pools:

AX(config)#ipv6 nat pool v6natpool-1 2001:32::2020:2010 2001:32::2020:2010 net-
mask 64
AX(config)#ipv6 nat pool v6natpool-2 2001:32::2020:2020 2001:32::2020:2020 net-
mask 64
The following commands bind the IPv6 NAT pools to the virtual port:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
DNS Security
DNS Optimization and Security
This chapter describes the DNS optimization and security features sup-
ported by the AX device.
• Security – DNS security examines DNS queries addressed to a VIP to
ensure that the queries are formed properly. You can enable DNS secu-
rity on individual VIPs. See “DNS Security” on page 439.
• Optimization – The AX device can locally cache DNS replies and serve
the cached replies in response to DNS requests from clients. DNS cach-
ing offloads DNS servers, by caching replies to DNS queries and serv-
ing the cached replies in response to subsequent queries.
You can enable DNS caching globally or on individual VIPs. See the
following sections:
• “Global DNS Optimization” on page 442
• “DNS Optimization per VIP” on page 444
Note: These features are supported only in software releases that support SLB.
DNS Security
You can configure security for DNS VIPs. DNS security examines DNS
queries addressed to a VIP to ensure that the queries are formed properly
(not malformed). If a malformed DNS query is detected, the AX device
takes one of the following actions, depending on the action specified in the
DNS security policy:
• Drops the query
• Forwards the query to another service group – This option is useful if

you want to quarantine and examine the malformed queries, while still
keeping them away from the DNS server.
This feature parses DNS queries based on the following RFCs:

• “RFC 1034: Domain Names – Concepts and Facilities”
• “RFC 1035: Domain Names – Implementation and Specification”
• “RFC 2671 – Extension Mechanisms for DNS (EDNS0)”

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
DNS Security
Sanity Check Details

DNS security performs a sanity check on DNS client requests and, if appli-
cable, DNS server replies.
Sanity Checking for Virtual-Port Type UDP
DNS sanity checking on virtual-port type UDP is performed only for client
requests. For a DNS client request to pass the sanity check, all the following
conditions must be met:
• Flags.qr == 0 (first bit in flags)
• Flags.opcode <=5 (bits 2 to 5 in flags)
• Flags.rcode == 0 (last 4 bits in flags)
• qdcount > 0 (questions in DNS header)
Sanity Checking for Virtual-Port Type DNS-UDP
DNS sanity checking on virtual-port type DNS-UDP is performed for client

requests and server responses.
For a client request to pass the sanity check, all the following conditions
must be met:
• Flags.opcode == 0 (bits 2 to 5 in flags)
• Flags.rcode == 0 (last 4 bits in flags)
• qdcount == 1 (questions in DNS header)
For a server response to pass the sanity check, all the following conditions
must be met:
• Flags.opcode <=5
• Flags.rcode == 0
• qdcount > 0
• ancount > 0 (Answer count)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
DNS Security
Configuring DNS Security

To configure DNS security for a DNS virtual port:
1. Create a DNS template and specify the DNS security action in the tem-
plate.
2. Bind the DNS template to the DNS virtual port.
USING THE GUI

1. Select Config Mode > Service > Template > Application > DNS
> .
2. In the Name field, enter a name for the template.
3. Select Enabled next to DNS Template, if not already selected.
4. Select Malformed Query.
5. Select the action to take for malformed queries:

• Drop
• Forward to Service group. To use this option, select the service
group from the drop-down list.
6. Click OK.
USING THE CLI
To configure DNS security, use the following command at the global con-
figuration level of the CLI:
[no] slb template dns template-name
This command creates the UDP template and changes the CLI to the config-
uration level for the template. Use the following command to enable DNS
security and specify the action to take for malformed DNS queries:
[no] malformed-query
{drop | forward service-group-name}
The drop option drops malformed queries. The forward option sends the
queries to the specified service group. With either option, the malformed
queries are blocked from further processing by the DNS virtual port to
which the template has been applied.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Global DNS Optimization
Configuration Example – DNS Security

The following commands configure a DNS template for DNS security and
bind the template to the DNS virtual port on a virtual server:
AX(config)#slb template dns dns-sec
AX(config-dns-policy)#malformed-query drop
AX(config-dns-policy)#exit
The following commands configure the real server and service group:
AX(config)#slb server dns-sec1 10.10.10.88
AX(config)#slb service-group dns-sec-grp udp
AX(config-slb svc group)#member dns-sec1:53
The following commands bind the service group and DNS template to the
DNS virtual port on a virtual server:
AX(config)#slb virtual-server dnsvip1 192.168.1.53
AX(config-slb vserver-vport)#service-group dns-sec-grp
AX(config-slb vserver-vport)#template dns dns-sec
Since the drop action is specified, malformed DNS queries sent to the vir-
tual DNS server are dropped by the AX device.

The AX device can locally cache replies to DNS queries. When DNS cach-
ing is enabled, the AX device sends the first request for a given name (host-
name, fully-qualified domain name, and so on) to the DNS server. The AX
device caches the reply from the DNS server, and sends the cached reply in
response to the next request for the same name.
The AX device continues to use the cached DNS reply until the reply times
out. After the reply times out, the AX devices sends the next request for the
hostname to the DNS server, and caches the reply, and so on.
DNS caching is disabled by default. When you enable it, replies are cached
for 300 seconds by default. You can change the cache timeout to 1-1000000
seconds. A DNS reply begins aging as soon as it is cached and continues

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
aging even if the cached reply is used after aging starts. Use of a cached
reply does not reset the age of that reply.
Global DNS caching applies only to DNS requests sent to a VIP with vir-
tual-port type udp (on port 53 only) or dns-udp (on port 53 only). DNS
caching is not supported for DNS requests sent to other UDP port numbers
or over TCP.
USING THE GUI

1. Select Config Mode > Service > SLB > Global > Settings.
2. Select Enabled next to DNS Cache field.
3. Optionally, to change the timeout for cached entries, edit the number in
the DNS Cache Age field.
4. Click OK.
USING THE CLI
To enable DNS caching, use the following command at the global configu-
slb dns-cache-enable
[
round-robin [ttl-threshold seconds] |
single-answer [ttl-threshold seconds] |
ttl-threshold seconds
]
By default, replies with a single or multiple IP addresses in the ANSWER

section can be cached.
• The round-robin option rotates the addresses when replying to client
requests. This option is disabled by default.
• The single-answer option caches only replies that have a single IP
address in the ANSWER section. This option is disabled by default.
• The ttl-threshold option specifies the minimum Time-To-Live (TTL) a
reply from the DNS server must have, in order for the AX device to
cache the reply. You can specify 1-10000000 seconds. The default TTL
threshold is 0 (unset).
To change the cache timeout, use the following command at the global con-
slb dns-cache-age seconds

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
DNS Optimization per VIP
You can specify 1-1000000 seconds. The default is 300 seconds.
To display global DNS caching information, use the following command:

show dns cache {client | entry | statistics}

DNS caching per-VIP DNS provides finer control over DNS caching. You
can configure caching policies to tightly control caching behavior.
• DNS caching on per-VIP basis
• DNS caching on per-record basis
• Rate-based DNS caching
• DNS record weighting for selective cache entry aging
• Throttling based on domain name
• Logging of DNS cache hits
Parameters for DNS caching per VIP are configured in the following places:
• Class list
• DNS template
Per-VIP DNS caching applies only to DNS requests sent to a VIP with vir-
tual-port type dns-udp, on any port number. DNS caching is not supported
for DNS requests sent to virtual-port type dns, or requests sent over TCP.
Class-List Parameters for DNS Caching

To control DNS caching based on domain name, you can use a class list. A
class list used for DNS caching has entries in the following format:
match-option domain-string {glid | lid} num
Each entry consists of the following:

• match-option – Specifies the match criteria for the domain-string. The
match-option can be one of the following:
• dns contains – The entry matches if the DNS request is for a
domain name that contains the domain-string anywhere within the
requested domain name.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• dns starts-with – The entry matches if the DNS request is for a
domain name that begins with the domain-string.
• dns ends-with – The entry matches if the DNS request is for a
domain name that ends with the domain-string.
• domain-string – Specifies all or part of the domain name on which to
match.
For wildcard matching on more than one character, you can use the
dns contains, dns starts-with, and dns ends-with options. For exam-
ple, “dns ends-with example.com” matches on both “abc.example.com”
and “www.example.com”.
• {glid | lid} num – Specifies a global limit ID (GLID) or a local limit ID
(LID). Limit IDs contain policies. GLIDs can be used by more than one
DNS template. LIDs are configured within an individual DNS template.
GLIDs / LIDs contain DNS caching policies. The AX device applies the
DNS caching policy in the specified GLID or LID to the domain-string.
Each class list can contain a maximum of 1000 entries or 5000 domain-
string characters.
Example Class List for DNS Caching

dns contains a10networks.com lid 1
dns starts-with www.example1.com lid 2
dns ends-with www.example2.com lid 3
dns contains example3 lid 4
Each class-list entry selects a DNS caching policy, contained in the LIDs,
based on the matching hostname. For example, queries for hostnames that
contain “a10networks.com” are processed using the policy in LID 1.
The LIDs are configured in a DNS template that is applied to the DNS vir-
tual port. (See “DNS Template Parameters” on page 445.)
DNS Template Parameters

You can configure the following DNS caching parameters in DNS tem-
plates:
• DNS caching state – enabled or disabled. DNS caching is enabled by
default. You can easily disable it by setting this parameter, without
changing the configuration of other caching parameters or changing the
configuration settings on the DNS virtual ports that use the template.
• Default caching policy – Specifies the cache action (cache or nocache)
for requests that do not match any domain-string in the class list. The

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
default is nocache. By default, replies for domain names that do not
match the class list are not cached.
• Maximum cache size per AX device – Specifies the maximum number
of DNS replies that can be cached on the AX device. You can specify
from 1 to the maximum allowed on your AX model. The default is the
maximum allowed on your AX model.
Note: This is based on the standard amount of RAM installed in each AX

device. For details, contact A10 Networks.
• Logging – You can enable logging of DNS caching events. (See “DNS
Cache Logging” on page 447.) Logging is disabled by default. When
you enable it, you can specify the number of minutes between genera-
tion of log messages, 1-10000 minutes.
• Class-list LID – Specifies the DNS policy (DNS caching settings) for
domain-strings in the class list.
DNS Caching LID / GLID Policy Parameters
You can configure the following DNS caching policy settings either in a
GLID or in a LID within the DNS template. Settings configured in a GLID
can be used by multiple DNS templates. Settings within the LID in a DNS
template can be used only by that template.
• Caching state – Enabled or disabled
• Connection rate limit – Maximum DNS connection rate allowed before

the over-limit action is applied. (See below.) You can specify
1-4294967295 DNS connections per 1-65535 100-millisecond (ms)
intervals. There is no default.
• Over-limit action – Action to take when the DNS connection or request
limit or rate is exceeded. The default action is to drop the traffic. Option-
ally, you can specify one of the following actions instead:
• Enable caching
• Disable caching
• Forward the traffic anyway
• Lock out further traffic from the sender for the specified number of
minutes, 1-1023. You also can specify a lockout time for any of the
other over-limit actions listed above.
By default, logs are not generated when an over-limit action occurs. You
can enable logging of over-limit actions. The over-limit messages are
sent immediately. They are not queued based on DNS cache logging set-
tings.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• Time-To-Live (TTL) – Number of seconds to keep an entry in the cache
before removing it. You can specify 1-65535 seconds. By default, the
global DNS cache age is used. The default global DNS cache age is 300
seconds (5 minutes).
• Weight – Numeric value used when cache entries need to be removed to
make room for new entries. You can assign a weight of 1-7. Lower-
weighted objects are removed before higher weighted objects.
• Cache more than 60% full, entries with weight 1 are eligible to be
removed.
• Cache more than 70% full, entries with weight 1 or 2 are eligible to
be removed.
• Cache more than 80% full, entries with weights 1-4 are eligible to
be removed.
• Cache more than 90% full, entries with weights 1-6 are eligible to
be removed.
The default weight is 1.
Additional Options (available only in GLIDs)

• Connection limit – Maximum active DNS connections allowed before
the over-limit action is applied. You can specify 1-1048575 DNS con-
nections. There is no default.
• Request limit – Maximum number of DNS requests before the over-
limit action is applied. You can specify 1-1048575. There is no default.
• Request rate limit – Maximum rate of DNS requests before the over-
limit action is applied. You can specify 1-4294967295 DNS requests
every 1-65535 100-millisecond (ms) interval(s). There is no default.
• Use NAT pool – Binds a NAT pool to the GLID. The pool is used to pro-
vide reverse NAT for class-list members that are mapped to this GLID.
DNS Cache Logging

Logging for DNS caching is disabled by default. When you enable it, the
following information is logged:
• Number of DNS cache hits between log intervals or before aging time
• AX management IP address, severity level (6, informational) and

domain name requested

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Here are some examples:
Aug 22 04:05:14 192.168.20.164 a10logd: [DNS-Cache]<6> dns=example.com hits=6
for the last 1 minute interval
Aug 22 04:05:16 192.168.20.164 a10logd: [DNS-Cache]<6> dns=example5.nl hits=5
for the last 1 minute interval
Note: The hits counter is reset to 0 after the messages are sent. The counter is
not cumulative.
Configuration
To configure per-VIP DNS caching:
• Configure a class list that maps domain-strings to GLIDs or LIDs.
• If using GLIDs to specify the DNS caching policies, configure the

GLIDs.
• Configure a DNS template. Specify the name of the class list. Bind the
class list to the GLIDs, or configure the LIDs under the class list.
• Configure a real server for the DNS server. Add UDP port 53 to the real
server.
• Configure a UDP service group and add the real server to it.
• Configure a VIP that uses a virtual port with service type dns-udp. Bind
the DNS template and the service group to the virtual port.
Note: In the service group, stateless load-balancing methods are not supported
with any of the DNS features described in this chapter.
Configure a Class List

You can configure a class list in either of the following ways:
• Use a text editor on a PC or other device to create the list, then import it
onto the AX device.
• Use CLI commands to create the list entries.
For class-list syntax information, see “Class-List Parameters for DNS Cach-
ing” on page 444.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE GUI
Importing a Class List onto the AX Device

1. Select Config Mode > Service > SLB > Class List.
2. Click Import. The Import page appears.
3. In the Name field, enter the filename to use for the imported class list.
4. Select the location of the file to be imported:

• Local – The file is on the PC you are using to run the GUI, or is on
another PC or server in the local network. Go to step 5.
• Remote – The file is on a remote server. Go to step 8.
5. Click Browse and navigate to the location of the class list.
6. Click Open. The path and filename appear in the Source field. Go to
step 13.
7. To use the management interface as the source interface for the connec-
tion to the remote device, select Use Management Port. Otherwise, the
AX device will attempt to reach the remote server through a data inter-
face.
8. Select the file transfer protocol: FTP, TFTP, RCP, or SCP.
9. In the Host field, enter the IP address or hostname of the server on

which the class list file resides.
10. If needed, change the protocol port number in the port field. By default,
the default port number for the selected file transfer protocol is used.
11. In the Location field, enter the directory path and filename.
12. In the User and Password fields, enter the username and password
13. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring a Class List in the GUI
1. Select Config Mode > Service > SLB > Class List > .
2. In the Name field, enter a name for the class list.
3. Select the system location in which to save the class list:

• File – The list is saved in a stand-alone file.
• Config – The list is saved in the startup-config.
Note: If the class list contains 100 or more entries, it is recommended to use the
File option. A class list can be exported only if you use the File option.
4. Select the IP version for class-list entries, IPv4 or IPv6.
5. In the DNS section, configure settings for DNS caching:

a. In the Domain field, enter the domain string on which to match.
b. From the Match Type drop-down list, select the match option:
• Contains
• Starts With
• Ends With
c. Specify the GLID or LID to use for matching traffic:
• Select Global (for GLID) or Local (for LID) from the LID drop-
down list.
• Enter the GLID or LID number, 1-1023.
d. Click Add.
e. Repeat for each domain string on which to match.
6. Click OK. The new class list appears in the class list table.
Note: You can specify the GLID or LID numbers before configuring the GLIDs
or LIDs. The steps for GLID / LID configuration appear in the following
sections in this chapter. Make sure to use the same numbers you specify
here.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI

After the class list is configured, import it onto the AX device, using the fol-
lowing command at the Privileged EXEC or global configuration level of
the CLI:
import class-list file-name url
The file-name specifies the name the class list will have on the AX device.
The url specifies the file transfer protocol, username (if required), and
directory path.
You can enter the entire URL on the command line or press Enter to display
a prompt for each part of the URL. If you enter the entire URL and a pass-
word is required, you will still be prompted for the password. To enter the
entire URL:
You also can export class lists to a remote server, using the following com-
mand:
export class-list file-name url
Configuring a Class List in the CLI

To configure a class list in the CLI, use the following commands:
[no] class-list name [file]
Enter this command at the global configuration level of the CLI.
The file option saves the class list as a separate file. Without this option, the
class list is instead saved in the startup-config. If the class list contains 100
or more entries, it is recommended to use the file option. The file option is
valid only when you create the class list. After you create the list, the list
remains either in the startup-config or in a separate file, depending on
whether you use the file option when you create the list.
Note: A class list can be exported only if you use the file option.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The class-list command creates the class list if it is not already configured,
and changes the CLI to the configuration level for the list, where the follow-
ing command is available. Use the command to configure match rules to
map DNS traffic to LIDs or GLIDs. (See “Class-List Parameters for DNS
Caching” on page 444.)
[no] dns match-option domain-string
{lid | glid} num
Configure the GLIDs
If you plan to configure the DNS caching policies in GLIDs, use the either
of the following methods to configure each GLID. Otherwise, if you plan to
use LIDs configured within the DNS template, go to “Configure a DNS
Template” on page 453.
USING THE GUI
Note: Make sure to use the GLID IDs you specified in the class list.
1. Select Config Mode > Service > SLB > GLID > .
2. In the ID field, enter the GLID ID, 1-1023.
3. In the remaining fields, configure DNS caching settings. (See “DNS

Caching LID / GLID Policy Parameters” on page 446.)
4. Click OK.
USING THE CLI

Use the following command at the global configuration level of the CLI:
[no] glid num

This command creates the GLID and changes the CLI to the configuration
level for it, where the following commands are available.
[no] conn-limit connections

This command specifies the maximum number of concurrent connections
allowed on the DNS virtual port before the over-limit action is applied.
[no] conn-rate-limit connections

per 100-msec-units
This command specifies the maximum DNS connection rate allowed before
the over-limit action is applied.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
[no] over-limit-action
{dns-cache-disable | dns-cache-enable | forward |
lockout minutes}
[lockout minutes]
[log]
This command specifies the action to take when the DNS connection or
request limit or rate is exceeded.
[no] request-limit requests

This command specifies the maximum number of DNS requests allowed
before the over-limit action is applied.
[no] request-rate-limit requests

per 100-msec-units
This command specifies the maximum DNS request rate allowed before the
over-limit action is applied.
[no] dns {cache-disable | cache-enable}

This command disables or enables DNS caching.
[no] dns ttl seconds

This command specifies the number of seconds to keep an entry in the
cache before removing it.
[no] dns weight num

This command specifies the numeric value used when cache entries need to
be removed to make room for new entries.
Configure a DNS Template

To configure a DNS template for DNS caching, use either of the following
methods.
USING THE GUI

1. Select Config Mode > Service > Template > Application > DNS
> .
3. Select Enabled next to DNS Template, if not already selected.
4. To enable logging, enter the number of minutes between log entries in

the Log Period field.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
5. To use the default maximum cache size, leave the Max Cache Size field
blank. Otherwise, to reduce the maximum cache size, enter the maxi-
mum number or replies that can be cached.
6. Select the class list from the Class List drop-down list.
After you select the class-list, additional configuration fields appear.
These fields are for configuring LIDs within the DNS template. If you
are using GLIDs instead, you can ignore these fields and go to step 7.
To configure a LID within this template, do not click OK yet. Instead,
go to “Configuring LIDs in the DNS Template” on page 454.
7. Click OK.
Configuring LIDs in the DNS Template

After you select a class-list on the DNS Template configuration page, con-
figuration fields for the LIDs appear.
1. Select the LID ID from the LID drop-down list.
2. In the remaining fields, configure DNS caching settings for the LID.
(See “DNS Caching LID / GLID Policy Parameters” on page 446.)
3. Click Add. The LID appears in the list.
4. Repeat for each LID.
5. When finished, click OK to complete configuration of the DNS tem-

plate.
USING THE CLI

To configure a DNS template for DNS caching, use the following com-
mands.
For configurable ranges and default values, see “DNS Template Parame-
ters” on page 445.
[no] slb template dns template-name

mand creates the template and changes the CLI to the configuration level
for it, where the following commands are available.
[no] default-policy {cache | nocache}

This command specifies the default action to take for DNS queries for
domain names that do not match an entry in the class list.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
[no] dns-log-enable period minutes
This command enables logging and specifies how often to generate logs.
[no] max-cache-size num

This command specifies the maximum number of replies to cache per DNS
virtual port.
[no] class-list name name

This command specifies the name of the class list to use.
[no] class-list lid num

This command creates an LID and changes the CLI to the configuration
level for it. The LID number can be 1-31.
If you ever need to disable the DNS template without removing the template
from the configuration, use the following command:
[no] disable-dns-template
LID Commands for DNS Caching

The following commands are available at the configuration level for DNS
caching LIDs.

per 100-msec-units
This command specifies the maximum DNS connection rate allowed before
the over-limit action is applied.
[no] over-limit-action
{dns-cache-disable | dns-cache-enable | forward |
lockout minutes | reset}
[lockout minutes]
[log]
This command specifies the action to take when the DNS connection or
request limit or rate is exceeded.
[no] dns {cache-disable | cache-enable}

This command disables or enables DNS caching.
[no] dns ttl seconds

This command specifies the number of seconds to keep an entry in the
cache before removing it.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
[no] dns weight num
This command specifies the numeric value used when cache entries need to
be removed to make room for new entries.
Enable DNS Caching on a VIP
USING THE GUI

On the configuration page for the virtual port:
1. From the Type drop-down list, select DNS-UDP.
2. Enter the protocol port number in the Port field.
3. Select the DNS template from the DNS Template drop-down list.
(If the template is not configured yet, select “create” and see “Configure
a DNS Template” on page 453.)
4. Click OK.
USING THE CLI
To enable DNS caching on a VIP, use the following commands.
At the configuration level for the virtual server, use the following command
to add a dns-udp port to the virtual server:
[no] port portnum dns-udp
Note: The service type must be dns-udp, not dns. DNS caching per VIP is sup-
ported only on dns-udp virtual ports.
port. At this level, use the following command to bind the DNS template to
the virtual port:
[no] template dns template-name
Make sure to also bind a UDP service group to the virtual port. The com-
mands for real server and service group configuration are the same as those
for other types of virtual ports and are not covered in this chapter.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Display DNS Caching Information
This section describes how to access DNS caching configuration informa-

tion and statistics.
USING THE GUI

The current release does not support VIP-based DNS caching statistics in
the GUI.
USING THE CLI
To display DNS cache entries, use the following command:

show dns cache entry
To display the requested domain names and their IP addresses, as well as

limit, rate, and lockout statistics, use the following command:
show dns cache client
To display DNS caching statistics, use the following command:

show dns cache statistics

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration Examples – DNS Optimization

The following subsections show how to configure the types of DNS caching
policies listed at the beginning of this section.
Note: Most of these examples use LIDs configured within the DNS template,
instead of GLIDs. For an example that uses a GLID, see “Rate-Based
DNS Caching with Rate Limiting” on page 460.
Control Caching on Per-VIP Basis

To implement this type of DNS caching policy:
• Configure a DNS caching policy in which the default action is to cache,
and bind it to the DNS virtual port for which you want to cache DNS
replies.
• Configure another DNS caching policy, in which the default action is
not to cache, and bind it to the DNS virtual port for which you do not
want to cache DNS replies.
In this example, the default settings are used for all DNS caching parame-
ters except the default action (cache or no cache).
The following commands configure the DNS caching templates:

AX(config)#slb template dns dns-enable-template
AX(config-dns)#default-policy cache
AX(config-dns)#exit
AX(config)#slb template dns dns-disable-template
AX(config-dns)#default-policy nocache
AX(config-dns)#exit
AX2500(config)#slb server dns-opt 10.10.10.88
AX2500(config-real server)#port 53 udp
AX2500(config-real server-node port)#exit
AX2500(config-real server)#exit
AX2500(config)#slb service-group group53 udp
AX2500(config-slb svc group)#member dns-opt:53
AX2500(config-slb svc group)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands bind the dns-enable-template to a VIP:
AX(config)#slb virtual-server vip-cache 192.168.10.10
AX(config-slb virtual server)#port 53 dns-udp
AX(config-slb virtual server-slb virtua...)#service-group group53
AX(config-slb virtual server-slb virtua...)#template dns dns-enable-template
The following commands bind the dns-disable-template to a different VIP:

AX(config)#slb virtual-server vip-nocache 192.168.10.11
AX(config-slb virtual server-slb virtua...)#template dns dns-disable-template
Note: Since the default action is nocache, the dns-disable-template is not needed
for vip-nocache. The template is used here just as an example.
Control Caching on Per-Record Basis

• Create a class list that contains match rules for the domain names for
which to perform DNS caching. In this example:
• Allow caching of all entries for “example.com”; for example,
“mail.example.com”, “ftp.example.com”, and so on.
• Deny caching of entries for “www.example.com”.
Associate each domain name string with an LID. (Within the DNS tem-
plate, the LIDs will contain specific caching policies.)
• Configure a DNS template with default action nocache, add the class list
to the template, and configure the following LIDs:
• LID 1 – DNS cache-enable
• LID 2 – DNS cache-disable
• Bind the DNS template to the DNS virtual port.
The following commands configure the class list:

AX(config)#class-list dns-record
AX(config-class list)#dns ends-with example.com lid 1
AX(config-class list)#dns contains www.example.com lid 2
AX(config-class list)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands configure the DNS template:
AX(config)#slb template dns dns-template
AX(config-dns)#class-list name dns-record
AX(config-dns)#class-list lid 1
AX(config-dns-lid)#dns cache-enable
AX(config-dns-lid)#exit
AX(config-dns-lid)#dns cache-disable
AX(config-dns)#exit
The following commands bind the DNS template to the DNS virtual port:
AX(config-slb virtual server-slb virtua...)#template dns dns-template
Rate-Based DNS Caching with Rate Limiting

which to perform DNS caching. Associate the URL string with an LID.
• Configure a GLID that enables caching when a specified connection rate
is reached.
• Configure a DNS template that specifies the default action (in this
example, nocache).
Note: Although this example uses a GLID, you can use a LID within the DNS
template instead.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX(config-class list)#dns contains .example2.com glid 1
The following commands configure the GLID:

AX(config)#glid 1
AX(config-global lid)#dns cache-disable
AX(config-global lid)#conn-rate-limit 1000 per 10
AX(config-global lid)#over-limit-action dns-cache-enable
AX(config-global lid)#exit

AX(config-dns)#class-list glid 1
AX(config-dns)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
DNS Record Weighting for Selective Cache Entry Aging

which to perform DNS caching. Associate each URL string with an
LID.
• Configure a DNS template with default action nocache, add the class list
to the template, and configure the following LIDs:
• LID 1 – DNS cache-enable, weight 1
• LID 2 – DNS cache-enable, weight 2

AX(config-class list)#dns contains example-corp1.com lid 1
AX(config-class list)#dns contains example-corp2.com lid 2

AX(config-dns-lid)#dns weight 1
AX(config-dns-lid)#dns weight 2
AX(config-dns)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Throttling Based on Domain Name

• Create a class list that contains match rules for the domain names to
throttle. Associate each URL string with an LID.
• Assign a very low connection or request rate (for example, 1).
• Optionally, enable lockout.

AX(config)#class-list dns-throttle-cl
AX(config-class list)#dns contains example.com lid 1

AX(config)#slb template dns dns-throttle
AX(config-dns)#class-list name dns-throttle-cl
AX(config-dns-lid)#conn-rate-limit 1 per 65535
AX(config-dns-lid)#over-limit-action lockout 1023
AX(config-slb virtual server-slb virtua...)#template dns dns-throttle

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Example – Logging

This example enables logging for DNS caching.
AX(config-dns)#dns-log-enable period 300
Logging for DNS caching will be enabled for each virtual DNS port that
uses this template. Logs will be generated every 300 seconds (5 minutes).
CLI Example – Show Commands
The following commands show DNS caching information.

AX#show dns cache entry
T = Type, C = Class, W = weight
Qlen = Query length, Rlen = Response length
Domain T C Qlen Rlen TTL Age W Hit
-----------------------------------+---+---+-----+-----+-------+-------+--+-------
ad.example.com 1 1 19 127 666 300 2 100
example.com 1 1 16 68 300 240 1 0
www.examplelive.com 1 1 24 142 666 360 2 257
.example2.com 1 1 16 89 666 420 2 0
example-corp1.com 1 1 21 74 666 420 2 11
example-corp2.com 1 1 17 104 666 420 2 12
Notes
• The T (Type) column lists the DNS record type. For a list, see the fol-
lowing: http://en.wikipedia.org/wiki/List_of_DNS_record_types
• If logging is enabled, the Hit counter is reset after each log entry is cre-
ated. (See “DNS Cache Logging” on page 447 and “CLI Example –
Logging” on page 464.)
• The counter in the Age column is always a multiple of 60. This is
because the age is rounded up to the next 60-second cache refresh inter-
val. The AX device refreshes the cache every 60 seconds. An entry that
has aged out is removed at some point during the 60-second cache
refresh.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX#show dns cache client

Client class list statistics:
F = Flag (C-Connection, R-Request), Over-RL = Over rate limit
Domain Destination F Rate Over-RL lock lock-time
-------------------------+---------------------+-+---------+---------+----------+------
ad.example.com 192.22.35.90:53 C 0 0 0 0
example.com 192.22.35.90:53 C 0 0 0 0
www.examplelive.com 192.22.35.90:53 C 0 30 0 0
.example2.com 192.22.35.90:53 C 0 0 0 0
example-corp1.com 192.22.35.90:53 C 0 0 0 0
example-corp2.com 192.22.35.90:53 C 0 0 0 0
AX#show dns cache statistics

Total allocated: 266
Total freed: 96
Total query: 1720
Total server response: 485
Total cache hit: 1218
Query not passed: 0
Response not passed: 0
Response answer not passed: 0
Query encoded: 0
Response encoded: 0
Query with multiple questions: 0
Response with multiple questions: 0
Response with multiple answers: 0
Response with short TTL: 0
Total aged out: 97
Total aged for lower weight: 0
Total stats log sent: 69
Current allocate: 170
Current data allocate: 23

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
RADIUS Message Load Balancing
This chapter describes RADIUS message load balancing and how to config-
ure it.
Overview
The AX device supports load balancing of RADIUS messages in a topology
such as the one shown in Figure 153.
FIGURE 153 RADIUS message load balancing
In this example, all RADIUS requests received by the AX device have the
same source and destination IP addresses. The source address is the address
of a Broadband Remote Access Server (BRAS), 10.11.11.50. The destina-
tion IP address is a RADIUS VIP on the AX device, 10.11.11.90.
In this type of topology, wherein RADIUS requests for multiple clients

arrive at the AX device with the same source and destination addresses,
using a UDP virtual port does not provide load balancing. This is because
the AX device uses the same session for all the requests.
Normally, the AX device sends all traffic on a given session to the same
server. If a UDP virtual port is used, the AX device uses the configured load
balancing method to select a server for the first request, then uses the same
server (and data CPU) for all subsequent requests.
To load balance RADIUS requests in the topology shown in Figure 153,

you can use the RADIUS virtual port type instead of the UDP port type. If

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
you use the RADIUS port type, the AX device load balances RADIUS mes-
sages based on the 1-byte Identifier field in the RADIUS packet headers.
Traffic Flow for RADIUS Message Load Balancing

The first time the AX device receives a RADIUS request with a given
Identifier value, the AX device uses the load balancing method to select a
RADIUS server. Subsequent RADIUS requests with the same Identifier
value go to the same server. However, when the AX device receives a
request with a different Identifier value, the AX device uses the configured
load balancing method to select a server for requests that contain that
Identifier value.
Figure 154 shows the traffic flow for RADIUS message load balancing.
FIGURE 154 RADIUS message load balancing - traffic flow
1. Client sends RADIUS request.
2. Request is forwarded by BRAS.
3. RADIUS VIP on AX device receives the request. AX device selects a

server and sends the request to the server. Subsequent requests with the
same Identifier go to the same server.
4. RADIUS server replies to request.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Protocol Port Numbers Supported with Stateless RADIUS Load

Balancing
Stateless load balancing for RADIUS is supported for the following proto-
col port numbers and ranges:
• 1645
• 1646
• 1812
• 1813
• 12,000 – 28,000
• 42,000 – 58,000
Both the virtual port number and the real port number(s) must be in the list
above, for stateless load balancing to occur.
Note: Stateless load balancing for RADIUS is supported only if the real and vir-
tual port numbers are in the list above.
Load-balancing Method
Models AX 5630, AX 5200-11, AX 3400, and AX 3200-12 perform hard-
ware-based per-packet CPU distribution. Other models perform CPU distri-
bution based on RADIUS request ID.
On models AX 5630, AX 5200-11, AX 3400, and AX 3200-12, to enable

the per-packet CPU distribution, use the Stateless Per-packet Round-robin
load balancing method. (This method is called “Stateless Per-Packet Round
Robin” in the GUI, and stateless-per-pkt-round-robin in the CLI).
Load Balancing Across Data CPUs

To optimize performance, traffic for the RADIUS virtual port type is load
balanced across multiple data CPUs. All requests that have a given
Identifier value go to the same server and are processed by the same data
CPU.
Note: If the virtual port uses source NAT, all traffic for the virtual port is pro-
cessed by the same data CPU, without further load balancing across
CPUs. Depending on the traffic volume, this can affect performance.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Note: Stateless RADIUS load balancing supports only IP Map list static NAT.
Source NAT is not supported in stateless RADIUS mode.
RADIUS Session Aging

Aging of RADIUS sessions is based on the idle-timeout in the UDP
template used by the RADIUS virtual port. The default is 120 seconds.
You also can use the aging option in the UDP template. For example, setting
aging to “immediate” terminates a session as soon as the server responds to
the client.
Configuration
Configuration of RADIUS message load balancing is similar to configura-
tion of other service types:
1. (Optional) To configure connection-rate limiting or request-rate limiting
for the RADIUS ports, configure a real-port template and set the rate
within the template.
2. Create a real server configuration for each RADIUS server.

• Make sure the port number(s) you assign to the RADIUS port(s) are
among those listed in “Protocol Port Numbers Supported with State-
less RADIUS Load Balancing” on page 469.
• If you configure a real-port template (step 1 above), bind the tem-
plate to each of the RADIUS ports in each real-server configuration.
3. Add the real servers to a service group. Configure the group to use the
Stateless Per-packet Round-robin load-balancing method.
4. Create a VIP configuration that has the IP address that will receive the
RADIUS requests. Add a RADIUS virtual port to the VIP. Bind the ser-
vice group created in step 3 to the virtual port.
Note: In the current release, the RADIUS port number on each real server must
be the same. Use of mixed port numbers in the service group is not sup-
ported.
The virtual port number does not need to be the same as the real port num-
ber. These port numbers can differ.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
USING THE GUI
On the configuration page for the virtual port, select RADIUS from the
Type drop-down list.
To view RADIUS sessions:

1. Select Monitor Mode > Service > Session > Session.
2. Select thee RADIUS radio button to filter the display.
USING THE CLI
At the configuration level for the virtual server, use the following com-
mand:
port portnum radius
To view RADIUS sessions, use the following command:

show session radius
CLI Example
The commands in this example implement the RADIUS load balancing
configuration shown in Figure 153 on page 467 and Figure 154 on
page 468.
To begin, the following commands create server configurations for the

RADIUS servers:
AX(config)#slb server radius1 10.11.11.11
AX(config-real server-node port)#slb server radius2 10.11.11.12
The following commands add the servers to a service group:

AX(config-real server-node port)#slb service-group sg-rad udp
AX(config-slb svc group)#member radius1:1812

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
The following commands configure the RADIUS VIP:

AX(config-slb svc group)#slb virtual-server rad-msg-lb 10.11.11.90
AX(config-slb vserver)#port 1812 radius
AX(config-slb vserver-vport)#service-group sg-rad
The following command shows active RADIUS sessions:

AXshow session radius
Traffic Type Total
--------------------------------------------
TCP Established 0
TCP Half Open 0
UDP 30
...
Prot Forward Source Forward Dest Reverse Source Reverse Dest

Age Hash Flags Radius ID
--------------------------------------------------------------------------------------------
------------------------------
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 1 NSe0 104
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 1 NSe0 111
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 1 NSe0 167
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 1 NSe0 118
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 2 NSe0 70
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 2 NSe0 91
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 2 NSe0 84
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 2 NSe0 77
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 2 NSe0 56
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 2 NSe0 119
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 2 NSe0 168
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 162
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 176
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 3 NSe0 239

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 15
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 3 NSe0 134
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 3 NSe0 169
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 204
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 4 NSe0 233
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 4 NSe0 107
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 5 NSe0 171
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 5 NSe0 66
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 5 NSe0 199
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 6 NSe0 221
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 6 NSe0 172
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 6 NSe0 151
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 6 NSe0 25
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 6 NSe0 179
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 7 NSe0 103
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 7 NSe0 222
Total Sessions: 30
The session table contains a separate session for each RADIUS Identifier
value. The following address information is shown for each session:
• Forward Source – The sender of the RADIUS message. In Figure 153
on page 467, this is the IP address of the BRAS.
• Forward Dest – The RADIUS VIP on the AX device.
• Reverse Source – The RADIUS server to which the AX device sends

requests that have the Identifier listed in the RADIUS ID field.
• Reverse Dest – The destination of the RADIUS server reply forwarded
by the AX device. (This is the sender of the initial RADIUS message
that started the session, the BRAS in the example above.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
Overview
However, if there is no Content-Length header, the response will not be
cached.
Warning headers are not supported.
If-Modified-Since Header Support

The AX device supports If-Modified-Since (IMS) headers in GET requests
from clients.
Optionally, a client can include the following header in a GET request:

If-Modified-Since: date-time
This header instructs the content server (or cache server) to send the
requested page only if the page has been modified subsequent to the date
and time specified in the IMS header.
The AX device responds as follows:

• If the requested content is in the cache and is still fresh, but the content
was cached before the date and time in the IMS header, the AX device
sends a 304 – Not Modified response to the client.
• If the requested content is in the cache and is still fresh, and the content
was cached after the date and time in the IMS header, the AX device
sends a 200 – OK response, along with the requested page, to the client.
• If the requested content is not in the cache, or is in the cache but is stale,
the AX device deletes the IMS header from the request. This forces the
server to send a 200 OK response, which is then immediately cached.
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.

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Insertion of Age and Via Headers into Cached Responses
RAM caching supports insertion of Age and Via headers into cached server
replies before they are sent to clients.
• Age header – indicates the age of the cached response, measured in sec-
onds
• Via header – indicates the AX software version, in the following format:
AX-CACHE-software-version(major.minor):last-octet-of-VIP address
Here is an excerpt of a cached server reply containing these headers:

HTTP/1.1 200 OK
Server: AX-3200
Date: Thu, 04 Mar 2010 20:46:23 GMT
Content-Type: text/plain
Content-Length: 4096
Last-Modified: Fri, 29 Jan 2010 00:37:46 GMT
Age: 230
Via: AX-CACHE-2.4:130
Insertion of these headers is enabled by default. You can disable insertion of

the Age and Via headers, in individual RAM caching templates.
Cacheability Behavior of AX RAM Cache

• A response for a request that uses any method other than GET is not
cached.
• A response for a GET request that contains a body is not cached.
• A request that contains an Authorization or a Proxy-Authorization

header is not cacheable. The authorization header contains security-
related information and should not be cached.
• A response for a request that contains an If-Match header or an If-
Unmodified-Since header is not cached.
• An HTTP response which has a Vary header with a value of anything
other than Accept-Encoding is not cached. (The compression module
inserts the Vary: Accept-Encoding header.)
• A response with a Cache-Control header that has one of the following
values: No-Cache, No-Store, Private is not cached.
• If the Cache-Control header has one of the following values: Public,
Must-Revalidate, Proxy-Revalidate, Max-Age, S-Maxage it is cached.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
• Responses that contain a Pragma header are not cached.
• Responses that contain a Set-Cookie or a Set-Cookie2 header are not

cached. (Responses with Cookie headers often contain information that
is specific to the user and so should not be cached.)
• If the response type is FIN terminated, or the response does not have one
of the following attributes: Content-Length, or Transfer-Encoding:
Chunked, it is not cached.
Caching Server Replies in Cookie Persistence Configurations

AX RAM caching does not cache responses that contain cookies. In config-
urations that also use cookie persistence, this behavior prevents server
responses from being cached. You can enable the AX device to remove
cookies from server replies, so that the replies can be cached.
Note: Image files are an exception. RAM caching can cache images that have
cookies.
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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
device serves the content to the client only if the content was cached for
“xyz.com”.
Memory Allocations for RAM Caching

Table 7 lists the amount of memory allocated to RAM caching, for each size
system memory, when you enable the feature. The higher memory alloca-
tion is used by default. You do not need to make any configuration changes.
TABLE 7 RAM caching memory allocation

Memory Allocated to RAM
AX Model Caching When Enabled
AX 5630 24 GB*
AX 5200-11 (on 24 GB
systems with more
than 80 GB)
AX 3530 18 GB
AX 5200-11 12 GB
AX 5200
AX 5100
AX 3400 6 GB
AX 3030 4 GB
AX 3200-12
AX 3000-11-GCF
AX 3000
AX 2600 3 GB
AX 1030
SoftAX (8 GB)† 2 GB
AX 2500
SoftAX (6 GB)† 1.5 GB

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring RAM Caching
TABLE 7 RAM caching memory allocation (Continued)
Memory Allocated to RAM
AX Model Caching When Enabled
AX 3200-11
AX 3200
AX 2200
AX 1000-11
SoftAX (4 GB)† 1 GB
† 500 MB
SoftAX (2 GB)
*. This amount is planned to be increased in an upcoming
release.
†. Amount allocated for the SoftAX in the hypervisor determines
how much of that memory is allocated to RAM caching. RAM
caching is not supported on SoftAX instances allocated less
than 2 GB.

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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 section. To override the
aging period, specify the number of seconds in the Duration field.
d. Click Add.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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

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).
Note: This value is used if the web server specifies that the object is cacheable
but does not specify for how long. If the server does specify how long the
object is cacheable, then the server value is used instead.
[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. The configurable
range and default depend on the AX model. See the CLI or GUI.
[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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
0-268435455 bytes. If you specify 0, no objects can be cached. The default
is 81920 bytes (80 KB).
[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
0-268435455 bytes (4 MB). If you specify 0, all objects smaller than or
equal to the maximum content size can be cached. The default is 512 bytes.
[no] disable-insert-age
Disables insertion of Age headers into cached responses. Insertion of Age
headers is enabled by default.
[no] disable-insert-via
Disables insertion of Via headers into cached responses. Insertion of Via
headers is enabled by default.
[no] remove-cookies
This command enables RAM caching to remove cookies from server replies
so the replies can be cached. (See “Caching Server Replies in Cookie Per-
sistence Configurations” on page 478.)
[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. In the
current release, matching is performed based on containment. All URIs that
contain the pattern string match the rule. For example, the following policy
matches all URIs that contain the string “.jpg” and sets the cache timeout for
the matching objects to 7200 seconds: policy uri .jpg cache 7200
The other options specify the action to take for URIs that match the pattern:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• 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.
Note: Wildcard characters (for example: ? and *) are not supported in RAM
Caching policies. For example, if the string pattern contains “*”, it is
interpreted literally, as the “*” character.
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
[uri-pattern]
To clear individual objects based on URI pattern, use the uri-pattern option.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
Bytes Served 0
Entries Cached 6
Entries Replaced 0
Entries Aged Out 0
Entries Cleaned 0
Total Requests 0
Cacheable Requests 0
No-cache Requests 0
No-cache Responses 0
IMS Requests 0
304 Responses 0
Revalidation Successes 0
Revalidation Failures 0
Policy URI nocache 0
Policy URI cache 0
Policy URI invalidate 0
Content Too Big 0
Content Too Small 0
Srvr Resp - Cont Len 220
Srvr Resp - Chnk Enc 37
Srvr Resp - 304 Status 0
Srvr Resp - Other 0
Cache Resp - No Comp 383579
Cache Resp - Gzip 0
Cache Resp - Deflate 0
Cache Resp - Other 0
Entry create failures 0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following command shows cached objects.
AX#show slb cache entries cached-vip 80
cached-vip:80
Host Object URL Bytes Type Status Expires in
---------------------------------------------------------------------------------------
-----------------------------------
10.20.0.130 /16k.html 16744 CL, No FR 165 s
10.20.0.130 /4k.html 4303 CL, No FR 166 s
10.20.0.130 /32k.html 32976 CE, No FR 169 s
10.20.0.130 /1024k.html 108786 CL, Gz FR 162 s
10.20.0.130 /8k.html 8399 CE, No FR 165 s
10.20.0.130 /64k.html 65744 CE, Gz FR 168 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-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
For information about health monitoring of the AX device’s nexthop gate-

ways, see the “Gateway Health Monitoring” chapter in the AX Series Sys-
tem Configuration and Administration Guide.
Default Health Checks

The AX device performs the following types of health checks by default:
• Layer 3 ping – Every 5 seconds, 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. If the
server does not reply after the fourth attempt (the first attempt followed
by 3 retries), the AX device sets the server state to DOWN.
• Layer 4 TCP – Every 5 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 it replies to the AX device by sending a TCP
SYN ACK. If the port does not reply after the fourth attempt, the AX
device sets the port state to DOWN.
• Layer 4 UDP – Every 5 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 it either does not reply, or replies with any
type of packet except an ICMP Error message. If the port replies with an
ICMP Error message, the AX device sets the port state to DOWN.
The default ICMP, TCP, or UDP monitor is not used if you disable it on the
server or port, or you apply a different monitor to the server or port.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Method Timers
Note: In the GUI, on the server configuration page, the default health monitors
appear as “(default)” in the Health Monitor drop-down lists for the server
itself and for the individual TCP or UDP ports.
For the server itself, “(default)” means the Layer 3 ping described above.
For TCP ports, “(default)” means the Layer 4 TCP health monitor
described above. Likewise, for UDP ports, “(default)” means the Layer 4
UDP health monitor described above.
On a new AX device, the Health Monitor list contains one health monitor,
“ping”. This health monitor is the same as the “default” server health
monitor. The list does not contain the default TCP or UDP health moni-
tors.
Health-check Guidelines
By default, Layer 3 health checking of real server IP addresses is enabled.
Likewise, Layer 4 (TCP and UDP) health checking of server ports is
enabled by default.
Layer 3 health checking can be CPU-intensive. To help reduce unnecessary

processing overhead, if you are using Layer 4 or Layer 7 health checking of
a real server’s ports, it is recommended to disable Layer 3 health checking
of that server’s IP address.
For very large deployments (1000 or more servers), A10 Networks recom-
mends disabling the default Layer 3 health check, and using only Layer 4-7
health checks. (See “Globally Disabling Layer 3 Health Checks” on
page 534.)

Health methods operate based on the following timers:
• Interval – Number of seconds between health check attempts.
Determination of the server or port’s health is not made within the inter-
val. Instead, determination of health is made after the server or port
passes or fails one of the attempts (intervals), or the number of retries is
exhausted.
The default interval is 5 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
again (if there are retries left) or marks the server or service down. You
can specify 1-60 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 496.)
• 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-5. 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 529.)
Note: The default interval and timeout can be adjusted automatically by health-
check rate limiting. (See “Health-check Rate Limiting” on page 535.)
Note: The timeout does not apply to externally configured health monitors.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Check Operation

The figures in this section show how health checking operates.
Example When Server or Port Is Unresponsive

Figure 155 shows how health checking operates when the server or port is
unresponsive.
After each interval, the AX device immediately begins the next health
check, because the next interval begins immediately after the previous
attempt times out. In the figures, “R” indicates a retry.
FIGURE 155 Health Checks Using Default Settings – Server or Port Is

Unresponsive

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Example When Server or Port Is Responsive
Figure 156 shows how health checking operates when the server or port is
responsive. The AX device begins the next health check when the next
interval begins. Using the default interval value, the next interval begins
within 5 seconds.
FIGURE 156 Health Checks Using Default Settings – Server or Port

Responds

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Method Types
Health Method Types

Table 8 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 506.
TABLE 8 Internal Health Method Types

Configuration Required
Type Description Successful If... on Target Server
Database AX device sends a query to the Server sends a reply with the Database must contain the
database. The database can be expected query results. queried data.
one of the following types: For replies that consist of multi- Requested user name and
• Oracle ple results, the results are in a password must be valid on the
• MSSQL table. You can specify the row server.
and column location within the
• MySQL
results table to use as the receive
• PostgreSQL string.
(For more information, see
“Database Health Monitors” on
page 538.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Method Types
TABLE 8 Internal Health Method Types (Continued)
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 514.)
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Method Types
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 511.) 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.
(cont.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Method Types
HTTP / For HTTPS health checks, the
HTTPS AX device encapsulates SSLv3,
(cont.) TLSv1, or TLSv1.1 hello mes-
sages within the SSLv2 hello
messages by default. You can
disable this encapsulation.
Note: The current release sup-
ports SSL 3.0 and SSL 3.1 (TLS
1.0) for HTTPS health checks.
SSL 3.2 (TLS 1.1) and SSL 3.3
(TLS 1.2) are not supported.
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.
IMAP AX Series sends an IMAP 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.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Method Types
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.
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 ->
<- FIN-ACK
ACK ->
(cont.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health Method Types
TCP To configure the AX device to
(cont.) 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.
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 531.)
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 517.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring and Applying a Health Method

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

To configure an internal monitor
2. Click Add.
3. In the Health Monitor section, enter a name for the monitor.
4. In the Method section, 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 496.)
5. Enter or select settings for the monitor.
6. 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 “Using External
Health Methods” on page 547.)
2. In the AX management GUI, select Config Mode > 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 section 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 717.)
6. Click OK.
To apply a health monitor to a real service port template

3. To edit an existing template, click on the template name. To create a new

template, click Add.
The Server Port Template section 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 717.)
6. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To apply the monitor to an individual real server or service port:
Note: Layer 3 health checking can be CPU-intensive. To help reduce unneces-

sary processing overhead, if you are using Layer 4 or Layer 7 health
checking of a real server’s ports, it is recommended to disable Layer 3
health checking of that server’s IP address.
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 in the General section.
5. To apply a health monitor to a service port:

a. In the Port section, click the checkbox next to the service port to
select it.
b. Select the health monitor from the Health Monitor drop-down list in
the Port section.
c. Click Update.
6. Enter or change other settings if needed.
7. Click OK.
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 in the
Service Group section.
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 521.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 496. 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.
To import an externally configured monitor

1. Create a Tcl script for the monitor. (For an example, see “Using Exter-
nal Health Methods” on page 547.)
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
directory path.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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]
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
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
checks, and then addressed to the specific protocol port. You can use the
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 “More SLB Deployment Examples”
on page 63.
Note: External health monitoring is not currently supported for DSR deploy-
ments.
USING THE GUI

address:
2. Click Add. The Health Monitor section appears.
3. Enter a name for the monitor.
4. In the Type drop-down list, select ICMP.
5. Select Transparent.
6. In the Alias Address field, enter the loopback address.
7. Click Apply or OK.

2. Select Enabled next to DSR Health Check.
3. Click Apply.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI

address:
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.
Use the following command at the global Config level of the CLI:
slb dsr-health-check-enable
Using Send and Receive Strings in TCP Health Checks

The AX device supports use of send and receive text strings in TCP health
checks. Send and receive string allow you to add additional intelligence to
TCP health monitors. The AX device sends the specified send string to the
target TCP port, and watches for the specified reply.
For example, you can configure a send string that is an HTTP GET request,
and specify the response string the server must send in reply to the GET
request. (See the CLI example below.)
TCP health monitors that include send and receive strings work as follows:
1. The AX device performs the TCP three-way handshake with the TCP
port on the server:
AX Server
SYN ->
<- SYN-ACK
ACK ->

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
2. If the three-way handshake is successful, the AX device sends the entire
send string to the TCP port.
AX Server
ACK ->
3. If the port’s reply contains the specified receive string anywhere within
the reply, the port passes the health check.
AX Server
<- ACK
4. The AX device and server complete the handshake.

AX Server
FIN ->
<- FIN-ACK
ACK ->
USING THE GUI
On the configuration page for the TCP health monitor, enter the send string
in the Send field, and enter the receive string in the Receive field.
Each string can be 1-127 characters long. Do not use quotation marks
around either string.
USING THE CLI
At the configuration level for the health monitor, use the following com-
mand:
[no] method tcp port portnum send send-string

response contains response-string
The port option specifies the TCP port number to which to send the health
checks.
The send-string is the string the AX device sends to the TCP port after the
three-way handshake is completed. The response-string is the string that
must be present in the server reply. Each string can be 1-127 characters
long. If a string contain blank spaces or other special characters (for exam-
ple, “ / ” or “ \ ”), use double quotation marks around the entire string.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: The following syntax, supported in previous releases, also is supported in
the current release: tcp port portnum [halfopen]
CLI Example
The following commands configure a TCP health monitor that sends an
HTTP GET request to TCP port 80, and expects the string “200” to be
present in the reply:
AX(config)#health monitor tcp-with-http-get
AX(config-health:monitor)#method tcp port 80 send "GET / HTTP/1.1\r\nHost:
22.1.2.2\r\nUser-Agent: a10\r\nAccept: */*\r\n\r\n" response contains 200
This health monitor sends an HTTP GET request to TCP port 80 on the tar-
get server. This particular request uses the following header fields:
• Host – Specifies the host (server) to which the request is being sent.
• User-Agent – Identifies the entity (user agent) that is sending the

request. In this example, the sending entity is “a10”.
• Accept – Specifies the types of media that are allowed in the response.
This example uses wildcards (*/*) to indicate that any valid media type
and range are acceptable.
If the string “200” is present anywhere in the reply from the port, the port
passes the health check.
Certificate and Key Support in HTTPS Health Monitors
You can add an SSL certificate and key to an HTTPS health monitor. When
you use this option, the AX device uses the certificate and key during the
SSL handshake with the HTTPS port on the server.
The certificate you plan to use with the health monitor must be present on
the AX device before you configure the health monitor.
USING THE GUI
On the configuration page for the HTTPS health monitor, select the certifi-
cate name and key, and enter the pass phrase (if applicable)
USING THE CLI
To add a certificate and key to an HTTPS health monitor, use the cert and
key options with the method https command.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Example
The following commands configure an HTTPS health monitor that uses a
certificate:
AX(config)#health monitor https-with-key
AX(config-health:monitor)#method https cert cert-for-health-checks key key1
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. In the Health Monitor section, enter a name for the monitor in the Name
field.
4. In the Method section, 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&fieldname2=value. The
string can be up to 255 bytes long.
6. Configure other settings as needed.
7. Click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 157 HTTP Health Monitor with POST Operation
USING THE CLI

To configure an HTTP or HTTPS health monitor, use the following com-
mands:
[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-0026 - Ver. 2.7.0 11/1/2012
[no] method http
[port port-num]
[url {GET | HEAD} url-path |
POST {url-path postdata string |
/ postfile filename}]
[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 |
/ postfile filename}]
[host {ipv4-addr | ipv6-addr | domain-name}
[:port-num]]
[expect {string | response-code code-list}]
[username name]
[disable-sslv2hello]
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&fieldname2=value. The string can be
up to 255 bytes long.
To use POST data longer than 255 bytes, you must import a POST data file
and use the POST / postfile filename option. To import POST data file up to
2 Kbytes long, use the following command at the global configuration level
of the CLI:
health postfile import filename
CLI Examples
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
The following commands import a file containing a large HTTP POST data
payload (up to 2 Kbytes), and add the payload to an HTTP health monitor:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX(config)#health postfile import long-post
AX(config)#health monitor http1
AX2000(config-health:monitor)#method http url post / postfile long-post expect
def
In this example, health checks that use this health monitor will send a POST
request containing the data in “postfile”, and expect the string “def” in
response.
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
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE GUI
2. Click Add.
3. In the Health Monitor section, enter a name for the monitor in the NAme
field.
4. In the Method section, select DNS from the Type drop-down list. Con-
figuration 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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 158 DNS Health
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-0026 - Ver. 2.7.0 11/1/2012
[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
DNS Health Monitoring over TCP

The AX device also supports use of DNS health monitoring over TCP.
USING THE GUI

On the configuration page for the DNS health monitor, select the DNS
Transport over TCP option.
USING THE CLI
To enable use of TCP instead of UDP for a DNS health monitor, use the tcp
option with the method dns command. (See the CLI example below.)
CLI Example
The following commands configure a health monitor for DNS over TCP:
AX(config)#health monitor dns-tcp
AX(config-health:monitor)#method dns domain www.example.com tcp
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
FIGURE 159 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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,
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
The following commands configure a health monitor for the service IPs
shown in Figure 159 on page 518, 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
Basing a Port’s Health Status on Another Port’s Health Status

You can configure the AX device to base a real port’s health status on the
health status of another port number.
Both the real port and the port to use for the real port’s health status must be
the same type, TCP or UDP.
USING THE GUI

1. Navigate to the configuration page for the real server.
2. In the port configuration section, select the Follow Port radio button.
3. Enter the port number of the TCP or UDP port upon which to base the
health of the real port.
4. Select the Layer 4 protocol of the port to use for health checking, TCP
or UDP.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Service Group Health Checks
USING THE CLI
Use the following command at the configuration level for the real port:
[no] health-check follow-port port-num

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.
FIGURE 160 Service Group Health Checks
In this example, a single server provides content for the following sites:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• 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
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

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.
Health checks can be applied to the same resource (real server or port) at the
following levels:
• In a service group that contains the server and port as a member
• In a server or server port configuration template that is bound to the

server or port
• Directly on the individual server or port
In cases where health checks are applied at multiple levels, they have the
following priority:
1. Health check on real server
2. Health check on real server’s port
3. Health check on service group

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
If a health check at the real server level (1) fails, the corresponding real
server, real server port, and service group members are marked Down.
However, if a health check on the service group level (3) fails, only that ser-
vice group member in that service group is marked Down.
To assign a health monitor to a service group, use either of the following

methods.
USING THE GUI
In the Service Group configuration section, 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 160.
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Disable Following Failed Health Check
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
AX(config)#slb virtual-server media-wxyz 192.168.1.12
AX(config-slb vserver-vport)#service-group wxyz
Disable Following Failed Health Check

You can configure the AX device to disable a server, port, or service group
if the server, port, or service group fails a health check.
This option applies to all servers, ports, or service groups that use the health
monitor. When a server, port, or service group is disabled based on this
command, the server, port, or service group’s state is changed to disable in
the running-config. If you save the configuration while the server, port, or
service group is disabled, the state change is written to the startup-config.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
In-Band Health Monitoring
The AX device also generates a log message to indicate that the server, port,
or service group is disabled.
The server, port, or service group remains disabled until you explicitly
enable it.
This option is disabled by default. (A server, port, or service group that uses
the health monitor is not disabled if it fails a health check.)
USING THE GUI

3. Select the Disable After Down checkbox.
4. When finished configuring the health monitor, click OK.
USING THE CLI
Use the following command at the configuration level for the health moni-
tor:
[no] disable-after-down

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 process 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 process:

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.
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 process.
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:
3. Click on the template name or click Add to create a new one.
4. Select Inband Health Check in the Server Port section.
5. In the Retry field, enter the number of retries allowed.
6. In the Reassign field, enter the number of reassignments allowed.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 725.
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]
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-real server-node port)#template port rp-tmplt2
AX(config-real server-node port)#template port rp-tmplt2

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Consecutive Health Checks Within a Health Check Period
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

2. Click on the monitor name or click Add to add a new one.
3. In the Health Monitor section, enter a name for the monitor (if new).
4. In the Consec Pass Req’d field, enter the number of consecutive times
the target must pass the same periodic health check.
5. If new, in the Method section, select the monitor type from the Type
drop-down list, and enter or select settings for the monitor.
6. Click OK.
USING THE CLI
Use the up-retry number option with the health-monitor command.
Maintenance Health Status for Servers in Persistence

Configurations
You can use the response to an HTTP or HTTPS health check to set a
server’s health status to “Maintenance”. When a server’s health status is
Maintenance, the server will accept new requests on existing cookie-persis-
tent or source-IP persistent connections, but will not accept any other
requests.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Maintenance Health Status for Servers in Persistence Configurations
To place a server into maintenance mode, configure an HTTP or HTTPS
health method that includes a maintenance code. If the server replies to a
health check with the code, the AX device changes the server’s health status
to Maintenance.
To leave maintenance mode, the server must do one of the following:

• Successfully reply to a health check, but without including the mainte-
nance code. In this case, the server’s health status changes to Up.
• Fail a health check. In this case, the server’s status changes to Down.
The Maintenance health status applies to server ports and service-group

members. When a port’s status changes to Maintenance, this change applies
to all service-group members that use the port.
Note: This feature applies only to servers in cookie-persistence or source-IP

persistence configurations, and can be used only for HTTP and HTTPS
ports.
USING THE GUI

3. In the Maintenance Code field, enter the response code to use to trigger
the AX device to change the server’s status to Maintenance.
4. When finished configuring the health monitor, click OK.
USING THE CLI
Use the maintenance-code code-list option with one of the following com-
mands at the configuration level for a health method:
http options
https options
CLI Example
The following commands configure a health monitor that places a server

into maintenance mode if the server replies to a health check with code 601:
AX(config)#health monitor hm2
AX(config-health:monitor)#method http url GET / maintenance-code 601 expect 200

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
On-Demand Health Checks
In this example, if the server replies with code 601, the server goes into
maintenance mode, and stays there until the server either fails a health
check (Down) or replies with code 200 (Up).
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]
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Enabling Strict Retries
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.
Enabling Strict Retries

Some types of health monitors do not use the retry parameter by default. For
these health monitors, the AX device marks the server or port Down after
the first failed health check attempt, even if the retries option for the health
monitor is set to higher than 0.
For example, this is true for HTTP health monitors that expect a string in the
server reply. If the server’s HTTP port does not reply to the first health
check attempt with the expected string, the AX device immediately marks
the port Down.
To force the AX device to wait until all retries are unsuccessful before
marking a server or port down, enable strict retries. You can enable strict
retries on an individual health monitor basis.
USING THE GUI
On the configuration page for the health monitor, select the Strictly Retry
checkbox.
USING THE CLI
Use the following command at the configuration level for the health moni-
tor:
[no] strictly-retry-on-server-error-response

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Globally Changing Health Monitor Parameters
CLI Example
The following commands configure an HTTP health monitor that checks for
the presence of “testpage.html”, and enable strict retries for the monitor.
AX(config)#health monitor http-exhaust
AX(config-health:monitor)#method http url GET /testpage.html
AX(config-health:monitor)#strictly-retry-on-server-error-response

You can globally change the following health monitor parameters:
• Interval – Number of seconds between health check attempts.
• Timeout – Number of seconds the AX device waits for a reply to a

health check.
• 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.
• Up-Retry – Number of consecutive times the device must pass the same
periodic health check, in order to be marked Up.
Globally changing a health monitor parameter changes the default for that
parameter. For example, if you globally change the interval from 5 seconds
to 10 seconds, the default interval becomes 10 seconds.
If a parameter is explicitly set on a health monitor, globally changing the

parameter does not affect the health monitor. For example, if the interval on
health monitor hm1 is explicitly set to 20 seconds, the interval remains 20
seconds on hm1 regardless of the global setting.
Note: Global health monitor parameter changes automatically apply to all new
health monitors configured after the change. To apply a global health
monitor parameter change to health monitors that were configured before
the change, you must reboot the AX device.
Note: When the auto-adjust mode for health-check rate limiting is enabled, and
the global interval or timeout setting differs from the setting on an indi-
vidual health monitor, the actual interval and timeout values that are used
depend on the number of health checks performed by the AX device. (See
“Health-check Rate Limiting” on page 535.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To globally change health monitor parameters, use the following command
at the global configuration level of the CLI:
health global
{
interval seconds |
retry number |
timeout seconds |
up-retry number
}
You can change one or more parameters on the same command line.
Note: To change a global parameter back to its factory default, use the
health global form of the command and specify the parameter value to
use.
CLI Example
The following command globally changes the default number of retries to 5:

AX(config)#health global retry 5
The following command globally changes the timeout to 10 seconds and

default number of retries to 4:
AX(config)#health global timeout 10 retry 4
Globally Disabling Layer 3 Health Checks

Layer 3 health checks (ICMP pings) are enabled by default. For very large
deployments (1000 or more servers), A10 Networks recommends disabling
the default Layer 3 health check, and using only Layer 4-7 health checks.
To globally disable Layer 3 health checks, disable health monitoring in the

server templates used to configure the servers. If you did not configure a
customized server template, the default server template is used.
Note: If a custom Layer 3 health monitor is enabled on an individual server, the

health monitor is still used.
USING THE GUI

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health-check Rate Limiting
3. Click on the name of the server template used to configure the servers. If
you did not configure a server template, click “default” to edit the
default server template.
4. Select the blank option from the Health Monitor drop-down list. (Do not
leave “default” selected.)
5. Click OK.
USING THE CLI
At the global configuration level of the CLI, use the following command to
access the configuration level for the server template:
slb template server template-name
Use the following command to disable Layer 3 health monitoring in the

template:
no health-check
CLI Example
The following commands disable Layer 3 health monitoring in the default
server template:
AX(config)#slb template server default
AX(config-rserver)#no health-check

Health-check rate limiting helps ensure that health checks in large SLB
deployments can be processed successfully. In previous releases, without
health-check rate limiting, it is possible for a server or port to fail its health
check because the AX device is unable to complete processing of the health
check before it times out.
Note: Health-check rate limiting is enabled by default. Generally, you do not

need to configure it. However, you still may want to see the following
section: “Health-check Guidelines” on page 492.
Health-check rate limiting uses a threshold to limit the number of health-

check packets the AX device will send within a given 500-millisecond (ms)
period. If additional health-check packets need to be sent, the AX device
waits until the next 500-ms period. Within any 500-ms period, the AX
device never sends more health-check packets than are allowed by the
threshold.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Health-check rate limiting has an auto-adjust mode, which is enabled by
default. When necessary, the auto-adjust mode dynamically increases the
default interval and timeout for health checks. By increasing these timers,
health-check rate limiting provides more time for health-check processing.
Health-check rate limiting is always enabled, and its auto-adjust mode is

enabled by default.
Health-check Threshold
When auto-adjust mode is enabled, the health-check threshold is one of the
following:
• AX models with 64-bit ACOS – 1600 health-check packets per 500-ms
period
period
When auto-adjust mode is enabled, you can not manually change the thresh-
old. To change the threshold, you first must disable auto-adjust mode. Then
you can set the threshold to a value within one of the following ranges:
• AX models with 64-bit ACOS – 1-5000 health-check packets per 500-
ms period
• AX models with 32-bit ACOS – 1-2000 health-check packets per 500-
ms period
When you disable auto-adjust mode, the default threshold is changed to one
of the following:
period
period
Note: It is recommended not to set the threshold to a very high value. Doing so
may result in health-check timeouts due to resource constraints.
Health-check Interval and Timeout

When the auto-adjust mode for health-check rate limiting is enabled, and
the global interval or timeout setting differs from the setting on an individ-
ual health monitor, the actual interval and timeout values that are used
depend on the number of health checks performed by the AX device:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• More than 1000 health checks (64-bit models) or more than 400 health
checks (32-bit models) – Setting with the longer value is used. For
example, if the global interval is 10 seconds but the interval configured
on an individual health monitor is 5 seconds, 10 seconds is used.
• Fewer than 1000 health checks (64-bit models) or fewer than 400 health
checks (32-bit models) – Setting on the individual health monitor is
used.
USING THE GUI
This is configurable on the Config Mode > Service > Health Monitor >
Global page.
USING THE CLI
To display the current settings for health-check rate limiting, use the show
health-stat command. Here is an example:
AX(config)#show health stat
Health monitor statistics
Total run time: : 21 hours 31 minutes 31 seconds
Number of burst: : 0
...
Configured health-check rate (/500ms) : Auto configured
Current health-check rate (/500ms): : 5
...
The Configured health-check rate field and Current health-check rate show
the health-check rate limiting settings.
• If auto-adjust is enabled:
• Configured health-check rate – Shows “Auto configured”
• Current health-check rate – Shows the total number of health moni-
tors divided by the global health-check timeout:
total-monitors / global-timeout
• If auto-adjust is disabled:
• Configured health-check rate – Shows the manually configured
threshold
• Current health-check rate – Shows the manually configured thresh-
old

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Database Health Monitors
Changing the Threshold
To change the health-check rate limiting threshold:
1. Disable auto-adjust, by entering the following command at the global
health disable-auto-adjust
2. Set the threshold, using the following command at the global configura-
tion level of the CLI:
health check-rate threshold
Database Health Monitors

You can configure database health monitors using the CLI or GUI, without
the need to configure and import scripts. Previous releases support database
health monitors only with imported scripts.
Simplified database health monitor configuration applies to the following

database types:
• Oracle
• MSSQL
• MySQL
• PostgreSQL
Database Health Monitor Parameters

To configure a database health monitor, specify the following parameters.
Required Parameters
• Database type – Oracle, MSSQL, MySQL, or PostgreSQL
• Database name – Name of the database to query
• Username and password – Account information required for access to

the database
Optional Parameters
• Send string – SQL query to send to the database.
• Receive string – Query result expected from the database in order to

pass the health check.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Compound Health Monitors
• Receive row and column – For replies that consist of multiple results,
the results are in a table. You can specify the row and column location
within the results table to use as the receive string. If you do not specify
the row and column, row 1 and column 1 are queried by default.
Note: To use the receive string option, you also must use the send string option.
If you do not use the send option, the AX device does not send a query.
USING THE GUI
This is configurable on the Config Mode > Service > Health Monitor >
Health Monitor page.
USING THE CLI

To configure a database health monitor, use the following commands:
Enter this command at the global configuration level. The command creates
the monitor and accesses the configuration level for it.
Use the following command to configure the specific database options:
[no] method database

{mssql | mysql | oracle | postgresql}
db-name name
username username-string password password-string
[send query
[receive expected-reply
[row row-num column col-num]
]
]
For information, see “Database Health Monitor Parameters” on page 538.

Compound health monitors enable you to combine the status of multiple
health checks into a single result. The AX device uses the combined results
of individual health checks to determine the health of the real server, port, or
service group to which the compound health monitor is applied.
Note: The compound server health status may report as Down due to incorrect
timeout or interval parameters. (See “Considerations” on page 541.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Note: Compound health monitoring increases the workload of the health moni-
toring subsystem. For example, using a compound monitor with many sub
monitors against a service group with many members can affect system
performance. This increased workload could significantly delay the
response time for compound health checks.
Compound Health Monitor Syntax

A compound health monitor consists of a set of health monitors joined in a
Boolean expression (AND / OR / NOT).
The CLI Boolean expression syntax is based on Reverse Polish Notation

(also called Postfix Notation), a notation method that places an operator
(AND, OR, NOT) after all of its operands (in this case, health monitors).
After listing the health monitors, add the Boolean operator(s). The follow-
ing operators are supported:
• AND – Both the ANDed health checks must be successful for the health
status to be Up. If either of the health checks is unsuccessful, the health
status is Down.
• OR – Either of the ORed health checks must be successful for the result
to be Up. Even if one of the health checks is unsuccessful, the health sta-
tus is still Up if the other health check is successful. If both of the health
checks are unsuccessful, the health status is Down.
• NOT – The health status is the opposite of the health check result. For
example, if a health check is unsuccessful, the resulting health status is
Up. Likewise, if the health check is successful, the resulting health sta-
tus is Down. You can use NOT with a single health method, or with
multiple health methods for more complex expressions. (See below.)
For example, to construct a health monitor that ANDs two health monitors,
use the following syntax:
method compound sub hm1 sub hm2 AND
This is logically equivalent to the following expression: hm1 & hm2
Note: In the CLI, you must enter method compound at the beginning, and sub
in front of each health-monitor name. In the GUI, do not enter method
compound. The GUI automatically enters sub in front of each health
monitor name when you select it.
Note: The equivalent expressions are shown for clarity but are not valid syntax
on the AX device.
Similarly, to construct a health monitor that ORs two health monitors, use
the following syntax:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
method compound sub hm1 sub hm2 OR
This is logically equivalent to the following expression: hm1 | hm2
To construct a health monitor that results in an Up health status if the health

check is unsuccessful, use the following syntax:
method compound sub hm1 NOT
This is logically equivalent to the following expression: ! hm1
To construct more complex expressions, you can enter multiple sets of

health monitors and operators. Here is a quite complex expression:
(! (hm1 | (hm2 & (hm3 | (! hm4))))) | hm5
To configure this expression, use the following syntax:
method compound sub hm1 sub hm2 sub hm3 sub hm4
NOT OR AND OR NOT sub hm5 OR
Considerations
• A maximum of 8 sub monitors are supported in a compound monitor. To
use more sub monitors, you can nest compound monitors. (See below.)
• The total number of sub monitors plus the number of Boolean operators
supported in a compound monitor is 16.
• You can nest compound monitors. To nest compound monitors, config-
ure a compound monitor, then use that compound monitor as a sub mon-
itor in another compound monitor. The maximum nesting depth is 8.
Nesting loops are not allowed.
• The timeout and interval parameters of a compound monitor must be set
to values that allow each of the sub monitors to complete their health
checks. If any of the sub monitors is unable to complete its health check,
the compound monitor’s result is always Down.
For example, if monitor1 gives a result after 2 seconds, but a compound
monitor that uses monitor1 times out in 1 second, the resulting health
status will always be Down, regardless of the Boolean expression. (See
“Timeout Configuration” on page 544.)
Note: If you encounter this problem, A10 Networks recommends you increase
the timeout parameter for the compound monitor to ensure the health
check can cycle through all sub monitors. (See “Configuring and Apply-
ing a Health Method” on page 502.) You alternatively can decrease the
number of retry attempts for sub monitor health checks to 1. (See “Con-
secutive Health Checks Within a Health Check Period” on page 529”.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE GUI

1. Configure the sub monitors first.
2. Click Add on the health monitor list to begin configuration of a new

monitor.
3. In the Method section, select Compound from the Type drop-down list.
The Boolean Expression configuration controls appear.
4. Construct the Boolean expression:

• To enter a health monitor, click the radio button next to the list of
health monitors, select the monitor, then click Add.
• To enter an operator, click the radio button next to the list of opera-
tors, select the operator, then click Add.
Note: Make sure to use Reverse Polish Notation. (See “Compound Health Mon-
itor Syntax” on page 540.) Otherwise, the GUI will display an error mes-
sage when you click OK to complete the health monitor configuration.
5. Click OK to complete the configuration of the compound monitor.
FIGURE 161 Compound Health Monitor Configuration

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI
To configure a compound health monitor, use the following command to

add a Boolean expression at the configuration level for the monitor:
[no] method compound sub monitor-name

[sub monitor-name ...]
Boolean-operators
Note: Make sure to use Reverse Polish Notation. (See “Compound Health Mon-
itor Syntax” on page 540.)
CLI Examples
The following commands configure a compound health monitor in which
both health checks must be successful in order for the resulting health status
to be Up:
AX(config)#health monitor hm-compoundAND
AX(config-health:monitor)#method compound sub hm1 sub hm2 AND
The following commands apply the health monitor to a service group:

AX(config-slb svc group)#health-check hm-compoundAND
The following commands configure a compound health monitor in which

the resulting health status is Up if any one ore more of the health checks is
successful:
AX(config)#health monitor hm-compoundOR
AX(config-health:monitor)#method compound sub hm1 sub hm2 sub hm3 OR OR
The following commands apply the health monitor to a service group:

AX(config-slb svc group)#health-check hm-compoundOR
NOT Operator
The following commands configure a compound health monitor that results
in an Up status only if the server fails the ICMP health check:
AX(config)#health monitor icmp retry 1
AX(config-health:monitor)#health monitor “not_ping” interval 11 timeout 11
AX(config-health:monitor)#method compound sub icmp not

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Displaying Health Status
Timeout Configuration
For a compound health check configured as follows:
AX(config)#health monitor monitor1 interval 3 retry 2 timeout 3
AX(config)#health monitor monitor2 interval 5 retry 1 timeout 5
AX(config)#health monitor compound-monitor interval 6 retry 3 timeout 6
AX(config-health-monitor)#method compound sub monitor1 sub monitor2 and
The amount of time allowed to perform health checks for monitor1 and
monitor2 is calculated by the retry and timeout values.
For this example, a compound health check requires a minimum of 10 sec-

onds. If the timeout value for the compound health check is set to 6, then the
result is always Down. In order to ensure a complete compound health
check, set the compound health check timeout to 10 seconds or greater.

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.
Virtual server health status is also displayed in the virtual server list dis-
played by Config Mode > Service > SLB > Virtual Server.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.

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.
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]]
Here is an example:
AX#show slb virtual-server "vs 1"
Virtual server: vs 1(A) State: Down IP: 1.1.1.201
Port Curr-conn Total-conn Rev-Pkt Fwd-Pkt Peak-conn
-------------------------------------------------------------------------------------
Virtual Port:80 / service:svcgrp 1 / state:Down

port 80 tcp
1 server 1:80/Down 0 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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]]
Here is an example:
AX#show slb server
Total Number of Services configured: 5
Current = Current Connections, Total = Total Connections
Fwd-pkt = Forward packets, Rev-pkt = Reverse packets
Service Current Total Fwd-pkt Rev-pkt Peak-conn State
---------------------------------------------------------------------------------------
s1:80/tcp 0 0 0 0 0 Down
s1:53/udp 0 0 0 0 0 Down
s1:85/udp 0 0 0 0 0 Down
s1: Total 0 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
max scan jiffie: : 326
min scan jiffie: : 1
average scan jiffie: : 1
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
Conn Immediate Success: : 0
Socket closed before l7: : 0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Using External Health Methods
Socket closed without fd notify: : 0
Get retry send: : 0
Get retry recv: : 0
Configured health-check rate (/500ms) : Auto configured
Current health-check rate (/500ms): : 1600
External health-check max rate(/200ms) : 2
Total number: : 8009
Status UP: : 8009
Status DOWN: : 0
Status UNKN: : 0
Status OTHER: : 0
IP address Port Health monitor Status Cause(Up/Down) Retry PIN

--------------------------------------------------------------------------------
10.0.0.11 80 http UP 11 /0 @0 0 0 /0 0
10.0.0.12 80 http UP 10 /0 @0 0 0 /0 0
For more information, see the AX Series CLI Reference.

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
• Python
Utility commands such as ping, ping6, wget, dig, and so on are supported.
The AX device supports the Perl IO::Socket module.
Note: External health methods are not supported in Direct Server Return (DSR)
deployments.
Configuration
To use an external health method:
1. Configure a health monitor script.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
3. Configure a health monitor that uses external as the method.
4. In the server configuration, set the health check to use the method.
USING THE GUI
To import an external health-check script onto the AX device:

2. On the menu bar, select External Program.
3. Click Add.
4. Enter a name and description for the script.
5. Copy-and-paste the script into the Definition field.
6. Click OK.
To configure an external health monitor:

1. On the menu bar, select Health Monitor.
2. Click Add.
3. Enter a name for the monitor.
4. In the Method section, click External next to Method.
5. Select the script from the Program Name drop-down list.
6. Enter any arguments in the Arguments field.
7. In the Port field, enter the protocol port number.
8. Click OK.
To configure a server to use the external health method:

3. Click on the server name or click Add to create a new one.
4. If configuring a new server, enter the name and IP address, and other
general parameters as applicable.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
5. In the Port section:
a. If adding a new port, enter the port number in the Port field.
b. Select the external health monitor from the Health Monitor field.
6. Click OK.
USING THE CLI
To import an external health-check script onto the AX device:

Use the following command at the global configuration level:
health external import [use-mgmt-port] [description]
url
To configure an external health monitor:

Use the following command at the global configuration level:
This command changes the CLI to the configuration level for the monitor.
At this level, use the following command:
method method-name external
[port port-num]
program program-name [arguments argument-string]
For program-name, use the same filename you used when you imported the
script.
To configure a server to use the external health method:

Use the following command at the configuration level for the server:
Script Examples
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(ServerHost) 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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-0026 - Ver. 2.7.0 11/1/2012
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
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
else
echo "Fail"
exit 1
fi
Python Script Example
See “Database Health Monitoring Using a Script” on page 552.
Database Health Monitoring Using a Script

The AX device supports Open Database Connectivity (ODBC). With this
support, you can use a Python script to perform Layer 7 health checking
based on information in a database on the server.
The following types of databases are supported:

• Microsoft SQL
• MySQL
• PostgreSQL
• Oracle
Note: The AX device also provides a database heath method. See “Database
Health Monitors” on page 538.
To configure database health monitoring:

1. Configure a Python script to check the database. (See the examples
below.)
3. Configure an external health monitor that uses the script.
4. Bind the external health monitor to the target (real server, real port, or
service group).
The steps performed on the AX device are the same as those for any other
type of external health monitor.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Example Script—Microsoft SQL
#!/usr/bin/python
import sys
import os
import pyodb
# MsSQL connection string format:

#Driver=FreeTDSDriver;Server=<ip>;Port=<port>;TDS_version=7.0;Database=<data-
base>;UID=<username>;PWD=<password>
# by a10hm convention get host and/or port from environment

host = os.environ['HM_SRV_IPADDR']
if os.environ.has_key('HM_SRV_PORT'):
port = int(os.environ['HM_SRV_PORT'])
if 0 >= port or 65536 <= port:
port = 0
else:
port = 0
if 0 != port:
conn_str = ("Driver=FreeTDSDriver;Server=%s;Port=%d;TDS_version=7.0;Database=Data-
base;UID=User;PWD=Password" % (host, port))
else:
conn_str = ("Driver=FreeTDSDriver;Server=%s;TDS_version=7.0;Database=Data-
base;UID=User;PWD=Password" % (host))
sql_stmt = "select * from Table"

try:
rv = 0
print "Connecting %s" % (conn_str)
conn = pyodb.Connect(conn = conn_str)
print "Doing SQL query '%s'" % (sql_stmt)
conn.execute(sql_stmt)
print "Fetching query results"
rows = conn.fetch()
print "Verifying results are OK"
if (0 == len(rows)):
rv = -1;
print "Cleaning up the database connection"
conn.disconnect()
del(conn)
except:
print "Something went wrong"
# by a10hm convention must exit with something other than 0
rv = -1
sys.exit(rv)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Example Script—MySQL
#!/usr/bin/python
import sys
import os
import pyodb
# MySQL connection string format:

#Driver=MySQLDriver;Server=<ip>;Port=<port>;Database=<database>;UID=<user-
name>;PWD=<password>

port = 0
else:
port = 0
if 0 != port:
conn_str = ("Driver=MySQLDriver;Server=%s;Port=%d;Database=Data-
else:
conn_str = ("Driver=MySQLDriver;Server=%s;Database=Database;UID=User;PWD=Password" %
(host))

try:
rv = 0
rows = conn.fetch()
if (0 == len(rows)):
rv = -1;
conn.disconnect()
del(conn)
except:
rv = -1
sys.exit(rv)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Example Script—PostgreSQL
#!/usr/bin/python
import sys
import os
import pyodb
# PostgreSQL connection string format:

# Driver=PostgreSQLDriver;Server=<ip>;Port=<port>;Database=<database>;UID=<user-
name>;PWD=<password>

port = 0
else:
port = 0
if 0 != port:
conn_str = ("Driver=PostgreSQLDriver;Server=%s;Port=%d;Database=Data-
else:
conn_str = ("Driver=PostgreSQLDriver;Server=%s;Database=Database;UID=User;PWD=Pass-
word" % (host))

try:
rv = 0
rows = conn.fetch()
if ( 0 == len(rows)):
rv = -1;
conn.disconnect()
del(conn)
except:
rv = -1
sys.exit(rv)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Example Script—Oracle
#!/usr/bin/python
import sys
import os
import pyodb
# Oracle connection string format:

#Driver=OracleODBCDriver;DBQ=<Oracle-DBQ>;UID=<username>;PWD=<password>

port = 0
else:
port = 0
if 0 != port:
conn_str = ("Driver=OracleODBCDriver;DBQ=//%s:%d/XE;UID=User;PWD=Password" % (host,
port))
else:
conn_str = ("Driver=OracleODBCDriver;DBQ=//%s/XE;UID=User;PWD=Password" % (host))

try:
rv = 0
rows = conn.fetch()
if ( 0 == len(rows)):
rv = -1;
conn.disconnect()
del(conn)
except:
rv = -1
# by a10hm convention must exit with 0

sys.exit(rv)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Network Address Translation for SLB
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.
Note: This chapter does not include information about Layer 3 NAT features or
NAT features for IPv6 migration.
Note: If you use the older implementation of High Availability (HA), only half
the protocol ports on each NAT IP address are available at a given time.
This is because the AX device allocates half the ports to one of the AX
devices in the HA pair and the other half to the other AX device. This
does not occur with VRRP-A. If you use VRRP-A, all the protocol ports
on NAT addresses are available.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Overview
AX Series devices can perform source and destination NAT on client-VIP
SLB traffic.
SLB Destination NAT

AX Series devices automatically perform destination NAT for client-VIP
SLB traffic. Figure 162 shows an example.
Note: Destination NAT is disabled for virtual ports on which Direct Server
Return (DSR) is enabled.
FIGURE 162 SLB NAT

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
By default, SLB NAT works as follows.
• 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.
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 559.)
• 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 564.)
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 its session. Instead, the AX device leaves the
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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.
USING THE GUI

1. To configure a pool of addresses:
a. Select Config Mode > Service > IP Source NAT.
b. Select IPv4 Pool or IPv6 Pool on the menu bar.
c. Click Add. The Pool section appears.
d. Enter a name for the pool.
e. Enter the start and end addresses.
f. Enter the network mask.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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:

a. Select Config Mode > Service > Template.
b. Select Connection Reuse on the menu bar.
c. Click Add. The Connection Reuse section appears.
d. Enter a name for the template.
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 Mode > Service > Server.
b. Select Virtual Server on the menu bar.
c. Select the virtual server name or Click Add.
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 Add. The Virtual Server Port
section appears.
g. Enter or select the port settings, if the port is new.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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]
To configure an IPv6 pool:

ipv6 nat pool pool-name
start-ipv6-addr end-ipv6-addr
netmask mask-length
[gateway ipaddr] [ha-group-id group-id]
To configure a pool group, 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
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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 /24
AX(config)#access-list 50 permit ip 192.168.20.69 /24
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
The following commands configure a real server and a service group:
AX(config)#slb service-group group80 tcp
AX(config-slb service group)#method weighted-rr
AX(config-slb service group)#member s1:80

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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 163 on page 565 shows an example.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 163 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-0026 - Ver. 2.7.0 11/1/2012
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

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-0026 - Ver. 2.7.0 11/1/2012
When DSR is enabled, only the destination MAC address is translated from
the VIP’s MAC address to the real server’s MAC 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: The current release does not support external health monitoring for DSR
deployments. To configure health checking for DSR, see “Configuring
Health Monitoring of Virtual IP Addresses in DSR Deployments” on
page 506.
Note: For examples of DSR configurations, see “More SLB Deployment Exam-
ples” on page 63.
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 sec-
tion 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-0026 - Ver. 2.7.0 11/1/2012
IP NAT Support for VIPs
IP NAT Support for VIPs

The AX device supports IP NAT for VIPs. This feature allows clients in a
private network to connect to outside VIP servers, without revealing the IP
addresses of the clients to the servers. Dynamic NAT and static NAT are
both supported.
Note: The current release does not support this feature for FTP or RTSP traffic.
Priority for Source IP NAT Configurations on Individual Virtual

Ports
Source IP NAT can be configured on a virtual port in the following ways:
1. ACL-based source NAT (access-list command at virtual port level)
2. VIP source NAT (slb snat-on-vip command at global configuration

level)
3. aFleX policy (aflex command at virtual port level)
4. Non-ACL source NAT (source-nat command at virtual port level)
These methods are used in the order shown above. For example, if IP source
NAT is configured using an ACL on the virtual port, and the slb snat-on-
vip command is also used, then a pool assigned by the ACL is used for traf-
fic that is permitted by the ACL. For traffic that is not permitted by the
ACL, VIP source NAT can be used instead.
Configuration
To configure IP NAT for VIPs:
1. Configure a pool, range list, or static inside source NAT mapping, that
includes the real IP address(es) of the inside clients.
2. Enable inside NAT on the interface connected to the inside clients.
3. Enable outside NAT on the interface connected to the external VIP serv-
ers
You can enable this feature globally or on individual virtual ports:
To globally configure IP NAT support for VIPs, use the following command
[no] slb snat-on-vip

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Using IP Pool Default Gateways To Forward Traffic from Real Servers
To configure IP NAT support for an individual virtual port, use the com-
mand at the configuration level for the virtual port instead of at the global
level.
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
[no] slb snat-gwy-for-l3
Smart NAT for Virtual Ports

Smart NAT provides source NAT for virtual ports. The IP addresses ta
Smart NAT uses to create the mappings depend on whether either VRRP-A
or HA is enabled and floating-IP addresses are configured:
• With VRRP-A / HA – If VRRP-A or HA is configured, Smart NAT uses
configured floating IP addresses as NAT addresses.
• Without VRRP-A / HA – If neither VRRP-A nor HA is configured,
Smart NAT uses IP address(es) on the AX interface connected to the real
server.
In VRRP-A or HA deployments, if session synchronization is enabled, ses-

sions created by Smart NAT are synchronized to the backup device.
Notes
• If you use HA or VRRP-A, it is recommended to bind a given service
group to only a single virtual port. If you do bind a service group to mul-
tiple virtual ports, it is highly recommended to assign all the virtual
servers to the same HA group ID or VRRP-A VRID.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• When a service group is bound to a virtual port, the Smart NAT
resources are created for all the servers belonging to that service group.
port. If the selected server does not have Smart NAT resources, then
they are dynamically created. In this case, some initial connections may
be dropped.
• Smart NAT applies only to AX devices deployed in route mode (also
called “gateway” mode). The feature is not applicable to devices
deployed in transparent mode.
• Smart NAT uses protocol ports 20032-65535.
• Smart NAT is not supported on SIP, SIP-TCP, or SIPS virtual ports.
• You can configure a virtual port to use both Smart NAT and a config-
ured NAT pool. By default, the configured pool addresses are used first.
In this case, Smart NAT is used only when there are no more available
mappings in the configured pool.
Optionally, you can configure Smart NAT to take precedence over the
configured NAT pool. In this case, the configured pool is used only
when there are no more available mappings using Smart NAT.
• If you do not use VRRP-A or HA, real server IP addresses are used for
the Smart NAT mappings. up to 45 K mappings per real server port are
supported. The AX device can use the same AX interface IP address and
port for more than one server connection. The combination of AX IP
address and port number (source) and server IP address and port (desti-
nation) uniquely identifies each mapping. Smart NAT uses only the pri-
mary IP address on an interface, even if multiple addresses are
configured on the interface.
USING THE GUI

On the configuration page for the virtual port, select the Auto checkbox next
to Source NAT Pool. If you want Smart NAT to be used before a pool is
used, also select the Precedence checkbox.
USING THE CLI
To enable Smart NAT on a virtual port, use the following command at the
configuration level for the virtual port:
[no] source-nat auto [precedence]
The precedence option configures Smart NAT to be used first. (See “Notes”
on page 569.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To display Smart NAT statistics, use the following command:
show slb server auto-nat-stats
CLI Example
The commands in this example configure two virtual ports. Smart NAT is
enabled on each virtual port.
To begin, the following commands configure the data interfaces:

AX(config)#vlan 10
AX(config-vlan:10)#vlan 20
AX(config-vlan:20)#interface ethernet 3
AX(config-if:ethernet3)#interface ve 10
AX(config-if:ve10)#interface ve 20
The following command configures a source NAT pool:

AX(config-if:ve20)#ip nat pool snat-pool1 160.160.160.200 160.160.160.200
netmask /24
The following commands configure a real server with two ports, and a ser-
vice group for each port:
AX(config-real server-node port)#slb service-group sg1-http tcp
AX(config-slb svc group)#slb service-group sg2-ftp tcp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands configure the VIP. Smart NAT is enabled on each
virtual port.
AX(config-slb svc group)#slb virtual-server vip1 160.160.160.150
AX(config-slb vserver)#port 21 ftp
AX(config-slb vserver-vport)#source-nat auto precedence
AX(config-slb vserver-vport)#source-nat pool snat-pool1
AX(config-slb vserver-vport)#service-group sg2-ftp
AX(config-slb vserver-vport)#port 80 tcp
AX(config-slb vserver-vport)#source-nat auto
AX(config-slb vserver-vport)#source-nat pool snat-pool1
AX(config-slb vserver-vport)#service-group sg1-http
On the FTP virtual port, the precedence option is used with Smart NAT.
This means Smart NAT is used first, and the NAT pool is used only if all
Smart NAT mappings are in use.
On the TCP virtual port, the precedence option is omitted. In this case, the
source NAT pool is used first. Smart NAT is used only if no more mappings
are available using the pool.
The following command shows Smart NAT statistics:

AX(config-slb vserver-vport)#show slb server auto-nat-stats
Service HA/VR ID Nat Address Port Usage Total Used Total Freed Failed
---------------------------------------------------------------------------------------
s1:80/tcp 0 160.160.160.1 5 1513 1508 0
s1:21/tcp 0 160.160.160.1 0 0 0 0
In this example, both virtual ports are using Smart NAT. The Nat Address,
Port Usage, Total Used, Total Freed, and Failed columns show the same
information shown in show ip nat pool statistics output. (See the AX Series
CLI Reference.)
The Service column lists the server, protocol port, and Layer 4 protocol.
The HA/VR ID column lists the HA group ID or VRRP-A VRID, if applica-
ble. In this example, the AX device is deployed as a standalone device, so
“0” is shown in this column.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Virtual-port TCP Maximum Segment Life for NATted Sessions
Virtual-port TCP Maximum Segment Life for NATted

Sessions
You can customize the Maximum Segment Life (MSL) for source-NAT
connections virtual ports.
The MSL is the maximum number of seconds a TCP segment (packet) is

allowed to remain in the network. When one of the endpoints in a TCP con-
nection sends a FIN to close the connection, that endpoint then enters the
TIME-WAIT state.
During the TIME-WAIT state, the endpoint is not allowed to accept any
new TCP connections. This behavior is meant to ensure that the TCP end-
point does not receive a segment belonging to a previous connection after
the endpoint enters a new connection.
The TIME-WAIT state lasts up to twice the MSL. On some older TCP/IP
stacks, this can result in a wait of up to 240 seconds (4 minutes) after a FIN
before the endpoint can enter a new connection.
To help reduce the time between connections for these endpoints, you can
set the MSL for individual virtual ports, to 1-1800 seconds.
Note: The current release supports this feature for IPv4 source NAT pools, and
for virtual ports on IPv4 or IPv6 VIPs. The current release does not sup-
port this feature for IPv6 source NAT pools. For information about con-
figuring this feature for source NAT pools, see the “Network Address
Translation” chapter in the AX Series System Configuration and Adminis-
tration Guide.
USING THE GUI

To set the MSL for source-NAT sessions for a virtual port:
On the configuration page for the virtual port template, enter the MSL value
in the MSL field. Apply the template to the virtual port.
USING THE CLI
To set the MSL for a virtual port, use the following command at the config-
uration level for the virtual port template:
[no] snat-msl seconds
Make sure to apply the template to the virtual port.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Virtual-port TCP Maximum Segment Life for NATted Sessions
CLI Example
The following commands configure a custom MSL value for a virtual port:
AX(config)#ip nat pool natintf 192.168.20.48 192.168.20.48 netmask /24
AX(config)#slb template virtual-port ronvport
AX(config-vport)#snat-msl 18
AX(config)#slb virtual-server ronvip2 192.168.20.103
AX(config-slb vserver-vport)#service-group web
AX(config-slb vserver-vport)#source-nat pool natintf
AX(config-slb vserver-vport)#template virtual-port ronvport

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
IP Limiting
IP limiting provides a greatly enhanced implementation of the source IP

connection limiting and connection-rate limiting feature available in previ-
ous releases. This chapter describes the IP limiting options and how to con-
figure and apply them.
Overview
IP limiting provides the following benefits:
• Configuration flexibility – You can apply source IP limiting on a sys-
tem-wide basis, on individual virtual servers, or on individual virtual
ports.
• Class lists – You can configure different classes of clients, and apply a
separate set of IP limits to each class. You also can exempt specific cli-
ents from being limited.
• Separate limits can be configured for each of the following:
• Concurrent connections
• Connection rate
• Concurrent Layer 7 requests
• Layer 7 request rate
Note: In the current release, Layer 7 request limiting applies only to the HTTP,
HTTPS, and fast-HTTP virtual port types.
The following sections describe the IP limiting options and how to config-
ure and apply them.
Class Lists
A class list is a set of IP host or subnet addresses that are mapped to IP lim-
iting rules.
The AX device can support up to 255 class lists. Each class list can contain
up to 8 million host IP addresses and 64,000 subnets.
Note: Class lists can be configured only in the shared partition. A policy tem-
plate configured in the shared partition or in a private partition can use a
class list configured in the shared partition.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Class List Syntax

Each entry (row) in the class list defines a client class, and has the following
format:
ipaddr /network-mask [glid num | lid num] [age minutes]
[; comment-string]
Each entry consists of the following:

• ipaddr – Specifies the host or subnet address of the client. The network-
mask specifies the mask. IPv4 and IPv6 are supported.
To configure a wildcard IP address, specify 0.0.0.0 /0 or ::/0. The wild-
card address matches on all addresses that do not match any entry in the
class list.
• glid num | lid num – Specifies the ID of the IP limiting rule to use for
matching clients. You can use a system-wide (global) IP limiting rule or
an IP limiting rule configured in a policy template.
• To use an IP limiting rule configured at the global configuration
level, use the glid num option.
• To use an IP limiting rule configured at the same level (in the same
policy template) as the class list, use the lid num option.
To exclude a host or subnet from being limited, do not specify an IP lim-
iting rule.
• age minutes – Removes a host entry from the class list after the specified
number of minutes. You can specify 1-2000 minutes.
When you assign an age value, the host entry remains in the class list
only for the specified number of minutes. After the age expires (reaches
0), the host entry is removed from the class list within the next minute.
You can use the age option in combination with IP limiting options in
the LID or GLID to temporarily control client access. Any traffic limit-
ing settings in the LID or GLID assigned to the host entry take effect
only until the age expires.
Note: The age option applies only to host entries (IPv4 /32 or IPv6 /128). The
age option is not supported for subnet entries.
Note: If you use a class-list file that is periodically re-imported, the age for
class-list entries added to the system from the file does not reset when the
class-list file is re-imported. Instead, the entries are allowed to continue
aging normally. This is by design.
• ; comment-string – Contains a comment. Use a semi-colon ( ; ) in front
of the comment string.
Note: The AX device discards the comment string when you save the class list.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
IP Address Matching
By default, the AX device matches class-list entries based on the source IP
address of client traffic. Optionally, you can match based on one of the fol-
lowing instead:
• Destination IP address – Matches based on the destination IP address
instead of the source IP address.
• IP address in HTTP request – Matches based on the IP address in a
header in the HTTP request. You can specify the header when you
enable this option.
Example Class Lists
Here is an example of a very simple class list. This list matches on all cli-
ents and uses an IP limiting rule configured at the global configuration
level:
0.0.0.0/0 glid 1
Here is an example with more options:
1.1.1.1 /32 lid 1
2.2.2.0 /24 lid 2 ; LID 2 applies to every single IP of this subnet
0.0.0.0 /0 lid 10 ; LID 10 applied to every undefined single IP
3.3.3.3 /32 glid 3 ; Use global LID 3
4.4.4.4 /32 ; No LID is applied (exception list)
The rows in the list specify the following:

• For individual host 1.1.1.1, use IP limiting rule 1, which is configured in
a policy template. (A policy template can be applied globally for sys-
tem-wide IP limiting, or to an individual virtual server or virtual port.
This is described in more detail in a later section.)
• For all hosts in subnet 2.2.2.0/24, use IP limiting rule 2, which is config-
ured in a policy template.
• For all hosts that do not match another entry in the class list, use IP lim-
iting rule 10, which is configured in a policy template.
• For individual host 3.3.3.3, use IP limiting rule 3, which is configured at
the global configuration level.
• For individual host 4.4.4.4, do not use an IP limiting rule.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
IP Limiting Rules
IP limiting rules specify connection and request limits for clients.
Each IP limiting rule has the following parameters:

• Limit ID – Number from 1-31 that identifies the rule.
• Connection limit – Maximum number of concurrent connections

allowed for a client. You can specify 0-1048575. Connection limit 0
immediately locks down matching clients. There is no default.
• Connection-rate limit – Maximum number of new connections allowed
for a client within the limit period. You can specify 1-4294967295 con-
nections. The limit period can be 100-6553500 milliseconds (ms), spec-
ified in increments of 100 ms. There is no default.
• Request limit – Maximum number of concurrent Layer 7 requests
allowed for a client. You can specify 1-1048575. There is no default.
• Request-rate limit – Maximum number of Layer 7 requests allowed for a
client within the limit period. You can specify 1-4294967295 connec-
tions. The limit period can be 100-6553500 milliseconds (ms), specified
in increments of 100 ms. There is no default.
• Over-limit action – Action to take when a client exceeds one or more of
the limits. The action can be one of the following:
• Drop – The AX device drops that traffic. If logging is enabled, the
AX device also generates a log message. This is the default action.
• Forward – The AX device forwards the traffic. If logging is enabled,
the AX device also generates a log message.
• Reset – For TCP, the AX device sends a TCP RST to the client. If
logging is enabled, the AX device also generates a log message.
• Lockout period – Number of minutes during which to apply the over-
limit action after the client exceeds a limit. The lockout period is acti-
vated when a client exceeds any limit. The lockout period can be 1-1023
minutes. There is no default.
• Logging – Generates log messages when clients exceed a limit. Logging
is disabled by default. When you enable logging, a separate message is
generated for each over-limit occurrence, by default. You can specify a
logging period, in which case the AX device holds onto the repeated
messages for the specified period, then sends one message at the end of
the period for all instances that occurred within the period. The logging
period can be 0-255 minutes. The default is 0 (no wait period).
Note: The class-list options request limit and request-rate limit, when config-
ured in a policy template, are applicable only in policy templates that are

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
bound to virtual ports. These options are not applicable in policy tem-
plates bound to virtual servers (rather than individual ports), or in policy
templates used for system-wide PBSLB. (For more information, see
“Request Limiting and Request-rate Limiting in Class Lists” on
page 579.)
The request limit and request-rate limit options apply only to HTTP, fast-
HTTP, and HTTPS virtual ports. The over-limit logging, when used with
the request-limit or request-rate-limit option, always lists Ethernet port 1
as the interface.
Match IP Address
lowing instead:
• Destination IP address – matches based on the destination IP address in
packets from clients.
• IP address in client packet header – matches based on the IP address in
the specified header in packets from clients. If you do not specify a
header name, this option uses the IP address in the X-Forwarded-For
header.
Request Limiting and Request-rate Limiting in Class Lists
If a LID or GLID in a class list contains settings for request limiting or

request-rate limiting, the settings apply only if the following conditions are
true:
1. The LID or GLID is used within a policy template.
2. The policy template is bound to a virtual port.
In this case, the settings apply only to the virtual port. The settings do not
apply in any of the following cases:
• The policy template is applied to the virtual server, instead of the virtual
port.
• The settings are in a system-wide GLID.
• The settings are in a system-wide policy template.
Note: This limitation does not apply to connection limiting or connection-rate

limiting. Those settings are valid in all the cases listed above.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
CLI Examples: Request Limiting and Request-rate Limiting Set-
tings Are Used
In the following examples, the request limiting and request-rate limiting
settings are used.
Example 1: GLID Used in Policy Template and Bound to Virtual Port

The following configuration is valid for request limiting and request-rate
limiting. The request limiting and request-rate limiting settings are in a
GLID that is used by a policy template bound to a virtual port.
AX(config)#class-list 2
AX(config-class list)#5.1.1.100 /32 glid 1023
AX(config-class list)#55.1.1.0 /24 lid 31
AX(config)#glid 1023
AX(config-global lid)#request-limit 10
AX(config-global lid)#request-rate-limit 2 per 100
AX(config-global lid)#over-limit-action reset log 1
AX(config)#slb template policy g
AX(config-policy)#class-list name 2
AX(config-policy)#exit
AX(config)#slb virtual-server vs-55 55.1.1.55
AX(config-slb vserver)#ha-group 1
AX(config-slb vserver-vport)#service-group vlan-80-grp
AX(config-slb vserver-vport)#template policy g
Example 2: LID Used in Policy Template and Bound to Virtual Port

The following configuration also is valid for request limiting and request-
rate limiting. The request limiting and request-rate limiting settings are in a
LID that is configured in a policy template bound to a virtual port.
AX(config)#class-list 2
AX(config-class list)#55.1.1.100 /32 lid 31
AX(config)#slb template policy gg
AX(config-policy)#class-list name 2
AX(config-policy)#class-list lid 31
AX(config-policy-policy lid)#request-limit 10
AX(config-policy-policy lid)#request-rate-limit 2 per 100
AX(config-policy-policy lid)#exit

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
AX(config-slb vserver-vport)#template policy gg
CLI Examples: Request Limiting and Request-rate Limiting Set-

tings Are Not Used
In the following examples, the request limiting and request-rate limiting
settings are not used.
Example 1: Policy Template Bound to Virtual Server Instead of Virtual

Port
The following configuration is not valid for request limiting and request-
rate limiting. The policy template is bound to the virtual server instead of
the virtual port.
AX(config-slb vserver)#template policy gg
Example 2: System GLID

rate limiting, because the settings are in a system GLID.
AX(config)#system glid 1023
Example 3: System-wide Policy Template

rate limiting, because the settings are in a policy template used for system-
wide PBSLB.
AX(config)#system template policy g

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring Source IP Limiting

To configure source IP limiting:
1. Configure a class list either on the AX device or another device. If you
configure the class list on another device, import it onto the AX device.
2. Configure the IP limiting rules.

• For system-wide IP limiting, you can configure the rules in a policy
template or in standalone IP limiting rules.
• For IP limiting on an individual virtual server or virtual port, config-
ure the rules in a policy template.
3. Apply the IP limiting rules.
You can configure multiple policy templates with different IP limiting rules.
You can use a given class list in one or more policy templates.
• For system-wide source IP limiting, apply the policy template globally.
• For source IP limiting on an individual virtual server or virtual port,

apply the policy template to the virtual server or virtual port.
Clients must comply with all IP limiting rules that are applicable to the cli-
ent. For example, if you configure system-wide IP limiting and also config-
ure IP limiting on an individual virtual server, clients must comply with the
system-wide IP limits and with the IP limits applied to the individual virtual
server accessed by the client.
Configuring a Class List

You can configure a class list in either of the following ways:
• Use a text editor on a PC or other device to create the list, then import it
onto the AX device.
• Use CLI commands to create the list entries.
For class-list syntax information, see “Class Lists” on page 575.
USING THE GUI

2. On the menu bar, select Class List.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
3. Click Import. The Import page appears.
4. In the Name field, enter the filename to use for the imported class list.
5. Select the location of the file to be imported:

• Local – The file is on the PC you are using to run the GUI, or is on
another PC or server in the local network. Go to step 6.
• Remote – The file is on a remote server. Go to step 8.
6. Click Browse and navigate to the location of the class list.
7. Click Open. The path and filename appear in the Source field. Go to
step 13.
8. To use the management interface as the source interface for the connec-
tion to the remote device, select Use Management Port. Otherwise, the
AX device will attempt to reach the remote server through a data inter-
face.
9. Select the file transfer protocol: FTP, TFTP, RCP, or SCP.
10. In the Host field, enter the directory path and filename.
11. If needed, change the protocol port number n the port field. By default,
the default port number for the selected file transfer protocol is used.
12. In the User and Password fields, enter the username and password
13. Click OK.
Configuring a Class List in the GUI

2. On the menu bar, select Class List.
3. Click Add.
4. In the Name field, enter a name for the class list.
5. Select the system location in which to save the class list:

• File – The list is saved in a stand-alone file.
• Config – The list is saved in the startup-config.
Note: If the class list contains 100 or more entries, it is recommended to use the
File option. A class list can be exported only if you use the File option.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
6. Configure the class list entries:
a. Enter the IP address and subnet mask.
• For a host entry, use mask 255.255.255.255.
• For a wildcard entry, enter IP address 0.0.0.0 and network mask
0.0.0.0.
b. Specify the IP limiting rule to apply to the host or subnet address.
• Select the system location of the IP limiting rule:
Local – The IP limiting rule is configured in a policy template to
be applied to a virtual server or virtual port.
Global – The IP limiting rule is configured at the system
(global) level, and can be shared by all policy templates.
• Enter the rule number.
Note: Make sure to use the same number when you configure the IP limiting
rule.
c. To make the entry temporary, assign an age to the entry. You can
specify 1-2000 minutes. The entry is removed from the class list
after the age expires.
d. Click Add.
e. Repeat for each entry.
7. Click OK.
Note: The Age option applies only to host entries (IPv4 /32 or IPv6 /128). The
Age option is not supported for subnet entries.
USING THE CLI

After the class list is configured, import it onto the AX device, using the fol-
lowing command at the Privileged EXEC or global configuration level of
the CLI:.
import class-list file-name url
The file-name specifies the name the class list will have on the AX device.
directory path.
entire URL:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
You also can export class lists to a remote server, using the following com-
mand:
export class-list file-name url
Configuring a Class List in the CLI

To configure a class list in the CLI, use the following commands:
[no] class-list name [file]
Enter this command at the global configuration level of the CLI.
The file option saves the class list as a separate file. Without this option, the
class list is instead saved in the startup-config. If the class list contains 100
or more entries, it is recommended to use the file option. The file option is
valid only when you create the class list. After you create the list, the list
remains either in the startup-config or in a separate file, depending on
whether you use the file option when you create the list.
Note: A class list can be exported only if you use the file option.
The class-list command creates the class list if it is not already configured,
and changes the CLI to the configuration level for the list.
[no] ipaddr /network-mask [glid num | lid num]
• To add an entry to the class list, use the command without “no”.
• To modify an entry, use the command without “no”. Use the same
source IP address as the entry to replace. Entries are keyed by source IP
address.
• To delete an entry, use “no” followed by the source IP address.
Applying a Class List to a Policy

To apply a class list, use the following command at the configuration level
for the policy that contains the IP limiting rules used by the class list.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
After you configure the IP limiting rules and class list, and add the class list
to the policy, you can activate the IP limits. See “Applying Source IP Lim-
its” on page 589.
Configuring the IP Limiting Rules

You can configure IP limiting rules in policy templates (applied to individ-
ual clients) or in system-wide IP limiting rules (applied to all clients).
• If you plan to apply IP limits to individual virtual servers or virtual
ports, you must configure the IP limiting rules in a policy template, then
apply the template to the virtual server or virtual port.
• If you plan to apply IP limits on a system-wide basis, you can configure
the IP limiting rules in a PBSLB template or in standalone IP limiting
rules.
USING THE GUI

Configuring IP Limiting Rules in a Policy Template
2. On the menu bar, select Application > Policy.
3. Click Add to create a new template (or click on the name of an existing
template). The Policy section appears.
4. Enter a name for the template, if creating a new one.
5. In the IP Limiting section, configure IP limiting.

a. Select the class list from the Class List drop-down list.
b. Configure the limiting rules to apply to the selected class list. (For
parameter information, see “IP Limiting Rules” on page 578.)
6. Leave the Destination IP and Overlap options disabled.
7. Click OK.
Configuring Standalone IP Limiting Rules for System-Wide IP

Limiting
2. On the menu bar, select GLID.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
3. Configure the IP limiting rules. (For parameter information, see “IP
Limiting Rules” on page 578.)
4. Click OK.
USING THE CLI
Configuring IP Limiting Rules in a Policy Template

To configure IP limiting rules in a policy template, use the following com-
mands:
[no] slb template policy template-name

mand creates the template and changes the CLI to the configuration level
for the template, where the following commands are available. For informa-
tion about the valid values and defaults, see “IP Limiting Rules” on
page 578.

This command creates an IP limiting rule and changes the CLI to the con-
figuration level for the rule. The num option specifies the rule ID, and can
be 1-31.
The following commands are available at the configuration level for the IP
limiting rule.
[no] conn-limit num

This command specifies the maximum number of concurrent connections
allowed for a client.
[no] conn-rate-limit num per num-of-100ms

This command specifies the maximum number of new connections allowed
for a client within the specified limit period.
[no] request-limit num

This command specifies the maximum number of concurrent Layer 7
requests allowed for a client.
[no] request-rate-limit num per num-of-100ms

This command specifies the maximum number of Layer 7 requests allowed
for the client within the specified limit period.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
[no] over-limit-action [forward | reset]
[lockout minutes] [log minutes]
This command specifies the action to take when a client exceeds one or
more of the limits. The command also configures lockout and enables log-
ging.
Configuring IP Limiting Rules for System-Wide IP Limiting

(without a class list)
To configure an IP limiting rule for system-wide IP limiting, use the follow-
ing commands.
[no] glid num

This command creates the rule and changes the CLI to the configuration
level for it. The following commands are available at this level:
[no] conn-limit num
[no] conn-rate-limit num per num-of-100ms
[no] request-limit num
[no] request-rate-limit num per num-of-100ms
[no] over-limit-action [forward | reset]
[lockout minutes] [log minutes]
These commands are the same as the ones available at the IP limiting rule
configuration level in policy templates. (See “Configuring IP Limiting
Rules in a Policy Template” on page 587.)
Specifying the Match IP Address

lowing instead:
• Destination IP address
• IP address in client packet header
To change the match IP address to one of these options, use the following
command at the configuration level for the PBSPB policy template:
[no] class-list client-ip
{l3-dest | l7-header [header-name]}
The l3-dest option matches based on the destination IP address in packets

from clients.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The l7-header [header-name] option matches based on the IP address in the
specified header in packets from clients. The header-name specifies the
name of the header to use. If you do not specify a header name, the
X-Forwarded-For header is used.
Note: The destination-ip option applies only to black/white lists.
Applying Source IP Limits

The following subsections describe how to apply IP limiting rules to the
system or to individual virtual servers or virtual ports.
USING THE GUI
Applying System-Wide Source IP Limiting
For system-wide source IP limiting, no additional configuration is required.

After you configure one or more stand-alone IP limiting rules, and apply
them to classes (if using more than one class), the feature is implemented.
See the following sections:
• “Configuring a Class List in the GUI” on page 583
• “Configuring Standalone IP Limiting Rules for System-Wide IP Limit-

ing” on page 586
Applying Source IP Limiting to a Virtual Server

2. On the menu bar, select Virtual Server.
3. Click on the virtual server name or click Add if you are configuring a
new virtual server.
4. If you are creating a new virtual server, enter the name, virtual IP
address, and other General settings.
5. Select the policy template from the Policy Template drop-down list.
6. If you are creating a new virtual server, configure the virtual port set-
tings as applicable to your deployment.
7. When the virtual server configuration is complete, click OK.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Applying Source IP Limiting to a Virtual Port
1. Access the configuration page for the virtual server. (For information,
see “Applying Source IP Limiting to a Virtual Server” on page 589.)
2. On the Virtual Server Port configuration page, select the policy template
from the Policy Template drop-down list.
3. Click OK to return to the configuration page for the virtual server.
4. When the virtual server configuration is complete, click OK.
USING THE CLI
Applying System-Wide Source IP Limiting

To apply source IP limits to the whole system, use one of the following
commands at the global configuration level of the CLI:
[no] system glid num

Use this command if you plan to apply a combined set of limits to the whole
system.
[no] system template policy template-name

Use this command if you plan to apply per-client IP limiting at the system
level.
Note: The AX device does not support using the system template policy com-
mand and the system pbslb command in the same configuration.
Applying Source IP Limiting to a Virtual Server

To apply source IP limiting to a virtual server, use the following command
at the global configuration level for the virtual server:
[no] template policy template-name
Applying Source IP Limiting to a Virtual Port

To apply source IP limiting to a virtual port, use the following command at
the global configuration level for the virtual port:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Displaying IP Limiting Information
USING THE GUI
To view configuration information for the feature, navigate to the configura-

tion pages described in the previous sections.
To display statistics for the feature, use the CLI. (See the following section.)
USING THE CLI
To display configuration information for IP limiting, use the following com-

mands:
show class-list [name [ipaddr]]
show glid [num]
To display statistics for IP limiting, use the following commands:

show pbslb
show pbslb system
show pbslb client ipaddr
show pbslb virtual-server virtual-server-name
[port port-num service-type]
To reset statistics counters for IP limiting, use the following commands:

clear pbslb
clear pbslb system
clear pbslb client ipaddr entry
clear pbslb virtual-server virtual-server-name
[port port-num service-type [group-id group-id]]

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
CLI Examples—Configuration
The examples in this section show how to configure IP limiting.
Configure System-Wide IP Limiting With a Single Class

The following commands configure a standalone IP limiting rule to be
applied globally to all IP clients (the clients that match class list “global”):
AX(config)#glid 1
AX(config-global lid)#conn-rate-limit 10000 per 1
AX(config-global lid)#conn-limit 2000000
AX(config-global lid)#over-limit forward logging
AX(config)#system glid 1
The following commands configure class list “global”, which matches on

all clients, and uses IP limiting rule 1:
AX(config)#class-list global
AX(config-class list)#0.0.0.0/0 glid 1
Configure System-Wide IP Limiting With Multiple Classes

The commands in this example configure system-wide IP limiting using a
policy template.
AX(config)#slb template policy global_policy
AX(config-policy)#class-list name global_list
AX(config-policy-policy lid)#conn-rate-limit 20000 per 1
AX(config-policy-policy lid)#conn-limit 5000000
AX(config-policy-policy lid)#over-limit reset logging
The following command imports the class list used by the policy:
AX(config)#import class-list global_list ftp:
Password []?*********
File name [/]?global_list

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following command applies the policy to the system:
AX(config)#system template policy global_policy
Configure IP Limiting on a Virtual Server

The commands in this example configure IP limiting for a virtual server.
The following commands configure a policy template:

AX(config)#slb template policy vs_policy
AX(config-policy)#class-list name vs_list
AX(config-policy-policy lid)#conn-rate-limit 200 per 1
AX(config-policy-policy lid)#over-limit lockout 10 logging
AX(config)#import class-list vs_list ftp:
Password []?*********
File name [/]?vs_list
The following commands apply the policy to a virtual server:

AX(config)#slb virtual server vs1
AX(config-slb virtual server)#template policy vs_policy
Configure IP Limiting on a Virtual Port

The commands in this example configure IP limiting for a virtual port.
Note: In this example, IP limiting is applied to a virtual port on a virtual server

that also has IP limiting. Clients must conform to both sets of limits.
The following commands configure a policy template:

AX(config)#slb template policy vp_policy
AX(config-policy)#class-list name vp_list
AX(config-policy-policy lid)#request-rate-limit 50 per 1
AX(config-policy-policy lid)#request-limit 60000
AX(config-policy-policy lid)#over-limit reset logging

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX(config)#import class-list vp_list ftp:
Password []?*********
File name [/]?vp_list
The following commands apply the policy to a virtual port:

AX(config)#slb virtual server vs1
AX(config-slb virtual server-slb virtua...)#template policy vp_policy
Configure Class List Entries That Age Out

The following commands configure a class list with 2 host entries, and
assign an age value to each entry.
AX(config)#class-list local
AX(config-class list)#192.168.1.100 /32 lid 30 age 1
AX(config-class list)#192.168.1.101 /32 lid 30 age 10
The following commands configure a policy template. The template

includes an LID that sets the connection limit to 0. The LID also resets and
logs connection attempts.
AX(config)#slb template policy 1
AX(config-policy)#class-list name local
AX(config-policy-policy lid)#over-limit-action reset log
The following commands apply the policy template to a virtual port.

AX(config-slb vserver-vport)#template policy 1
In the configuration above, host 192.168.1.100 is not allowed to establish a

connection during the first minute after the host entry is created. After the

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
age expires, the host entry is removed form the class list, and the connection
limit no longer applies to the client.
Likewise, host 192.168.1.101 is not allowed to establish a connection dur-

ing the first 10 minutes after that host entry is created. Once the age expires,
the client is no longer locked down.
CLI Examples—Display
This section shows example show command output for IP limiting.
Class Lists
The following command displays the class-list files on the AX device:
AX#show class-list
Name IP Subnet Location
test 4 3 file
user-limit 14 4 config
Total: 2
Table 9 describes the fields in the command output.
TABLE 9 show class-list fields

Field Description
Name Name of the class list.
IP Number of host IP addresses in the class list.
Subnet Number of subnets in the class list.
Location Indicates whether the class list is in the startup-config or in a
standalone file:
• config – Class list is located in the startup-config.
• file – Class list is located in a standalone file.
Total Total number of class lists on the AX device.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following command shows details for a class list:
AX#show class-list test
Name: test
Total single IP: 4
Total IP subnet: 3
Content:
1.1.1.1 /32 glid 1
2.2.2.2 /32 glid 2
10.1.2.1 /32 lid 1
10.1.2.2 /32 lid 2
20.1.1.0 /24 lid 1
20.1.2.0 /24 lid 2
0.0.0.0 /0 lid 31
The following commands show the closest matching entries for specific IP
addresses in class list “test”:
AX#show class-list test 1.1.1.1
1.1.1.1 /32 glid 1
AX#show class-list test 1.1.1.2
0.0.0.0 /0 lid 31
The class list contains an entry for 1.1.1.1, so that entry is shown. However,
since the class list does not contain an entry for 1.1.1.2 but does contain a
wildcard entry (0.0.0.0), the wildcard entry is shown.
IP Limiting Rules
The following command the configuration of each standalone IP limiting
rule:
AX#show glid
glid 1
conn-limit 100
conn-rate-limit 100 per 10
request-limit 1
request-rate-limit 10 per 10
over-limit-action reset log 1
glid 2
conn-limit 20000
request-limit 200

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
glid 30
conn-limit 10000
over-limit-action forward log
The following command shows the configuration of IP limiting rule 1:

AX#show glid 1
glid 1
conn-limit 100
request-limit 1
IP Limiting Statistics
The following command shows IP limiting statistics for the entire system:
AX#show pbslb system
System LID statistics (lid 1):
Current connection: 1
Current connection rate: 0/s
Total over connection limit number: 0
Total over connection rate limit number: 0
System class list statistics:

Source Destination F Current Rate Over-limit Over-RL
---------------+---------------------+-+---------+---------+----------+----------
20.1.2.1 * C 0 0 0 0
Total: 1
The following command shows IP limiting statistics for virtual servers:
AX#show pbslb virtual-server
Virtual server class list statistics:
---------------+---------------------+-+---------+---------+----------+----------
1.1.1.1 20.1.11.1:80 R 0 0 0 2
20.1.2.1 20.1.11.1 C 0 0 0 0
20.1.2.1 20.1.11.1:80 C 0 0 0 0
Total: 3

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following command shows IP limiting statistics for clients:
AX#show pbslb client
Client class list statistics:
---------------+---------------------+-+---------+---------+----------+----------
1.1.1.1 20.1.11.1:80 R 0 0 0 2
20.1.2.1 * C 0 0 0 0
20.1.2.1 20.1.11.1 C 0 0 0 0
20.1.2.1 20.1.11.1:80 C 0 0 0 0
Total: 4

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Advanced Traffic Replication
The AX device includes a traffic replication feature that intercepts traffic

feeds, such as SNMP or Syslog packets, copies them to a buffer, and for-
wards the duplicated packet to multiple collector servers, where the data can
be used to track users and devices.
The new feature can be helpful for organizations that need Network Moni-
toring feeds to be replicated to multiple destinations. It represents a signifi-
cant improvement over alternative method that rely on servers processing
feeds and then forwarding them to other groups in an organization.
Figure 164 shows the topology used to discuss this traffic replication fea-
ture.
FIGURE 164 Topology for Traffic Replication
The figure shows an AX device connected to multiple real “collector” serv-

ers. The servers can be connected directly to the AX device (Server 5), or
they can be connected through a Layer 2 switch (Servers 1 and 2), or they
can be connected through a Layer 3 router (Servers 3 and 4).
Figure 165 shows how the traffic replication feature works:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
1. The Network Monitoring device (NM-1) sends traffic to the AX VIP.
2. As traffic passes through the AX device, it is vetted to see if it belongs

to one of the target NM traffic types, such as SNMP or Syslog. If the
traffic does belong to one of the NM traffic types, then duplicates are
made for each collector server and are stored locally on the AX device.
3. The original traffic from NM-1 is load balanced using standard SLB
algorithms and is sent to its original target destination (RS-1). This is
represented by the solid blue line in Figure 165.
4. The AX device applies one of the traffic replication options to the dupli-
cated packets. This “customization” of the duplicated packet changes
the MAC or IP in the packet’s header. These changes are needed to for-
ward the packets to multiple destinations (RS-2, RS-3, and RS-4). For-
warded packets are represented by the dotted blue lines.
While previous releases supported a port mirroring feature, it operated at the

port level and did not discriminate between different types of traffic. This
new approach to traffic replication provides better granularity by enabling
you to specify which parts of the source and destination addresses will be
replaced.
The feature allows you to bind a traffic replication mode to a normal VIP or
to a wildcard VIP, and that wildcard VIP can be associated with an ACL.
Separate VIPs can be created on the AX device to handle specific types of
traffic. For example, a VIP could be dedicated to receiving SNMP traffic.
When traffic is received on that VIP, (and assuming one of the replication

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
modes has been enabled), the SNMP traffic stream will be replicated to the
collector servers designated within the associated service group.
Note: Both TCP and UDP traffic types are supported, as long as the feature has
been enabled at the service group level.
Packet Header Changes

In general, most of the traffic replication options modify the headers of the
duplicated packets at Layer 2 by changing the MAC address. As Figure 166
shows, the traffic replication feature mainly affects the packet addressing at
Layer 2 and Layer 3.
Only one of the Traffic Replication modes, mirror IP-replacement, alters

the packets’ IP address and makes changes to the Layer 4 source and desti-
nation ports in the duplicated packets.
FIGURE 166 Changes to Packet Header
Details:
• When using the mirror IP-replacement option, the destination port
can be changed under the following circumstances:
• If the virtual port is set to wildcard port 0, and if the service group
members have different real ports configured, then the Layer 4 des-
tination port on the duplicated packets will be changed.
• If the virtual port is set to wildcard port 0, and if a service group
member is configured with port 80, then the Layer 4 destination port
on the duplicated packets will be changed to port 80.
Note: If the virtual port is set to wildcard port 0, and if a service group member
is configured with real port 0, then the Layer 4 destination port will not be
changed.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• If the virtual port is not set to wildcard port 0 but is instead set to
port 80, and if a service group member is configured with real port
81, then the Layer 4 destination port will be changed to port 81.
• When using the mirror IP-replacement option, the source port can be
changed under the following circumstances:
• The Layer 4 source port will only be changed if the original packet
being load balanced and replicated is changed. The reasons for this
change to the source port of the original packet, (and in the dupli-
cated packets) are unrelated to the Advanced Traffic Replication
feature.
• Source NAT can be used with the mirror IP-replacement option.
In this case, the Layer 4 source-port might be replaced for packets
that have been load balanced, but all of the replicated packets will
have the same source port as the packet that was load balanced.
Traffic Replication Modes

Traffic can be replicated or “mirrored” to the collector servers that are spec-
ified within a service group using one of the following traffic replication
modes:
• Mirror: This mode does not change the packet header at all. The origi-
nal Layer 2 Destination Address (DA) or Source Address (SA) and
Layer 3 IP addresses are left intact. The AX device simply sends the
packets “as is” to the collector server(s), and the forwarding is based on
the IP address in the original packet. Unlike other replication modes,
mirror mode replicates traffic to the client, in addition to replicating traf-
fic to the server. Only lower priority servers are used, so it is recom-
mended to define the collector servers as lower priority to ensure they
receive the replicated traffic.
• Mirror Destination MAC Address replacement: This mode uses
Layer 2 forwarding, with the AX device replacing the destination MAC
address on the incoming packet with the destination MAC for each of
the collector servers within the designated service group.
• Mirror IP-replacement: This mode replaces the incoming packet’s IP
address with the IP address of the collector server(s) and then forwards
the duplicated packet to those servers. This is the only mirroring option
that affects the packet at Layer 4, with minor changes being made to the
Layer 4 source and destination ports. This option is recommended for
scenarios in which collector servers are not directly connected to the AX
device.
• Mirror Source MAC Address and Destination MAC Address
replacement: This mode replaces both the source and destination MAC
addresses at Layer 2 but does not change the Layer 3 IP addressing
information.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• Mirror Source MAC Address replacement: This mode replaces the

source MAC address on the incoming packet with the MAC address cor-
responding to virtual server on the AX device. This option is recom-
mended for scenarios where not changing the source MAC can cause a
loop.
Traffic Replication Use Case Scenarios

Table 10 lists replication modes and associated use case scenarios for each.
TABLE 10 Traffic Replication Options and Use Cases

Traffic Replication
Option CLI Description Use Case Scenario
mirror Mirror Bi-directional Packet If UDP Network Management traffic col-
lectors operate in promiscuous mode, then
this mirror option can be used to replicate
traffic to collectors that are directly con-
nected to the AX.
mirror-da-repl Replace Destination MAC When the collector server is connected
through a Layer 2 network, or if the col-
lector server is not operating in promiscu-
ous mode, this option can be used to
require the destination MAC to be set with
the collector server's MAC.
mirror-ip-repl Replaces IP with server-IP If UDP Network Management traffic col-
lectors are not capable of operating in pro-
miscuous mode, then this “mirror-ip-rep”
option can be used to replicate traffic to
collectors that are not directly connected
to the AX device and which are on a dif-
ferent subnet.
This can be particularly useful with event
management applications (such as net-
cool), which employ an active/standby
architecture and replicate traffic between
the servers. This application can be
offloaded from the servers and onto the
AX device, thus improving performance.
mirror-sa-da-repl Replace Source MAC and Destination MAC This option is similar to the “mirror-da-
repl” option because the destination MAC
is replaced. However, in addition to the
destination MAC being replaced, the
source MAC will also be changed to the
AX device's MAC address, in order to pre-
vent network loops from occurring.
mirror-sa-repl Replace Source MAC This option is similar to the "mirror"
option because the source MAC address is
changed in order to provide additional pro-
tection and for identification purposes.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Implementation Details
Implementing the Traffic Replication feature is almost the same set of con-
figuration steps as required for a standard SLB. To configure this feature,
the following configurations are necessary:
1. Define a normal VIP (or a wildcard VIP) within the service group. If a
wildcard VIP is used, then an ACL should also be created to identify the
subnet of the network monitoring devices from which traffic will be
accepted.
2. Configure the real collector servers.
3. Configure a service group for the collector servers, add the real collector
servers to the service group, and define which of the traffic replication
modes will be used with the traffic-replication-type command.
USING THE GUI

To enable the Traffic Replication feature using the GUI, follow the steps
below:
1. Select Config Mode > Service > SLB > Service Group.
2. Click the name of the service group for which you would like to enable
the Traffic Replication feature.
The Service Group edit page appears, as shown in Figure 167 below.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
3. Click the Traffic Replication drop-down menu and select the desired
replication type for this service group.
4. Click OK to save your changes.
USING THE CLI
To configure a traffic replication mode, use the following command at the

service-group level of the CLI:
[no] traffic-replication-type
{
mirror |
mirror-da-repl |
mirror-ip-repl |
mirror-sa-da-repl |
mirror-sa-repl
}
CLI Example
1. The following commands define a VIP on the AX device.
AX(config)#slb virtual-server NM-VIP 10.10.10.99
2. The following commands configure the real collector servers.

AX(config)#slb server RS-1 10.10.20.1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
3. The following commands configure a service group for the collector

servers and add the real collector servers to the service group. The traf-
fic-replication-type command is then used to specify which traffic rep-
lication mode will be used to forward duplicated network monitoring
traffic to the collector servers.
AX(config)#slb service-group SG-RS tcp
AX(config-slb svc group)#member RS-1:0
AX(config-slb svc group)#traffic-replication-type mirror-da-repl

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration Using a Class List
Geo-location-based Access Control for VIPs
You can control access to a VIP based on the geo-location of the client. You
can configure the AX device to perform one of the following actions for
traffic from a client, depending on the location of the client:
• Drop the traffic
• Reset the connection
• Send the traffic to a specific service group (if configured using a black/
white list)
The AX device determines a client’s location by looking up the client’s sub-

net in the geo-location database used by Global Server Load Balancing
(GSLB).
Note: This feature requires you to load a geo-location database, but does not
require any other configuration of GSLB. The AX system image includes
the Internet Assigned Numbers Authority (IANA) database. By default,
the IANA database is not loaded but you can easily load it, as described in
the configuration procedure later in this section.

This section show how to configure geo-location-based VIP access using a
class list.
Note: In the current release, geo-location-based VIP access works only if the
class list is imported as a file. The CLI does not support configuration of
class-list entries for this application.
Example
The following class list maps client geo-locations to limit IDs (LIDs), which
specify the maximum number of concurrent connections allowed for clients
in the geo-locations.
L US 1
L US.CA 2
L US.CA.SJ 3
The following commands import the class list onto the AX device, config-
ure a policy template, and bind the template to a virtual port. The connec-

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
tion limits specified in the policy template apply to clients who send
requests to the virtual port.
This example assumes the default geo-location database (iana) is already

loaded.
AX(config)#import class-list c-share tftp:
File name [/]?c-share
Importing ... Done.
AX(config)#slb template policy pclass
AX(config-policy)#class-list name c-share
AX(config-policy-policy lid)#class-list lid 2
AX(config-policy-policy lid)#class-list lid 3
AX(config-policy)#geo-location overlap
AX(config-slb vserver-vport)#template policy pclass
The following command verifies operation of the policy:

AX(config-policy)#show slb geo-location statistics
M = Matched or Level, ID = Group ID

Conn = Connection number, Last = Last Matched IP
v = Exact Match, x = Fail
Virtual Server: vip1/80, c-share
--------------------------------------------------------------------------------
Max Depth: 3
Success: 3
Geo-location M ID Permit Deny Conn Last
--------------------------------------------------------------------------------
US.CA.SJ v 3 1 1 1 77.1.1.107
--------------------------------------------------------------------------------
Total: 1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuration Using a Black/White List

To configure geo-location-based access control for a VIP:
1. Configure a black/white list. You can configure the list using a text edi-
tor on a PC or enter it directly into the GUI. If you configure the list
using a text editor, import the list onto the AX device.
2. Configure an SLB policy (PBSLB) template. In the template, specify the

black/white list name, and the actions to perform for the group IDs in
the list.
3. Load a geo-location database, if one is not already loaded.
4. Apply the policy template to the virtual port for which you want to con-
trol access.
Configuring the 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. The black/white list must be a
text file that contains entries (rows) in the following format:
L "geo-location" group-id #conn-limit
The “L” indicates that the client’s location will be determined using infor-
mation in the geo-location database.
The geo-location is the string in the geo-location database that is mapped to

the client’s IP address; for example, “US”, “US.CA”, or “US.CA.SanJose”.
The group-id is a number from 1 to 31 that identifies a group of clients (geo-

locations) in the list. The default group ID is 0, which means no group is
assigned. On the AX device, the group ID specifies the action to perform on
client traffic.
The #conn-limit specifies the maximum number of concurrent connections

allowed from a client. The # is required only if you do not specify a group
ID. The connection limit is optional. For simplicity, the examples in this
section do not specify a connection limit.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Here is a simple example of a black/white list for this feature:
L "US" 1
L "US.CA" 2
L "JP" 3
USING THE GUI
To configure or import a black/white list using the GUI:

1. Select Config Mode > Service > PBSLB.
2. Click New.
• To import the list:
• Leave Remote selected.
• Enter a name for the list in the Name field.
• Enter the hostname or IP address in the Host field.
• Enter the file path and name in the Location field.
• To enter the file directly into the GUI:
• Select Local.
• Type the list into the Definition field.
3. Click OK.
To configure an SLB policy (PBSLB) template:

2. On the menu bar, select Application > PBSLB Policy.
3. Click Add.
5. From the drop-down list below the Name field, select the black/white
list.
6. Select a group ID from the Group ID drop-down list.
7. Select one of the following from the Action drop-down list.

• Drop – Drops new connections until the number of concurrent con-
nections 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• service-group-name – Each of the service groups configured on the
AX device is listed.
• create – This option displays the configuration sections for creating
a new service group.
8. Optionally, enable logging. (The AX device uses the same log rate limit-
ing and load balancing features for PBSLB logging as those used for
ACL logging. See the “"Log Rate Limiting” section in the “"Basic
Setup” chapter of the AX Series System Configuration and Administra-
tion Guide.)
9. Click Add.
10. Repeat step 6 through step 9 for each group ID.
11. Click OK.
To load the IANA geo-location database:

1. Select Config Mode > Service > GSLB.
2. On the menu bar, select Geo-location > Import.
3. In the Load/Unload section, enter “iana” in the File field. Leave the
Template field blank.
4. Click Add.
Note: If preferred, you can import a custom geo-location database instead. For
information, see the AX Series Global Server Load Balancing Guide.
To apply the policy template to a virtual port:

3. Select the virtual server or click Add to configure a new one.
4. If you are configuring a new VIP, enter the name and IP address for the
server.
5. In the Port section, select the port and click Edit, or click Add to add a
new port. The Virtual Server Port page appears.
6. Select the policy template from the PBSLB Policy Template drop-down
list.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
7. Click OK.
8. Click OK again to finish the changes and redisplay the virtual server list.
USING THE CLI

1. To import a black/white list onto the AX device, use the following com-
bw-list name url [period seconds] [load]
The name can be up to 31 alphanumeric characters long. The url speci-
fies the file transfer protocol, directory path, and filename. The follow-
ing URL format is supported: tftp://host/file
2. To configure a PBSLB template, use the following commands:

[no] slb template policy template-name
Enter this command at the global configuration level of the CLI. The
command creates the template and changes the CLI to the configuration
for the template, where the following PBSLB-related commands are
available.
[no] bw-list name file-name
This command binds a black/white list to the virtual ports that use this
template.
[no] bw-list id id
service {service-group-name | drop | reset}
[logging [minutes] [fail]]
This command specifies the action to take for clients in the black/white
list:
• id – Group ID in the black/white list.
• service-group-name – Sends clients to the SLB service group asso-
ciated 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.
3. To load a geo-location database, use the following command at the

[no] gslb geo-location load
{iana | file-name csv-template-name}

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
4. To apply the policy template to a virtual port, use the following com-
mand at the configuration level for the virtual port:
Displaying SLB Geo-Location Information

To display SLB geo-location information, use the following command:
show slb geo-location

[
virtual-server-name |
virtual-port-num |
bad-only |
[depth num]
[id num]
[location string]
[statistics]
]
The bad-only option displays only invalid or mismatched geo-location con-

tent.
The depth option specifies how many nodes within the geo-location data
tree to display. For example, to display only continent and country entries
and hide individual state and city entries, specify depth 2. By default, the
full tree (all nodes) is displayed.
The id option displays only the geo-locations mapped to the specified black/
white list group ID.
The location option displays information only for the specified geo-loca-
tion; for example “US.CA”.
Clearing SLB Geo-Location Statistics

To clear SLB geo-location statistics, use the following command at the Priv-
ileged EXEC level of the CLI:
clear slb geo-location

[
virtual-server name [...]
virtual-port-num |
location {all | string}
]

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Enabling Full-Domain Checking for Connection Limits
CLI Example
The following command imports black/white list “geolist” onto the AX
device.
AX(config)#import bw-list geolist scp://192.168.1.2/root/geolist
The following commands configure a policy template named “geoloc” and

add the black/white list to it. The template is configured to drop traffic from
clients in the geo-location mapped to group 1 in the list.
AX(config)#slb template policy geoloc
AX(config-policy)#bw-list name geolist
AX(config-policy)#bw-list id 1 drop
The following commands apply the policy template to port 80 on virtual

server “vip1”:
AX(config)#slb virtual-server vip1
AX(config-slb vserver-vport)#template policy geoloc
AX(config-slb vserver-vport)#show slb geo-location

By default, when a client requests a connection, the AX device checks the
connection count only for the specific geo-location level of the client. If the
connection limit for that specific geo-location level has not been reached,
then the client’s connection is permitted. Likewise, the permit counter is
incremented only for that specific geo-location level.
Table 11 shows an example set of geo-location connection limits and cur-
rent connections.
TABLE 11 Geo-location connection limit example

Current
Geo-location Connection Limit Connections
US 100 100
US.CA 50 37
US.CA.SanJose 20 19
Using the default behavior, the connection request from the client at
US.CA.SanJose ia allowed even though CA has reached its connection
limit. Likewise, a connection request from a client at US.CA is allowed.
However, a connection request from a client whose location match is simply
“US” is denied.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
After these three clients are permitted or denied, the connection permit and
deny counters are incremented as follows:
• US – Deny counter is incremented by 1.
• US.CA – Permit counter is incremented by 1.
• US.CA.SanJose – Permit counter is incremented by 1.
Full-Domain Checking
When full-domain checking is enabled, the AX device checks the current
connection count not only for the client’s specific geo-location, but for all
geo-locations higher up in the domain tree.
Based on full-domain checking, all three connection requests from the cli-
ents in the example above are denied. This is because the US domain has
reached its connection limit. Likewise, the counters for each domain are
updated as follows:
• US – Deny counter is incremented by 1.
• US.CA – Deny counter is incremented by 1.
USING THE GUI
This is configurable on the configuration page for the policy template. Nav-
igate to Config Mode > Service > Template > Application > Policy.
USING THE CLI

To enable full-domain checking for geo-location-based connection limiting,
use the following command at the configuration level for the PBSLB tem-
plate:
geo-location full-domain-tree
Note: It is recommended to enable or disable this option before enabling GSLB.

Changing the state of this option while GSLB is running can cause the
related statistics counters to be incorrect.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Enabling PBSLB Statistics Counter Sharing

You can enable sharing of statistics counters for all virtual servers and vir-
tual ports that use a PBSLB template. This option causes the following
counters to be shared by the virtual servers and virtual ports that use the
template:
• Permit
• Deny
• Connection number
• Connection limit
USING THE GUI
This is configurable on the configuration page for the policy template. Nav-
igate to Config Mode > Service > Template > Application > Policy.
USING THE CLI

To enable the share option, use the following command at the configuration
level for the PBSLB policy template:
geo-location share
Note: It is recommended to enable or disable this option before enabling GSLB.

Changing the state of this option while GSLB is running can cause the

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
Monitoring” on page 491.
• For information about GSLB parameters, see the AX Series Global
Server Load Balancing Guide.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SLB Packet Processing Order
SLB Packet Processing Order

Often, more than one set of configuration parameters applies to the same
packet. For example, SLB processing of an HTTP packet may include pro-
cessing of HTTP template parameters and TCP-proxy template parameters,
before server selection based on the service-group load-balancing method.
The packet processing order differs depending on whether the virtual port
type is Layer 4 or Layer 7.
Packet Processing Order for Layer 4 Virtual Ports

For Layer 4 virtual ports (TCP, UDP, or “Others”), template parameters are
processed in the following order:
1. DNS template
2. Policy template
3. All other types of templates
Packet Processing Order for Layer 7 Virtual Ports

For Layer 7 virtual ports (for example: HTTP), template parameters are pro-
cessed in the following order:
1. Layer 4 packet processing (described above in “Packet Processing
Order for Layer 4 Virtual Ports” on page 618)
2. Layer 7 server selection:

a. Cookie persistence template
b. aFleX policy (script)
c. All other types of templates

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Service Template Parameters

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 717.
For information about logging templates, see “Web Logging for HTTP
and RAM Caching” on page 219.
Table 15 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 information about the default settings in a template, see the section in
this chapter that describes the template.
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 12 Template Types Valid for Virtual Port Types

Virtual Port Type
F S T
D A S C
I D D S S L P
A N N T O R I - -
M S S - H T A P P P
E - - H H T H D R - S S R R T
T T U T F T T M E I T S T I M O T O F U
E C D T T T P M R U S I C P T X C X T D
Template Type R P P P P P S S S S P P P S P Y P Y P P
Cache V V
Cipher*
Client SSL † V V V V
Connection V V V V V
Reuse
Cookie V V V
Persistence
Diameter V V
DNS V V V V V V
Destination-IP V V V V V V V V V V V V V V V V V V V V
Persistence ‡
FTP V V V V V V V V V V V V V V V V V V V V
HTTP V V V
Policy V V V V V V V V V V V V V V V V V V
Server SSL V V V V V
SIP V V V
Source-IP V V V V V V V V V V V V V V V V V V V V
Persistence
SMTP V
SSL Session-ID V
Persistence
Streaming- V
media
TCP V V V V V V
TCP-Proxy V V V V V V V V V
UDP V V V V V V
**
*. Cipher templates can be added to client-SSL or server-SSL templates. They are not added directly to virtual ports.
†. To use a client-SSL template, you must install a valid certificate and key on the AX device, then configure the template to refer
to the certificate and key.
‡. Destination-IP persistence templates apply only to wildcard virtual ports.
**.In UDP templates, only the idle-timeout option is supported for TFTP virtual ports. The maximum idle-timeout supported for
TFTP is 255 minutes (15300 seconds).

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Cache Template Parameters

Table 14 lists the parameters you can configure in RAM caching templates.
TABLE 13 Cache Template Parameters

Parameter Description and Syntax Supported Values
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 Mode > Service > Template > Application > below.
RAM Caching Note: The default template can not be
modified.
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 Mode > 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
RAM Caching
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. The configurable range and default
[no] max-cache-size Mbytes depend on the AX model. See the CLI
or GUI.
RAM Caching
Maximum object Maximum object size that can be cached. The AX 1-268435455 bytes
size device will not cache objects larger than this size. Default: 81920 bytes (80 Kbytes)
[no] max-content-size bytes
RAM Caching

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 13 Cache Template Parameters (Continued)
Minimum object Minimum object size that can be cached. The AX 1-268435455 bytes
size device will not cache objects smaller than this size. Default: 512 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
Note: If a URI matches the pattern in more than one
policy rule, the rule with the most specific match is
used. Wildcard characters (for example: ? and *) are
not supported in RAM Caching policies.
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
Age header Disables insertion of Age headers into cached Default: Disabled (Age header inser-
insertion responses. tion is enabled.)
[no] disable-insert-age
RAM Caching

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 13 Cache Template Parameters (Continued)
Via header Enables insertion of Via headers into cached Default: Disabled (Age header inser-
insertion responses. tion is enabled.)
[no] disable-insert-via
RAM Caching
Cookie removal Removes cookies from server replies so the replies Default: Disabled
can be cached. RAM caching does not cache server
replies that contain cookies. (Image files are an
exception. RAM caching can cache images that
have cookies.)
[no] remove-cookies
RAM Caching
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Cipher Template Parameters

Table 14 lists the parameters you can configure in cipher templates. A
cipher template contains a list of ciphers. A client who connects to a virtual
port that uses the cipher template can use only the ciphers that are listed in
the template.
TABLE 14 Cipher Template Parameters

[no] slb template cipher Default: “default”. The default tem-
Config Mode > Service > Template > SSL > SSL below.
Cipher Note: The default template can not be
modified.
Cipher suite List of ciphers enabled by the template. For more information, see “Cipher
Template Options” on page 798.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Client-SSL Template Parameters

Table 15 lists the parameters you can configure in client SSL templates.
Note: If you replace a certificate and key in a client-SSL or server-SSL tem-

plate, you must unbind the template from the virtual ports that use it, then
rebind the template to the virtual ports, to place the change into effect.
TABLE 15 Client SSL Template Parameters

[no] slb template client-ssl Default: “default”. The default tem-
Config Mode > Service > Template > SSL > Client below.
SSL Note: The default template can not be
modified.
Certificate Name of the Certificate Authority (CA) certificate Name of a CA certificate imported
Authority (CA) to use for validating client certificates. onto the AX device
certificate name [no] ca-cert cert-name
Config Mode > Service > Template > SSL > Client
SSL
Note: To use the certificate, you must import it onto
the AX device. (See “Importing a Certificate and
Key” on page 804.)
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
SSL
Certificate Chain of certificates to use for terminating or initiat- String of 1-255 characters
key-chain name ing SSL connections with clients.
[no] chain-cert chain-cert-name
SSL
Certificate key Key for the certificate, and the passphrase used to Key name: string of 1-255 characters
encrypt the key. Passphrase: string of 1-16 characters
[no] key key-name Default: None configured
[passphrase passphrase-string]
SSL

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 15 Client SSL Template Parameters (Continued)
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 [no] client-certificate request the client to send its certifi-
client {ignore | request | require} cate.
Config Mode > Service > Template > SSL > Client • request – The AX device requests
SSL 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
SSL
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.)
Session cache Maximum number of cached sessions for SSL ses- 0-8000000
size sion ID reuse. Default: 0 (session ID reuse is dis-
[no] session-cache-size number abled)
SSL

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Close Closure alerts for SSL sessions. When this option is Enabled or disabled
notification enabled, the AX device sends a close_notify mes- Default: disabled
sage when an SSL transaction ends, before sending
a FIN. This behavior is required by certain types of
client applications, including PHP cgi. For this type
of client, if the AX device does not send a
close_notify, an error or warning appears on the cli-
ent.
Note: The Close Notify option can not be used
along with the TCP-proxy template Force Delete
Timeout option. Doing so may cause unexpected
behavior.
[no] close-notify
SSL
SSL False Start SSL False Start. SSL False Start is an SSL modifi- Enabled or disabled
cation used by the Google Chrome browser for web Default: enabled
optimization.
Note: The following ciphers are not supported in
the current release:
• SSL3_RSA_DES_64_CBC_SHA
• SSL3_RSA_RC4_40_MD5
• TLS1_RSA_EXPORT1024_RC4_56_MD5
If no other ciphers but these are enabled in the cli-
ent-SSL template, SSL False Start handshakes will
fail.
[no] ssl-false-start-disable
SSL
Forward proxy Options that can be used for SSL Intercept. Not set.
options [no] forward-proxy-ca-cert
certificate-name
[no] forward-proxy-ca-key
private-key-name
[no] forward-proxy-enable
SSL
For more information, see “SSL Intercept” on
page 315.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Server name Enables support for the Server Name Indication Not set.
indication (SNI) extension for Transport Layer Security (TLS).
The SNI extension enables servers that manage con-
tent for multiple domains at the same IP address to
use a separate server certificate for each domain.
One use for this feature is as part of an SSL Inter-
cept deployment.
cert certificate-name key private-
key-name
[partition shared]
SSL
Cipher template Name of a cipher template containing a set of Name of a configured cipher suite.
ciphers to use with clients. Default: No template assigned.
[no] template cipher template-name
SSL - SSL Cipher
Ciphers List of individual ciphers to support with clients. One or more of the following:
[no] cipher cipher-name • SSL3_RSA_DES_192_CBC3_SHA
Config Mode > Service > Template > SSL > Client • SSL3_RSA_DES_40_CBC_SHA
SSL - Cipher • SSL3_RSA_DES_64_CBC_SHA
• SSL3_RSA_RC4_128_SHA
• TLS1_RSA_AES_128_SHA256
• TLS1_RSA_AES_128_SHA
• TLS1_RSA_EXPORT1024_RC4_56
_MD5
_SHA
Default: All the above are enabled.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Connection Reuse Template Parameters

Table 16 lists the parameters you can configure in connection reuse tem-
plates.
TABLE 16 Connection Reuse Template Parameters

[no] slb template Default: “default”. The default tem-
connection-reuse template-name plate has the default values listed
Config Mode > Service > Template > Connection below.
Reuse Note: The default template can not be
modified.
Connection limit Maximum number of reusable connections per 0-65535. For unlimited connections,
server port. specify 0.
[no] limit-per-server number] Default: 1000
Config Mode > Service > Template > Connection
Reuse
Connection Number of new reusable connections to open before 1-1024 connections
keepalive beginning to reuse existing connections. You can Default: Not set
specify 1-1024 connections.
[no] keep-alive-conn number
Reuse
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)
Reuse

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Cookie Persistence Template Parameters

Table 17 lists the parameters you can configure in cookie persistence tem-
plates.
TABLE 17 Cookie Persistence Template Parameters

[no] slb template persist cookie Default: “default”. The default tem-
Config Mode > Service > Template > Persistent > below.
Cookie Persistence Note: The default template can not be
modified.
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 Mode > Service > Template > Persistent > Default: 10 years
Cookie 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 Mode > Service > Template > Persistent >
Cookie Persistence
Path Adds path information to the cookie. 1-31 characters
[no] path path-name Default: “ / ”
Cookie 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 Mode > Service > Template > Persistent > sistence cookie inserted by the AX
Cookie Persistence device, or if the server referenced by
the cookie is unavailable.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 17 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}
Cookie 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
Cookie 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
Cookie Persistence

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Destination-IP Persistence Template Parameters

Table 18 lists the parameters you can configure in destination-IP persistence
templates.
TABLE 18 Destination-IP Persistence Template Parameters

[no] slb template persist Default: “default”. The default tem-
destination-ip template-name plate has the default values listed
Destination IP Persistence Note: The default template can not be
modified.
Match type Granularity of persistence: One of the following:
• 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
[no] match-type
{server | service-group}
Destination IP Persistence

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 18 Destination-IP Persistence Template Parameters (Continued)
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
[no] netmask6 mask-length
Timeout Number of minutes the mapping of a client source 1-2000 minutes (about 33 hours)
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 18 Destination-IP Persistence Template Parameters (Continued)
Hash-based Enables hash-based persistence. Hash-based persis- Enabled or Disabled
persistence tence provides the persistence and performance ben- Default: Disabled
efits of hash-based load balancing, while allowing
use of advanced SLB features that require stateful
load balancing. For example, rate limiting is an
advanced SLB feature that requires stateful load
balancing.
Without this option, client sessions on a virtual port
that uses a source-IP persistence or destination-IP
persistence template do not use the session table.
Hash-based IP persistence does not use the session
table. Advanced SLB features can not be used in
this case, and no session information appears in the
session table.
[no] hash-persist
Diameter Template Parameters

Table 19 lists the parameters you can configure in Diameter templates used
for Diameter AAA load balancing.
TABLE 19 Diameter Template Parameters

[no] slb template diameter Default: None
template-name Note: The default template can not be
Config Mode > Service > Template > Application > modified.
Diameter
Origin-host Sets the value of Diameter AVP 264. String in the following format:
[no] origin-host host.realm host.realm
Config Mode > Service > Template > Application > Default: not set
Diameter
Multiple-origin- Prepends the AX CPU ID onto the origin-host string Enabled or disabled
host to identify the CPU used for a given Diameter peer Default: disabled. The CPU ID is not
connection. prepended onto the origin-host string.
[no] multiple-origin-host
Diameter

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 19 Diameter Template Parameters (Continued)
Origin-realm Sets the value of Diameter AVP 296. This AVP can String
be a character string and specifies the Diameter Default: None
realm from which Diameter messages, including
requests, are originated.
[no] origin-realm string
Diameter
Product-name Sets the value of Diameter AVP 269, which speci- String
fies the product; for example, “a10dra”. Default: None
[no] product-name string
Diameter
Vendor-ID Sets the value of Diameter AVP 266. This AVP can Number
be a numeric value and specifies the vendor; for Default: None
example, “156”. Make sure to use a non-zero value.
Zero is reserved by the Diameter protocol.
[no] vendor-id num
Diameter
AVP insertion Specifies custom AVP values to insert into Capabil- Supported values:
ities-Exchange-Request messages sent by the AX • avp-num – Diameter AVP number.
device to Diameter servers. For each custom AVP
• mandatory – Sets the AVP manda-
value to insert, you must specify the following
tory flag on. By default, this flag is
information:
off (not set).
avp-num [mandatory] {int32 | int64 | string} value
• int32 | int64 | string – Specifies the
You can configure up to 6 custom AVP values. If data format of the value to insert.
using the CLI, enter the command separately for
• value – Specifies the value to insert.
each AVP value.
Default: None
[no] avp avp-num [mandatory]

{int32 | int64 | string} value
Diameter
Customize CEA Replaces the AVPs in Capabilities-Exchange- Enabled or disabled
Answer (CEA) messages with the custom AVP val- Default: disabled
ues you configure before forwarding the messages.
[no] customize-cea
Diameter
Idle timeout Specifies the number of minutes a Diameter session 1-65535 minutes
can remain idle before the session is deleted. Default: 5 minutes
[no] idle-timeout minutes
Diameter

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Session age Specifies the absolute limit for Diameter sessions. 1-65535 minutes
Any Diameter session that is still in effect when the Default: 10 minutes
session age is reached is removed from the AX ses-
sion table.
[no] session-age minutes
Diameter
DWR time Specifies the maximum number of seconds the AX 0-2147483647 milliseconds (ms), in
device will wait for the reply to a device-watch-dog 100-ms increments
message sent to a Diameter server before marking Default: 10 seconds
the server Down..
[no] dwr-time ms
Diameter
Load balancing Enables load balancing of Diameter message codes, Valid message code number
for specific in addition to those already load balanced by Default: By default, Diameter load
message codes default. You can enable load balancing of up to 10 balancing applies only to the following
additional message codes. message codes (also called “command
[no] message-code num codes”):
Config Mode > Service > Template > Application > • Accounting-Request (code 271)
Diameter • Accounting-Answer (code 271)
• Capabilities-Exchange-Request
(code 257)
• Capabilities-Exchange-Answer
(code 257)
• Device-Watchdog-Request (code
280)
• Device-Watchdog-Answer (code
280)
• Session-Termination-Request (code
275)
• Session-Termination-Answer (code
275)
• Abort-Session-Request (code 274)
• Abort-Session-Answer (code 274)
• Disconnect-Peer-Request/Discon-
nect-Peer-Answer (code 282)
The AX device drops all other Diame-
ter message codes by default.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Accounting- Duplicates Accounting-Request messages and sends See left.
Request them to a separate service group. This option is use-
message ful for logging, accounting, and so on.
duplication To configure message duplication, configure real
servers and the service group, and use the duplicate
command to configure the following parameters:
• pattern – String pattern within the message.
• service-group – The duplication service group,
which is the service group to which to send the
duplicate messages.
[no] duplicate avp-num pattern

service-group
Diameter
Notes:
• To place the message duplication configuration
into effect, you must unbind the Diameter tem-
plate from the Diameter virtual port, then rebind
it.
• A Diameter template in which message duplica-
tion is configured can be bound to only a single
virtual port.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
DNS Template Parameters (DNS security)

Table 20 lists the parameters you can configure in DNS templates used for
DNS security.
TABLE 20 DNS Template Parameters - DNS security

[no] slb template dns template-name Default: None
DNS
Action for Action to take if the AX device detects a malformed Drop or forward
malformed DNS DNS query: To use the forward option, you also
queries • Drop – Drops the query must specify the service group name.
(DNS security) • Forward to service group – Forwards the query to Default: drop
another service group. This option is useful if you
want to quarantine and examine the malformed
queries, while still keeping them away from the
DNS server. You must specify the service group.
[no] malformed-query
{drop | forward service-group-name}
DNS
DNS Template Parameters (DNS caching per VIP)

Table 21 lists the parameters you can configure in DNS templates used for
per-VIP DNS caching.
TABLE 21 DNS Template Parameters - DNS caching

[no] slb template dns template-name Default: None
DNS

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 21 DNS Template Parameters - DNS caching (Continued)
Class list name Class list to use. The class list specifies the domain Name of a configured class list
matching options and the Limit IDs (LIDs) to use Default: not set
for caching.
DNS
Class list LID DNS caching rule. The settings in the rule apply to Limit ID – 1-31
queries for the domain names mapped to this rule in • Caching state – Enabled or disabled
the class list.
• Connection rate limit –
The following options can be configured: 1-4294967295 DNS connections per
• Caching state – State of the feature 1-65535 100-millisecond (ms) inter-
• Connection rate limit – Maximum DNS connec- vals. There is no default.
tion rate allowed before the over-limit action is • Over-limit action:
applied. • Drop
• Over-limit action – Action to take when the DNS • Enable caching
connection or request limit or rate is exceeded:
• Disable caching
• Drop
• Forward the traffic anyway
• Enable caching
• Reset the connection
• Disable caching
• Lock out further traffic from the
• Forward the traffic anyway sender for the specified number
• Reset the connection of minutes, 1-1023.
• Lock out further traffic from the sender for the
specified number of minutes. You also can Defaults:
specify a lockout time for any of the other
over-limit actions listed above. • Caching state – disabled
You can enable logging of over-limit actions. The • Connection rate limit – not set
over-limit messages are sent immediately. They • Over-limit action – drop
are not queued based on DNS cache logging set- • Logging – Logs are not generated
tings. when an over-limit action occurs.

The following commands are available at the con-
figuration level for the LID:
[no] conn-rate-limit rate per
interval
dns {cache-enable | cache-disable}
[no] dns ttl num
[no] dns weight num
[no] over-limit-action action

DNS

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 21 DNS Template Parameters - DNS caching (Continued)
Default caching Default action to take when a query does not match Cache or no-cache
policy any class-list entries. Default: no-cache
[no] default-policy
[cache | nocache]
DNS
Cache disable Disables DNS caching on all virtual DNS ports that Enabled or disabled
use the template. Default: caching is enabled
[no] disable-cache
DNS
Logging Logging for DNS caching. 1-10000 minutes
The period option specifies how often log messages Default: not set; logging is disabled
are generated. You can specify
[no] dns-log-enable period minutes
DNS
Maximum cache Maximum number of entries that can be cached per The maximum configurable amount
size VIP. depends on the AX model.
[no] max-cache-size num Default: maximum allowed on the
Config Mode > Service > Template > Application > entire system
DNS

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
HTTP Note: The default template can not be
modified.
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
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 stops using a ser-
vice port for 30 seconds after reassignment. The
second command does not.
[no] retry-on-5xx num
[no] retry-on-5xx-per-req num
HTTP
By default, logging of HTTP retries is disabled by

default. To enable logging of HTTP retries, use the
following command at the configuration level for
the HTTP template:
[no] log-retry
HTTP
Note: This option is supported only for virtual port
types HTTP and HTTPS. It is not supported for fast-
HTTP or any other virtual port type.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 22 HTTP Template Parameters (Continued)
Logging of Logs HTTP retries. An HTTP retry occurs when the Enabled or disabled
retries AX device resends a client’s HTTP request to a Default: disabled
server because the server did not reply to the first
request.
(HTTP retries are enabled using the retry-on-5xx or
retry-on-5xx-per-req option in the HTTP template.)
[no] log-retry
HTTP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-31 characters long.
level number |
minimum-content-length number} • exclude-content-type – Specifies the
types of content to exclude from
compression.
HTTP
• exclude-uri – Specifies URI strings
(up to 31 characters) to exclude
Note: Compression is supported only for HTTP and from compression.
HTTPS virtual ports. Compression is not supported
• keep-accept-encoding enable –
of fast-HTTP virtual ports.
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.
(cont.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 |
HTTP
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
HTTP
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.
Note: You can use URL switching or Host switch-
ing in an HTTP template, but not both.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
HTTP
ing in an HTTP template, but not both. However, if
you need to use both types of switching, you can do
so with an aFleX script.
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 Mode > Service > Template > Application > X-ClientIP field by default, without
HTTP replacing any client IP addresses
already in the field.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
HTTP
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}
HTTP
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
HTTP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 | equals}
[url-case-insensitive]
[url-hits-enable]
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.
• equals url-string – matches only if the URL
strings are the same.
If a URL matches on more than one match filter of
the same type, the most specific match is used.
The url-case-insensitive option enables case-insen-
sitive matching for URL switching rules. This
option does not change the case of any URLs. The
option simply allows URLs that have a mixture of
upper and lowercase (and that are not otherwise fil-
tered out based on the configuration).
The url-hits-enable option enables the counter for
URL hits.
Each URL matching pattern can be up to 64 bytes
long.
HTTP
ing in an HTTP template, but not both. However, if
you need to use both types of switching, you can do
so with an aFleX script.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
The offset option specifies how far into the string to
begin hash calculation. By default, there is no off-
set.
The use-server-status option enables server load
awareness, which allows servers to act as backups
to other servers, based on server load. (This option
requires some custom configuration on the server.
For information, see “URL Hash Switching with
Server Load Awareness” on page 181.)
[no] url-hash-persist
[offset offset-bytes]
{first | last} bytes
[use-server-status]
HTTP
Non-HTTP Redirects non-HTTP traffic to a specific service Enabled or disabled
bypass group, from the HTTP template configuration level, Default: disabled. The AX device
use the following command. drops non-HTTP requests that are sent
[no] non-http-bypass service-group to an HTTP port.
group-name
HTTP
Session Enables the AX device to terminate HTTP 1.1 client Enabled or disabled
termination for connections when the “Connection: close” header Default: disabled
non-compliant exists in the HTTP request. This option is applicable
HTTP 1.1 clients to connection-reuse deployments that have HTTP
1.1 clients that are not compliant with the HTTP 1.1
standard. Without this option, sessions for non-com-
pliant HTTP 1.1. clients are not terminated.
[no] term-11client-hdr-conn-close
HTTP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
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
Policy
Action for over- Specifies the action to take for traffic that is over the You can specify the following:
limit traffic limit. You can specify one or more of the following • Over-limit action – reset
options:
• Lockup – 1-127 minutes
• Lockup – Stops accepting new connection
• Logging – 1-255 minutes
requests for the specified number of minutes,
1-127.
• Logging – Generates a log message when traffic Default:
goes over the limit. The min option specifies the • Over-limit action – drop
log interval and can be 1-255 minutes. • Lockup – not set
• Reset – Resets new connections until the number • Logging – not set
of concurrent connections on the virtual port falls
below the connection limit.
Note: If the template uses a black/white list, the
Lockup over-limit action is applicable only if the
template is applied at the system level, for system-
wide PBSLB deployed for Sockstress protection. If
the template uses a class list, the Lockup over-limit
action is applicable regardless of whether the tem-
plate is applied at the system level or to an individ-
ual virtual server or virtual port.
[no] bw-list over-limit
{lockup min | logging min | reset}
Policy

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 23 Policy Template Parameters (Continued)
Timeout for Specifies the number of minutes dynamic black/ 1-127 minutes
dynamic clients white-list client entries can remain idle before aging Default: 5
out.
[no] bw-list timeout minutes
Note: The current release does not support configu-
ration of this option using the GUI.
Action Specifies the action to take for clients in the black/ The following settings are configu-
white list. rable:
[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 Mode > Service > Template > Application > SLB service group on the AX Series
Policy device.
• Action:
Note: If the option to use default selection if pre- • Drop – Drops new connections
ferred server selection fails is enabled on the virtual until the number of concurrent
port, log messages will never be generated for connections on the virtual port
server-selection failures. To ensure that messages falls below the port’s connection
are generated to log server-selection failures, dis- limit. (The connection limit is set
able the option on the virtual port. This limitation in the black/white list.)
does not affect failures that occur because a client is
• Reset – Resets new connections
over their PBSLB connection limit. These failures
until the number of concurrent
are still logged.
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-0026 - Ver. 2.7.0 11/1/2012
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] bw-list use-destination-ip on the client’s source IP address.
Policy
Class list IP Specifies the IP address to use for matching entries Client IP address, destination IP
address in an IP class list. address, or request header.
matching • Destination IP address – Matches based on the Default: Matching is based on the cli-
destination IP address instead of the source IP ent’s source IP address.
address.
• IP address in HTTP request – Matches based on
the IP address in a header in the HTTP request.
You can specify the header when you enable this
option.
[no] class-list client-ip
{l3-dest |
l7-header [header-name]}
Policy
Class list name Applies an IP class list to the template. Name of a configured class list
[no] class-list name name Default: not set
Policy
Note: Class lists can be configured only in the
shared partition. A policy template configured in the
shared partition or in a private partition can use a
class list configured in the shared partition.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Class list IP Configures an IP limiting rule for the IP limiting Valid values:
limiting rule feature. IP limiting rules have the following param- • Limit ID (LID) – 1-31
eters:
• Connection limit – 1-1048575
• Limit ID (LID) – Number from 1-31 that identi-
• Connection-rate limit –
fies the rule.
1-4294967295 connections. The
• Connection limit – Maximum number of concur- limit period can be 100-6553500
rent connections allowed for a client. milliseconds (ms), specified in
• Connection-rate limit – Maximum number of increments of 100 ms.
new connections allowed for a client within the • Request limit – 1-1048575
limit period.
• Request-rate limit – 1-4294967295
• Request limit – Maximum number of concurrent connections. The limit period can be
Layer 7 requests allowed for a client. 100-6553500 milliseconds (ms),
• Request-rate limit – Maximum number of Layer specified in increments of 100 ms.
7 requests allowed for a client within the limit • Over-limit action – Drop, Forward,
period. or Reset
• Over-limit action – Action to take when a client • Lockout period – 1-1023 minutes
exceeds one or more of the limits. The action can
• Logging – Enabled or disabled. The
be one of the following:
logging period can be 0-255 min-
• Drop – The AX device drops that traffic. If utes.
logging is enabled, the AX device also gener-
ates a log message.
• Forward – The AX device forwards the traffic. Default:
If logging is enabled, the AX device also gen- • Limit ID (LID) – None
erates a log message. • Connection limit – None
• Reset – For TCP, the AX device sends a TCP • Connection-rate limit – None
RST to the client. If logging is enabled, the AX • Request limit – None
device also generates a log message.
• Request-rate limit – None
• Lockout period – Number of minutes during
which to apply the over-limit action after the cli- • Over-limit action – Drop
ent exceeds a limit. The lockout period is acti- • Lockout period – None
vated when a client exceeds any limit. • Logging – Disabled. When logging
• Logging – Generates log messages when clients is enabled, the default logging
exceed a limit. When you enable logging, a sepa- period is 0 (no wait period).
rate message is generated for each over-limit
occurrence, by default. You can specify a logging
period, in which case the AX device holds onto
the repeated messages for the specified period,
then sends one message at the end of the period
for all instances that occurred within the period.

Policy

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Geo-location Matches black/white list entries based on the cli- Enabled or Disabled
overlap ent’s destination IP address. Default: Disabled. Matching is based
[no] geo-location overlap on the client’s source IP address.
Policy
Geo-location full Checks the current connection count not only for the Enabled or Disabled
domain checking client’s specific geo-location, but for all geo-loca- Default: Disabled. Checks the current
tions higher up in the domain tree. connection count not only for the cli-
[no] geo-location full-domain-tree ent’s specific geo-location
Policy
Geo-location Enables sharing of PBLSB statistics counters for all Disabled
statistics sharing virtual servers and virtual ports that use the tem-
plate. This option causes the following counters to
be shared:
• Permit
• Deny
• Connection number
• Connection limit
[no] geo-location share
Policy
Note: It is recommended to enable or disable this
option before enabling GSLB. Changing the state of
this option while GSLB is running can cause the

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Server-SSL Template Parameters

Table 28 lists the parameters you can configure in Server SSL templates.

TABLE 24 Server SSL Template Parameters

[no] slb template server-ssl Default: “default”. The default tem-
Config Mode > Service > Template > SSL > Server below.
SSL Note: The default template can not be
modified.
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 Mode > Service > Template > SSL > Server
SSL
Certificate name Certificate to use for terminating or initiating SSL Name of a certificate imported onto
connections with servers. the AX device
[no] cert cert-name
SSL
Certificate key Key for the certificate, and the passphrase used to Key name: string of 1-255 characters
encrypt the key. Passphrase: string of 1-16 characters
[no] key key-name Default: None configured
[passphrase passphrase-string]
SSL

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 24 Server SSL Template Parameters (Continued)
Close Closure alerts for SSL sessions. When this option is Enabled or disabled
notification enabled, the AX device sends a close_notify mes- Default: disabled
sage when an SSL transaction ends, before sending
a FIN. This behavior is required by certain types of
applications, including PHP cgi.
Note: The close notification option may not work if
connection reuse is also configured on the same vir-
tual port. In this case, when the server sends a FIN
to the AX device, the AX device will not send a FIN
followed by a close notification. Instead, the AX
device will send a RST.
Note: The Close Notify option can not be used
along with the TCP-proxy template Force Delete
Timeout option. Doing so may cause unexpected
behavior.
[no] close-notify
SSL
Version Security version: Secure Sockets Layer (SSL) v3.0 One of the following:
or Transport Layer Security (TLS) v1.0. • 30 – SSL v3.0
[no] version {30 | 31 | 32 | 33} • 31 – TLS v1.0
Config Mode > Service > Template > SSL > Server • 32 – TLS v1.1
SSL
• 33 – TLS v1.2
Default: TLS v1.0
Forward proxy Option that can be used for SSL Intercept. Not set.
options [no] forward-proxy-enable
SSL
For more information, see “SSL Intercept” on
page 315.
Cipher template Name of a cipher template containing a set of Name of a configured cipher suite.
ciphers to use with clients. Default: No template assigned.
[no] template cipher template-name
SSL - SSL Cipher

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 24 Server SSL Template Parameters (Continued)
Ciphers List of individual ciphers to support for decrypting One or more of the following:
certificates from servers. • SSL3_RSA_DES_192_CBC3_SHA
[no] cipher • SSL3_RSA_DES_40_CBC_SHA
Config Mode > Service > Template > SSL > Server • SSL3_RSA_DES_64_CBC_SHA
SSL
Note: For client certificates, the key length for
SSL3_RSA_DES_40_CBC_SHA and
SSL3_RSA_RC4_40_MD5 must be 512 bits or • SSL3_RSA_RC4_40_MD5
less. • TLS1_RSA_AES_128_SHA256
The TLS1_RSA_EXPORT1024_RC4_56_MD5 • TLS1_RSA_AES_256_SHA256
and TLS1_RSA_EXPORT1024_RC4_56_SHA • TLS1_RSA_AES_128_SHA
ciphers are not supported.
_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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SIP Template Parameters (SIP over TCP/TLS)

Table 25 lists the parameters you can configure in SIP templates for SIP
over TCP/TLS.
TABLE 25 SIP Template Parameters for SIP over TCP/TLS

[no] slb template sip template-name Default: None.
SIP
Client Enables the AX device to respond to SIP pings from Enabled or disabled
Keep-Alive clients on behalf of SIP servers. When this option is Default: Disabled
enabled, the AX device responds to a SIP ping from
a client with a “pong”. This option is disabled by
default.
Note: If connection reuse is configured, even if cli-
ent keepalive is disabled, the AX device will
respond to a client SIP ping with a pong.
[no] client-keep-alive
SIP
Server For configurations that use a connection-reuse tem- 5-300 seconds
Keep-Alive plate, this option specifies how often the AX device Default: Not set
sends a SIP ping on each persistent connection. The
AX device silently drops the server’s reply.
If the server does not reply to a SIP ping within the
connection-reuse timeout, the AX device closes the
persistent connection. (The connection-reuse time-
out is configured in the connection-reuse template.
See “Connection Reuse Template Parameters” on
page 629.)
Note: This option is applicable only if the configu-
ration includes a connection-reuse template.
[no] server-keep-alive seconds
SIP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 25 SIP Template Parameters for SIP over TCP/TLS (Continued)
Insert Client IP Inserts an “X-Forwarded-For: IP-address:port” Name of an IP header that inserts a cli-
header into SIP packets from the client to the SIP ent IP address.
server. The header contains the client IP address and Default: Disabled
source protocol port number. The AX device uses
the header to identify the client when forwarding a
server reply. This option is disabled by default.
[no] insert-client-ip
SIP
Client-request Inserts the specified SIP header into client requests. String of 1-256 characters
header insert client-request-header insert Default: None
header-name [insert-always |
SIP
Client-request Erases the specified SIP header from client requests. String of 1-256 characters
header erase client-request-header erase Default: None
header-name [all]
SIP
Client-response Inserts the specified SIP header into client String of 1-256 characters
header insert responses. Default: None
[no] client-response-header insert
SIP
Client-response Erases the specified SIP header from client String of 1-256 characters
header erase responses. Default: None
[no] client-response-header erase
header-name [all]
SIP
Server-request Inserts the specified SIP header into server requests. String of 1-256 characters
header insert [no] server-request-header insert Default: None
SIP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Server-request Erases the specified SIP header from server String of 1-256 characters
header erase requests. Default: None
[no] server-request-header erase
header-name [all]
SIP
Server-response Inserts the specified SIP header into server String of 1-256 characters
[no] server-response-header insert
SIP
Server-response Erases the specified SIP header from server String of 1-256 characters
[no] server-response-header erase
header-name [all]
SIP
Select Client Fail Specifies the AX response when selection of a SIP The action can be one of the following:
Action client fails. You can specify one of the following: • Reset
• String – Message string to send to the server; for • Drop
example: “480 Temporarily Unavailable”. If the
• Send message
message string contains a blank, use double quo-
tation marks around the string. Default: Reset
• Drop – Drops the traffic.
[no] failed-client-selection
{string | drop}
SIP
Select Server Specifies the AX response when selection of a SIP The action can be one of the following:
Fail Action server fails. You can specify one of the following: • Reset
• String – Message string to send to the client; for • Drop
example: “504 Server Time-out”. If the message
• Send message
string contains a blank, use double quotation
marks around the string. Default: Reset
• Drop – Drops the traffic.
[no] failed-server-selection
{string | drop}
SIP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Exclude Disables translation of the virtual IP address and Enabled or disabled
Translation Body virtual port in specific portions of SIP messages: Default: Disabled
• Body – Does not translate virtual IP addresses
and virtual ports in the body of the message.
• Header string – Does not translate virtual IP
addresses and virtual ports in the specified
header.
• Start line – Does not translate virtual IP addresses
and virtual ports in the SIP request line or status
line.
Note: Regardless of the settings for this option, the
AX device never translates addresses in “Call-ID”
or “X-Forwarded-For” headers.
[no] exclude-translation
{body | header string | start-line}
SIP
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
SIP
ALG for source Translates source IP address into the NAT IP Enabled or disabled
NAT address in SIP messages, when source NAT is used. Default: Disabled
[no] alg-source-nat
SIP
ALG for Translates the VIP address into the real server IP Enabled or disabled
destination NAT address in SIP messages, when destination NAT is Default: Disabled
used.
[no] alg-dest-nat
SIP
Call-ID Sends all SIP requests with a given call ID to the Enabled or disabled
persistence same server. Default: Enabled
[no] call-id-persist
SIP
Note: This option and the server-selection-per-
request option are mutually exclusive within the
same SIP template. You can enable one or the other
but not both.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Server selection Forces the AX device to perform the server selec- Enabled or disabled
per request tion process anew for every SIP request. Without Default: Disabled
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.
This option applies to SIP-TCP and SIPS virtual
ports. The option is unnecessary for SIP over UDP.
Pre-request server reselection automatically is used
for SIP over UDP.
[no] server-selection-per-request
SIP
SIP Template Parameters (SIP over UDP)

Table 26 lists the parameters you can configure in SIP templates for SIP
over UDP.
TABLE 26 SIP Template Parameters for SIP over UDP

[no] slb template sip template-name Default: None.
SIP
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
SIP
Client-request Inserts the specified SIP header into client requests. String of 1-256 characters
header insert client-request-header insert Default: None
SIP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 26 SIP Template Parameters for SIP over UDP (Continued)
Client-request Erases the specified SIP header from client requests. String of 1-256 characters
header erase client-request-header erase Default: None
header-name [all]
SIP
Client-response Inserts the specified SIP header into client String of 1-256 characters
[no] client-response-header insert
SIP
Client-response Erases the specified SIP header from client String of 1-256 characters
[no] client-response-header erase
header-name [all]
SIP
Server-request Inserts the specified SIP header into server requests. String of 1-256 characters
header insert [no] server-request-header insert Default: None
SIP
Server-request Erases the specified SIP header from server String of 1-256 characters
header erase requests. Default: None
[no] server-request-header erase
header-name [all]
SIP
Server-response Inserts the specified SIP header into server String of 1-256 characters
[no] server-response-header insert
SIP
Server-response Erases the specified SIP header from server String of 1-256 characters
[no] server-response-header erase
header-name [all]
SIP

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 26 SIP Template Parameters for SIP over UDP (Continued)
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
SIP
ALG for Translates the VIP address into the real server IP Enabled or disabled
destination NAT address in SIP messages, when destination NAT is Default: Disabled
used.
[no] alg-dest-nat
SIP
ALG for source Translates source IP address into the NAT IP Enabled or disabled
NAT address in SIP messages, when source NAT is used. Default: Disabled
[no] alg-source-nat
SIP
Reverse NAT Disables reverse NAT based on the IP addresses in ID of a configured extended ACL.
disable an extended ACL. This option is useful in cases Default: Not set. Reverse NAT is
where a SIP server needs to reach another server, enabled for all traffic from the 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] keep-real-server-ip-if-match-
acl acl-id
SIP
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-
SMTP Note: The default template can not be
modified.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 27 SMTP Template Parameters (Continued)
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
STARTTLS Disables support of certain SMTP commands. If a Any of the following: VRFY, EXPN,
command client tries to issue a disabled SMTP command, the TURN
disable 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 27 SMTP Template Parameters (Continued)
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 Mode > 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
Source-IP Persistence Template Parameters

Table 28 lists the parameters you can configure in source-IP persistence
templates.
TABLE 28 Source-IP Persistence Template Parameters

[no] slb template persist source-ip Default: “default”. The default tem-
Source IP Persistence Note: The default template can not be
modified.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 28 Source-IP Persistence Template Parameters (Continued)
Match type Granularity of persistence: One of the following:
• 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.
The scan-all-members option scans all members
bound to the template. This option is useful in
configurations where match-type “server” is
used, and where some members have different
priorities or are disabled. (For more information,
see “Scan-All-Members Option in Persistence
Templates” on page 785.)
• 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.
The scan all members option scans all members
bound to the template. This option is useful in
configurations where match-type “server” is
used, and where some members have different
priorities or are disabled. (See “Scan-All-Mem-
bers Option in Persistence Templates” on
page 785.)
(cont.)
Match type Note: To use URL switching or host switching, you
(cont.) also must configure an HTTP template with the
[no] match-type
{server [scan-all-members] |
service-group}
Source IP Persistence

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
[no] netmask6 mask-length
Timeout Number of minutes the mapping of a client source 1-2000 minutes (about 33 hours)
IP to a real server persists after the last time traffic Default: 5 minutes
from the client is sent to the server.
Note: The timeout for a source-IP persistent session
will not be reset if the timeout in the source-IP per-
sistence template is set to 1 minute. If the timeout is
set to 1 minute, sessions will always age out after 1
minute, even if they are active.
Include Includes the source port in persistent sessions. Enabled or Disabled
source port Note: If you use this option, the IP address in the Default: Disabled.
Forward Source column of show session output is
modified to include the source port. For example,
“155.1.1.151:33067” is shown as “1.151.129.43”.
[no] incl-sport

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
client source IP address.
Source-IP When this option is enabled, the AX device checks Enabled or Disabled
persistence for higher-priority servers, even if persistent ses- Default: Disabled.
override and sions are established between client and server.
reselect May be helpful for off-hours maintenance of pri-
mary servers. Traffic would be sent to backup serv-
ers. When maintenance is complete, persistent
sessions established with low-priority servers will
be broken in order to reselect primary servers.
[no] enforce-higher-priority
Hash-based Enables hash-based persistence. Hash-based persis- Enabled or Disabled
persistence tence provides the persistence and performance ben- Default: Disabled
efits of hash-based load balancing, while allowing
use of advanced SLB features that require stateful
load balancing. For example, rate limiting is an
advanced SLB feature that requires stateful load
balancing.
Without this option, client sessions on a virtual port
that uses a source-IP persistence or destination-IP
persistence template do not use the session table.
Hash-based IP persistence does not use the session
table. Advanced SLB features can not be used in
this case, and no session information appears in the
session table.
[no] hash-persist

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
SSL Session-ID Persistence Template Parameters

Table 29 lists the parameters you can configure in SSL session-ID persis-
tence templates.
TABLE 29 SSL Session-ID Persistence Template Parameters

[no] slb template persist ssl-sid Default: “default”. The default tem-
SSL Session ID Persistence Note: The default template can not be
modified.
Timeout Number of minutes the mapping of an SSL session 1-2000 minutes
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 Persistence
SSL session ID.
SSL Session ID Persistence

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Streaming-Media Template Parameters

Table 30 lists the parameters you can configure in streaming-media tem-
plates.
TABLE 30 Streaming-media Template Parameters

[no] slb template streaming-media Default: “default”. The default tem-
RTSP Note: The default template can not be
modified.
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.
RTSP
Note: This option is supported only for Windows
Media Server.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TCP Template Parameters

Table 31 lists the parameters you can configure in TCP templates.
TABLE 31 TCP Template Parameters

[no] slb template tcp template-name Default: “default”. The default tem-
Config Mode > Service > Template > L4 > TCP plate has the default values listed
below.
Note: In addition to configuring cus-
tom TCP templates, you can modify
the default TCP template.
CAUTION! Before changing a
default template, make sure the
changes you plan to make are appli-
cable to all virtual ports that use the
template.
Idle timeout Number of seconds a connection can remain idle 60-2097151 seconds (about 24 days)
before the AX Series device terminates it. Default: 120 seconds
Enter a value that is a multiple of 60 (60, 120, 1200,
and so on). If you enter a value that is not a multiple
of 60, the AX device rounds to the nearest, lowest
multiple of 60. For example, if you enter 70, the
value is rounded down to 60. Likewise, if you enter
110, the value is rounded down to 60.
[no] idle-timeout seconds
Config Mode > Service > Template > L4 > TCP
Force delete Maximum time that a session can stay in the system 1-31 seconds
timeout before being deleted. Default: not set
This option forces deletion of any session that is still
active after the specified number of seconds.
This option is useful for small, fast transactions for
which the completion time of sessions is guaran-
teed. When used in combination with the reset-fwd
and reset-rev options, the force-delete-timeout
option can help clean up user connections with
RSTs instead of allowing the connections to hang.
[no] force-delete-timeout seconds

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 31 TCP Template Parameters (Continued)
Aging of half- Enables aging of half-closed TCP sessions. A half- 60-15000 seconds
closed sessions closed TCP session is a session in which the server Default: Not set. The AX device keeps
sends a FIN but the client does not reply with an half-closed sessions open indefinitely.
ACK.
[no] half-close-idle-timeout
seconds
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
LAN fast Increases performance of bidirectional peer sessions Enabled or disabled
acknowledge- by acknowledging receipt of data on behalf of cli- Default: Disabled
ment ents and servers.
[no] lan-fast-ack

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TCP-Proxy Template Parameters

Table 31 lists the parameters you can configure in TCP-proxy templates.
TABLE 32 TCP-Proxy Template Parameters

[no] slb template tcp-proxy Default: “default”. The default tem-
Config Mode > Service > Template > TCP Proxy below.
tom TCP-proxy templates, you can
modify the default TCP-proxy tem-
plate.
template.
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 Mode > Service > Template > TCP Proxy
Idle timeout Number of seconds that a connection can be idle 60-2097151 seconds (about 24 days)
before the AX Series terminates the connection. Default: 600 seconds
of 60, the AX device rounds to the nearest multiple
of 60. For example, if you enter 70, the actual time-
out is 60 seconds.
[no] idle-timeout seconds
Half-close idle Enables aging of half-closed TCP sessions. A half- 60-15000 seconds
timeout closed TCP session is a session in which the server Default: Not set. The AX device keeps
ACK.
seconds

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 32 TCP-Proxy Template Parameters (Continued)
Force delete Maximum time that a session can stay in the system 1-31 seconds
timeout before being deleted. Default: not set
This option forces deletion of any session that is still
active after the specified number of seconds.
This option is useful for small, fast transactions for
which the completion time of sessions is guaran-
teed. When used in combination with the reset-fwd
and reset-rev options, the force-delete-timeout
option can help clean up user connections with
RSTs instead of allowing the connections to hang.
Note: The Force Delete Timeout option can not be
used along with the client-SSL or server-SSL tem-
plate Close Notify option. Doing so may cause
unexpected behavior.
[no] force-delete-timeout seconds
Aging of half- Enables aging of half-closed TCP sessions. A half- 60-15000 seconds
closed sessions closed TCP session is a session in which the server Default: Not set. The AX device keeps
ACK.
seconds
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
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: 51200 bytes
[no] receive-buffer number

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
Transmit buffer Number of bytes sent by the port that the AX Series 1-2147483647
size will buffer. Default: 51200 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TCP window Sets the TCP window scaling factor for backend 1-14
scaling factor connections to servers. Default: 1
The TCP window scaling factor is applicable to vir- Note: The default window scaling fac-
tual ports for which the AX device acts as a TCP tor for front end connections (connec-
proxy. tions to clients) is 2, and is not
The TCP window scaling factor is used to calculate configurable.
the TCP receive window, which is the maximum
amount of data (in bytes) the receiver on a TCP con-
nection will buffer. The sender is not allowed to
send more than this amount of data before receiving
an acknowledgement that the data has arrived.
Each side of a TCP connection sends its receive
window settings during the 3-way handshake used
to establish the connection. The receive window
size is calculated as follows:
TCP-receive-window *
2^window-scaling-factor =
TCP-receive-window
For example, if the TCP window value is 2048
bytes and the window scaling factor is 6, the win-
dow value is 131,072.
2048 * 64 = 131,072
In this case, the sender can send a maximum of
131,072 bytes before receiving acknowledgement
that the data has arrived.
[no] backend-wscale num
Maximum Changes the minimum supported TCP Maximum 128-4312 octets
segment size Segment Size (MSS). Default: 538
(MSS) [no] mss octets
Reno Enables the TCP Reno congestion control algo- Enabled or disabled
rithm, and disables Cubic. Default: disabled. Cubic is used
[no] reno instead.
Initial Specifies the maximum number of unacknowledged 1-10
congestion packets that can be sent on a TCP connection. Default: 4 segments
window A large initial congestion-control window size helps
reduce HTTP response latency, especially for short
web pages.
[no] init-cwnd num

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
ACK Specifies the cases in which the AX device sends an High, medium, or low
aggressiveness ACK to the client. You can set ACK aggressiveness Default: low
to one of the following levels:
• High – ACK for each packet
• Medium – Delayed ACK, with ACK on each
packet with PUSH flag
• Low – Delayed ACK
A high ACK aggressiveness helps reduce the delay
of interactive client-server applications, but at a cost
of more ACKs.
[no] ack-aggressiveness
{high | medium | low}

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Keepalive Periodically verifies that a TCP-proxy session is Keepalive interval – 60-12000 seconds
still up on both ends of the session. Probe count of – 2-10
The feature uses the following configurable parame-
ters:
Defaults:
• Keepalive interval – Number of seconds a TCP-
• Keepalive interval – 75 seconds
proxy session can remain idle before the AX
device sends a TCP ACK to the devices on both • Probe count – 9
ends of the session.
• Keepalive probe count – Maximum number of
times the AX device sends a keepalive ACK,
before deleting the session.
The AX device sends the first keepalive ACK if a
session remains idle for the duration of the keepal-
ive interval:
• If both devices respond with an ACK before the
next keepalive interval expires, the AX device
resets the keepalive time to 0. This starts a new
keepalive interval.
• If either device does not respond with an ACK
before the next keepalive interval expires, the
action taken by the AX device depends on the
setting of the keepalive probe count.
• Keepalive probe count set to value greater
than 1 – The AX device sends another ACK to
each device.
If both devices respond, the AX device resets
the keepalive time to 0, to begin a new keepal-
ive interval.
If either device does not respond, the AX
device sends another ACK to each device. This
action can be repeated up to the configured
maximum number of probes (the probe count).
• Keepalive probe count set to 1 – The AX
device does not send new probe ACKs.
Instead, the AX device deletes the session.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Keepalive Relation of Keepalive to Idle-timeout
(cont.) The keepalive and idle-timeout options work inde-
pendently of one another.
By default, the keepalive interval is shorter than the
idle timeout. In this case, keepalive probes are trig-
gered before the idle timeout expires.
• If both devices respond with an ACK before
either of the following occurs, the keepalive
interval time and the idle time are both reset to 0.
• Idle timeout expires – If this occurs, the ses-
sion is deleted, even if the maximum number
of keepalive probes have not been sent.
• Maximum number of keepalive probes are
sent, but at least one of the devices still does
not respond – In this case, the session is
deleted even if the idle timeout has not expired.
If you change the keepalive or idle-timeout settings
so that the idle timeout is shorter than the keepalive
interval, the keepalive mechanism is never trig-
gered. The idle timeout always expires first, causing
the session to be deleted. No keepalive probes are
ever sent.
Note: The default idle-timeout setting is 300 sec-
onds.
[no] keepalive-interval seconds
[no] keepalive-probes num

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
UDP Template Parameters

Table 33 lists the parameters you can configure in UDP templates.
TABLE 33 UDP Template Parameters

[no] slb template udp template-name Default: “default”. The default tem-
Config Mode > Service > Template > L4 > UDP plate has the default values listed
below.
tom UDP templates, you can modify
the default UDP template.
template.
Aging Specifies how quickly sessions are terminated when One of the following:
the request is received. • Immediate
aging {immediate | short [seconds]} • Short, with an aging period of 1-6
Config Mode > Service > Template > L4 > UDP seconds
Default: Not set.
• Immediate aging: • If a response is received – Behavior
• Response Received – differs based on port number:
Session is terminated within 1 second. • Port 53 (default DNS port) – Ses-
• No Response – Idle timeout value in UDP tem- sion is terminated within 1 sec-
plate is used. ond.
• Short aging: • Any other port number – Session
is terminated after the idle time-
• Response Received –
out expires.
Session is terminated within 1 second.
• If there is no response – Idle timeout
• No Response – Session is terminated after con-
value in UDP template is used.
figured short aging period.
If you enable short aging, the default
Note: If you are configuring DNS load balancing,
aging period is 3 seconds.
A10 Networks recommends using the immediate
option.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
System-wide SLB Parameters
TABLE 33 UDP Template Parameters (Continued)
Idle timeout Number of seconds a connection can remain idle 60-2097151 seconds (about 24 days)
before the AX Series terminates it. Default: 120 seconds
Note: The maximum idle timeout sup-
of 60, the AX device rounds to the nearest multiple
ported for TFTP virtual ports is 255
of 60. For example, if you enter 70, the actual time-
minutes.
out is 60 seconds.
[no] idle-timeout number
Config Mode > 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 Mode > Service > Template > L4 > UDP

Table 35 lists the SLB parameters you can configure globally.
TABLE 34 System-wide 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 Mode > Service > SLB > Server

Config Mode > Service > SLB > Virtual Server
Gateway health Enables gateway health monitoring. Interval – 1-180 seconds
check [no] slb gateway-health-check Timeout – 1-60 seconds
[interval seconds Default:
[timeout seconds]] • Interval – 5
Note: The current release does not support configu- • Timeout – 15
ration of this feature using the GUI.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 34 System-wide SLB Parameters (Continued)
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 Mode > Service > SLB > Global > Settings
Note: Additional configuration is required. See
“Configuring Health Monitoring of Virtual IP
Addresses in DSR Deployments” on page 506.
Graceful Enables the AX device to wait for the specified 1-65535 seconds (about 18 hours)
shutdown grace period before moving active sessions on a Default: Not set. When you delete a
deleted or disabled port or server to the delete real or virtual service port, the AX
queue. device places all the port’s sessions in
[no] slb graceful-shutdown the delete queue, and stops accepting
grace-period new sessions on the port.
[server | virtual-server]
[after-disable]
Maximum Maximum session life following completion of a 1-40 seconds
session life TCP flow. Default: 2 seconds
[slb] msl-time seconds

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 supported only on models
AX 2200, AX 3200, AX 3200-11, AX 3200-12,
AX 3400, AX 5100, AX 5200, AX 5200-11, and
AX 5630.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 [no] slb conn-rate-limit src-ip • 100 milliseconds (one tenth of a
{tcp | udp} 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 the applies separately to each virtual
“Traffic Security Features” chapter of the AX Series port. (This is the default behavior.
System Configuration and Administration Guide. 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-0026 - Ver. 2.7.0 11/1/2012
DNS caching Configures the AX device to locally cache DNS Enabled or disabled
responses to client requests. The cache aging timeout can be
Note: A DNS reply begins aging as soon as it is 1-1000000 seconds.
cached and continues aging even if the cached reply Default: disabled. When you enable
is used after aging starts. Use of a cached reply does DNS caching, replies with a single or
not reset the age of that reply. multiple IP addresses in the ANSWER
[no] dns-cache-enable section can be cached. The default
[ cache aging timeout is 300 seconds.
round-robin
[ttl-threshold seconds] |
single-answer
[ttl-threshold seconds] |
ttl-threshold seconds
]
[no] dns-cache-age seconds
Source NAT on Globally enables IP NAT support for VIPs. Enabled or disabled
VIP Source IP NAT can be configured on a virtual port Default: disabled
in the following ways:
• ACL-SNAT Binding at the virtual port level
• VIP source NAT at the global configuration level
• aFleX policy bound to the virtual port
• Source NAT Pool at the virtual port level
These methods are used in the order shown above.
For example, if IP source NAT is configured using
an ACL on the virtual port, and VIP source NAT is
also enabled globally, then a pool assigned by the
ACL is used for traffic that is permitted by the ACL.
For traffic that is not permitted by the ACL, the
globally configured VIP source NAT can be used
instead.
Note: The current release does not support source
IP NAT on FTP or RTSP virtual ports.
[no] slb snat-on-vip
Layer 7 request Globally enables Layer 7 request accounting. Enabled or disabled
accounting Note: Layer 7 request accounting is automatically Default: disabled
enabled for service groups that use the least-request
load-balancing method.
To display Layer 7 request statistics, view details
for the service group, real port, or virtual port.
[no] slb enable-l7-req-acct

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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
certain models. If this option does not appear on
your AX device, the device does not contain a com-
pression module.
[no] slb hw-compression
Idle timeout for Sets the idle timeout for pass-through TCP sessions. Name of a configured TCP template.
passthrough TCP A pass-through TCP session is one that is not termi- To use the default TCP template, spec-
sessions nated by the AX device (for example, a session for ify the name “default”.
which the AX device is not serving as a proxy for Default: The default idle timeout for
SLB). pass-through TCP sessions is 30 min-
Specify the name of a TCP template. The idle time- utes. The default idle timeout in TCP
out in the TCP template is used. templates is 120 seconds.
Only the idle timeout setting in the specified TCP
template is applicable to pass-through TCP ses-
sions. None of the other options in TCP templates
affect pass-through TCP sessions.
The maximum idle timeout supported for transpar-
ent sessions is 15300 seconds. This is true even if
the idle timeout in the TCP template itself is set to a
higher value. Higher idle timeout values apply only
to SLB sessions, not to transparent sessions. This
is because transparent sessions are stateless and can
be recreated if timed out.
[no] slb transparent-tcp-template
template-name
GUI.
Trunk load Disables or re-enables trunk load balancing of Enabled or disabled
balancing Layer 2/3 traffic. Default: Enabled.
[no] slb l2l3-trunk-lb-disable
GUI.
Fast-path Disables fast-path processing. Enabled or disabled
processing [no] slb fast-path-disable Default: Fast-path processing is ena-
Config Mode > Service > SLB > Global > Settings bled.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TCP Maximum Changes the minimum TCP MSS the AX device 128-750
Segment Size allows for client traffic. Default: 538
(MSS) [no] slb mss-table num
GUI.
SLB application Fine-tunes thresholds for SLB buffer queues. The supported values and defaults
buffer threshold • Hardware buffer – IO buffer threshold. For each depend on the AX model. See the CLI
CPU, if the number of queued entries in the IO online help.
buffer reaches this threshold, fast aging is ena-
bled and no more IO buffer entries are allowed to
be queued on the CPU’s IO buffer.
• Relieve threshold – Threshold at which fast aging
is disabled, to allow IO buffer entries to be
queued again.
• Low buffer threshold – Threshold of queued sys-
tem buffer entries at which the AX begins refus-
ing new incoming connections.
• High buffer threshold – Threshold of queued sys-
tem buffer entries at which the AX device drops a
connection whenever a packet is received for that
connection.
[no] slb buff-thresh hw-buff num
relieve-thresh num sys-buff-low num
sys-buff-high num
GUI.
Compression Changes the default compression block size used for 6000-32000 bytes
block size SLB. Default: 16000 bytes
[no] compress-block-size bytes
Config Mode > Service > SLB > Global > Rate-
Limit Log
DDoS Protection See the “Traffic Security Features” chapter of the Default: Not set
AX Series System Configuration and Administration
Guide.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Log rate limiting Configures rate limiting settings for system logging: • Max-local-rate – 1-100 messages
• Max-local-rate – Specifies the maximum number per second
of messages per second that can be sent to the • Max-remote-rate – 1-100000 mes-
local log buffer. sages per second
• Max-remote-rate – Specifies the maximum num- • Exclude-destination – Local,
ber of messages per second that can be sent to remote, or both
remote log servers. Defaults:
• Exclude-destination – Excludes logging to the • Max-local-rate – 32 messages per
specified destination. second
• Max-remote-rate – 15000 messages
slb rate-limit-logging per second
[max-local-rate msgs-per-second]
• Exclude-destination – Logging to
[max-remote-rate msgs-per-second]
both destinations is enabled.
[exclude-destination {local |
remote}]
Config Mode > Service > SLB > Global > Rate-
Limit Log
SSL expiration Sends a warning email when a certificate used for Before – 1-5 days
checking SLB is about to expire. Interval – 1-5 days
• The before option specifies how many days
before expiration to begin sending notification
Default: not set. When you configure
emails.
the feature, it has the following
• The interval option specifies how many days defaults:
after expiration to continue sending notification
• Before – 5 days
emails.
• Interval – 2 days
One notification is sent per day. If a certificate is
updated before expiration or at least before the con-
figured interval, no more notification emails are
sent for that certificate.
[no] slb ssl-expire-check

email-address address [...]
[before days] [interval days]
Config Mode > Service > SSL Management > Expi-
ration Mail
Statistics Globally disables or re-enables collection of statisti- Enabled or disabled
collection cal data for system resources and for load-balancing Default: Statistical data collection for
resources. system resources is enabled by default.
stats-data-disable This also allows collection for those
stats-data-enable individual load-balancing resources on
which collection is enabled.
Note: Statistical data collection for load-balancing
resources also must be enabled on the individual Statistical data collection also is ena-
resources. bled by default on individual load-bal-
ancing resources.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Real Server Parameters
Stale session Please contact A10 Networks for information. Enabled or disabled
reset [no] reset-stale-session Default: Disabled
Maximum Please contact A10 Networks for information. Enabled or disabled
buffer queue per [no] max-buff-queued-per-conn num Default: Disabled
connection Note: The current release does not support configu-
SSL Disables or re-enables the SSL acceleration module, Enabled or disabled
acceleration if the device has one. Disabling the SSL accelera- Default: Enabled
module state tion module reverts SSL processing to software.
[no] slb ssl-module software

Table 35 lists the parameters you can configure on real servers.
TABLE 35 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 [no] slb server server-name ipaddr characters
Config Mode > Service > SLB > Server IPv4 or IPv6
address
Note: The name does not need to match the host-
name configured on the server. Default: None con-
figured
Server state State of the real server. Enabled or disa- No
[no] {disable | enable} bled
Config Mode > Service > SLB > Server Default: Enabled
Real server Configuration template of real server parameters. Name of a config- N/A
template [no] template server template-name ured real server
template
Default: “Default”
real server tem-
plate

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 35 Real Server Parameters (Continued)
Configurable in
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 Mode > Service > SLB > Server tor
Default: Enabled;
ping (ICMP)
Connection Number of concurrent connections allowed on a real 1-8000000 Yes
limit server. Default: 8000000
[no] conn-limit max-connections
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 Mode > Service > SLB > Server - Port Port number:
0-65534
(For parameters you can set on the service port, see
“Real Service Port Parameters” on page 692.) 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
the number of new connections on the server. Default: Disabled
[no] slow-start
Config Mode > Service > SLB > Server - Port
Note: It is recommended to configure this feature in
the real server template or real port template
instead. See “Behavior When Slow Start Is Also
Configured on the Real Server Itself” on page 733.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
Weight Administrative weight of the server, used for 1-100 Yes
weighted load balancing (weighted-least-connection Default: 1
or weighted-round-robin).
[no] weight num
Alternate Alternate server to use as a dedicated backup for a Sequence number No
servers for primary server. You can assign up to 16 servers as 1-16
backup dedicated backups. (See “Alternate Servers and Default: not set
Ports for Individual Backup” on page 761.)
[no] alternate sequence-num
server-name
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
Spoofing Enables support for a spoofing cache server. A Enabled or disa- Yes
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 “Transparent Cache
Switching” on page 395.)
[no] spoofing-cache
Statistics Enables or disables collection of statistical data for Enabled or Yes
collection the server. disabled
stats-data-enable Default: enabled
stats-data-disable
Extended Enables collection of peak connection statistics. Enabled or Yes
statistics [no] extended-stats disabled
Config Mode > Service > SLB > Server Default: disabled
HA priority Decreases the HA priority of an HA group, if the Weight: 1-255 Yes
cost real server’s health status changes to Down. HA group: 1-31. If
[no] ha-priority-cost weight no group is speci-
[ha-group group-id] fied, the weight
Config Mode > Service > SLB > Server applies to all HA
groups.
Default: not set

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Real Service Port Parameters
Configurable in
GSLB IPv6 Assigns an IPv6 address to the real server for Valid IPv6 address No
mapping GSLB. Default: None
[no] ipv6 ipv6-addr

Table 36 lists the parameters you can configure on individual service ports
on real servers.
TABLE 36 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
tocol
In the CLI, this is set at the real server configuration Note: Port num-
level. In the GUI, this is set in the Port section of the ber 0 is a wildcard
Server page. port used for IP
protocol load bal-
ancing. (For more
information, see
“IPv4 Load Bal-
ancing” on
page 99.)
Service port State of the service port. Enabled or disa- No
state [no] {disable | enable} bled
Config Mode > Service > SLB > Server - Port Default: Enabled
Real server Configuration template of real port parameters. Name of a config- N/A
port template [no] template port template-name ured real port tem-
plate
Default: “Default”
real port template

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 36 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 (The follow-port
To base the port’s health on the health of another Name of a config- option can not be
port of the same type on the same server, use the fol- ured health moni- configured using a
low-port option instead. tor template.)
[no] health-check Default: The AX
[monitor-name | performs the
follow-port portnum method-type] default TCP or
Config Mode > Service > SLB > Server - Port UDP check every
5 seconds. (See
“Default Health
Checks” on
page 491.)
Connection Number of concurrent connections allowed on the 1-8000000 Yes
limit service port. Default: 8000000
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
Alternate Alternate server and port to use as a dedicated Sequence number No
servers for backup for this port. (See “Alternate Servers and 1-16
port backup Ports for Individual Backup” on page 761.) Default: not set
[no] alternate sequence-num server-
name port portnum
Note: The current release does not support this
option in the GUI.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 36 Real Service Port Parameters (Continued)
Configurable in
Supported Real Port
No-SSL Disables SSL for server-side connections. This Enabled or Yes
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
Statistics Enables or disables collection of statistical data for Enabled or Yes
collection the port. disabled
stats-data-disable
Extended Enables collection of peak connection statistics. Enabled or Yes
Config Mode > Service > SLB > Server - Port Default: disabled
HA priority Decreases the HA priority of an HA group, if the Weight: 1-255 Yes
cost port’s health status changes to Down. HA group: 1-31. If
[no] ha-priority-cost weight no group is speci-
[ha-group group-id] fied, the weight
Note: The current release does not support configu- applies to all HA
ration of this option using the GUI. groups.
Default: not set

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Service Group Parameters

Table 36 lists the parameters you can configure in service groups.
TABLE 37 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 Mode > 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. The highest
[priority num] priority is 16.
[template template-name] Defaults:
[stats-data-disable] • State – enabled
The enable | disable options change the server and
• Priority – 1
port state within the service group only.
• Template – not set
The priority option enables you to designate some
real servers as backups (the lower priority servers) • Statistical data collection – enabled
to be used only if the higher priority servers all are
unavailable. If the priority affinity feature is enabled
within a service group, then the sessions with low-
priority backup servers will be persistent, even if
primary servers are brought back into service.
The template option binds a real port template to
the port.
The stats-data-disable option disables statistical
data collection for the member.
Note: The port template option Slow Start is not
supported if the port template is applied here.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 37 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 first data packet
[auto-switch stateless-lb-method] response time (after three-way
Config Mode > Service > SLB > Service Group handshake) from end-user traffic
requests.
Note: The fastest-response algorithm takes effect
only if the traffic rate on the servers is at least 5 con- Note: The fastest-response method is
nections per second (per server). If the traffic rate is not applicable in Direct Server Return
lower, the first server in the service group usually is (DSR) deployments.
selected. • Least-connection – Selects the server
Note: For information about the auto-switch that currently has the fewest connec-
option, see “Auto-switch to Stateless SLB Based on tions.
Traffic” on page 129. • Service-least-connection – Selects
the server port that currently has the
fewest connections.
Note: For this and the other least-con-
nection methods, if there is a tie, the
port (among those tied) that has the
lowest number of request bytes plus
response bytes is selected. If there is
still a tie, a port is randomly selected
from among the ones that are still tied.
• 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.
• Least-request – Selects the real
server port for which the AX device
is currently processing the fewest
HTTP requests. This method is
applicable to HTTP load balancing.
(cont.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Load balancing • Weighted-round-robin – Selects
method servers in rotation, based on the
(cont.) servers’ administratively assigned
weights.
If the weight value is the same on
each server, this load-balancing
method simply selects the servers in
rotation.
The Weighted-round-robin method
uses only the server weight. Server
port weight is not used. (Instead,
server port weight is used by the
Service-weighted-least-connection
method).
• Round Robin Strict – Provides a
more exact round-robin method.
The standard, default round robin
method is optimized for high perfor-
mance. Over time, this optimization
can result in a slight imbalance in
server selection. Server selection is
still basically round robin, but over
time some servers may be selected
slightly more often than others.
The following methods apply only to

stateless SLB. (For more information,
see “Stateless SLB” on page 123.)
• Stateless-src-ip-hash – Balances
server load based on a hash value
calculated using the source IP
address and source TCP or UDP
port.
• Stateless-src-dst-ip-hash – Balances
calculated using both the source and
destination IP addresses and TCP or
UDP ports.
• Stateless-dst-ip-hash – Balances
calculated using the destination IP
address and destination TCP or
UDP port.
(cont.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Load balancing • Stateless-per-pkt-round-robin – Bal-
method ances server load by sending each
(cont.) packet to a different server, in rota-
tion. This method is applicable only
for UDP DNS traffic.
• Stateless-src-ip-only-hash – Bal-
ances server load based on a hash
value calculated using the source IP
address only.
• Src-ip-hash – Calculates a hash
value based on the source IP address
and protocol port of the client’s
request.
• Src-ip-only-hash – Calculates a
hash value based on only the source
IP address of the client’s request.
• Dest-ip-hash – Calculates a hash
value based on the destination IP
address and protocol port of the cli-
ent’s request.
• Dest-ip-only-hash – Calculates a
hash value based on only the desti-
nation IP address of the client’s
request.
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.
[no] health-check monitor-name

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
backup servers and stops using any of the primary
servers.
[no] min-active-member num
[skip-pri-set]
Reset after server Sends a TCP reset (RST) to clients if server selec- Enabled or disabled
selection tion fails. Default: disabled
failure [no] reset-on-server-selection-
fail
Note: For more information about this option, see
“Sending a Reset After Server Selection Failure” on
page 755.
Priority affinity When enabled, the AX device maintains persistent Enabled or disabled
connections between clients and low-priority serv- Default: disabled
ers, even after the primary, higher-priority servers
return to service.
The Reset option resets the priority affinity feature
so that the primary servers can be used again. With-
out this option, the backup servers continue to be
used even when the primary servers come back up.
[no] priority-affinity [reset]

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Priority affinity Options allow you to associate an action with a spe- The priority of service-group members
options cific priority. Specified action will occur only if all can range from 1-16.
service-group members having that same priority Default action: Proceed
fail. Useful for preventing lower-priority secondary
servers from being overwhelmed by traffic during
failover.
priority num
[drop]
[drop-if-exceed-limit]
[proceed]
[reset]
[reset-if-exceed-limit]
Associate one of the following actions with a prior-
ity level in a service-group:
• Reset – Sends TCP reset (RST) back to client
• Drop – Drops the current client request
• Proceed – Use node(s) with the next-highest pri-
ority in the service-group (this is the default
behavior)
• Reset-if-exceed-limit – Sends a reset to the client
if one or more nodes exceed the configured con-
nection-limit or connection-rate-limit
• Drop-if-exceed-limit – Drops the request if one
or more nodes exceed the configured connection-
limit or connection-rate-limit
The actions above are mutually exclusive, meaning
that only one action can be configured for each pri-
ority level. However, the same action can be used
more than once for different priorities.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Backup server Generates a log message (and SNMP notification, if Enabled or
event logging enabled) when a backup service-group member is disabled
placed into service for either of the following rea- Default: disabled
sons:
• The connection limit on the primary servers or
member ports is exceeded.
• The primary servers or member ports go down.
Likewise, the backup-server-event-log option gen-
erates a log message when a backup service-group
member is removed from service, and a primary
server is returned to service for either of the follow-
ing reasons:
• The primary server or member port’s connection-
resume limit is reached.
• The primary server or member port comes back
up.
[no] backup-server-event-log
SNMP Trap Requirements

For SNMP backup-server notifications, the follow-
ing SLB notifications must be enabled:
• slb server-conn-limit
• slb server-conn-resume
• slb service-conn-limit
• slb service-conn-resume
Statistics Enables or disables collection of statistical data for Enabled or
collection the service group. disabled
stats-data-disable
Extended Enables collection of peak connection statistics. Enabled or disabled
statistics [no] extended-stats Default: disabled

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Traffic Enables replication of VIP traffic to external collec- Enabled or disabled
replication tors. Default: disabled
[no] traffic-replication-type
{
mirror |
mirror-da-repl |
mirror-ip-repl |
mirror-sa-da-repl |
mirror-sa-repl
}
(For more information, see “Advanced Traffic Rep-
lication” on page 599.)
Traffic Manually resets a service group configured for auto- N/A
replication switch to use stateful load balancing. Operational option, not a configuration
(See “Auto-switch to Stateless SLB Based on Traf- option
fic” on page 129.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Virtual Server Parameters

Table 38 lists the parameters you can configure on virtual servers.
TABLE 38 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
• To configure a single VIP, enter the IP address. address
• To configure a contiguous range of VIPs, enter a Default: None con-
subnet, in Classless Interdomain Routing (CIDR) figured
format.
[no] slb virtual-server name ipaddr
or
[no] slb virtual-server server-name

starting-ip
{subnet-mask | /mask-length}
Virtual server State of the virtual server. Enabled or disa- No
state [no] {disable bled
[when-all-ports-down] | Default: Virtual
enable} servers are enabled
The when-all-ports-down option automatically dis- by default. The
ables the virtual server if all its service ports are when-all-ports-
down. If OSPF redistribution of the VIP is enabled, down option is
the AX device also withdraws the route to the VIP enabled by default.
in addition to disabling the virtual server.
Config Mode > Service > Server > Virtual Server
Virtual server Configuration template of virtual server parameters. Name of a config- N/A
template [no] template virtual-server ured virtual server
template-name template
Config Mode > Service > Server > Virtual Server Default: “Default”
virtual server tem-
plate

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 38 Virtual Server Parameters (Continued)
Configurable in
Virtual Service port number and service type. Port number: N/A
service port [no] port port-num service-type 0-65535
number and Service type:
Config Mode > Service > SLB > Virtual Server -
service type
Port • Diameter
• DNS-TCP
The service type can be one of the following: • DNS-UDP
• Diameter – Load balancing for Diameter AAA • Fast-HTTP
• DNS-TCP – Domain Name Server (DNS) TCP • FTP
port for DNS caching • HTTP
• DNS-UDP – DNS port for DNS caching • HTTPS
• Fast-HTTP – Streamlined Hypertext Transfer • MMS
Protocol (HTTP) service
• RADIUS
• FTP – File Transfer Protocol
• RTSP
• HTTP – HTTP
• SIP
• HTTPS – Secure HTTP (SSL)
• SIP-TCP
• MMS – Multimedia Messaging Service
• SIPS
• RADIUS – Load balancing of RADIUS AAA
• SMTP
messages
• SSL-Proxy
• RTSP – Real Time Streaming Protocol
• TCP
• SIP – Session Initiation Protocol over UDP
• TCP-Proxy
• SIP-TCP – SIP over TCP
• TFTP
• SIPS – Secure SIP over TLS
• UDP
• SMTP – Simple Mail Transfer Protocol
• Others
• SSL-Proxy – SSL proxy service; also used for
SSL Intercept Default: None con-
figured
• TCP – Transmission Control Protocol
• TCP-Proxy – Generic TCP stack
• TFTP – Trivial File Transfer Protocol
• UDP – User Datagram Protocol
• Others – Wildcard port used for IP protocol load
balancing. (For more information, see “IPv4
Load Balancing” on page 99.)
(For parameters you can set on the service port, see
“Virtual Service Port Parameters” on page 707.)
(cont.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
Virtual Note: Fast-HTTP is optimized for very high per-
service port formance information transfer in comparison to
number and regular HTTP. Due to this optimization, fast-
service type HTTP does not support all the comprehensive
(cont.) capabilities of HTTP such as header insertion
and manipulation. It is recommended not to use
fast-HTTP for applications that require com-
plete data transfer integrity.
ARP disable Disables or re-enables ARP replies from a virtual Enabled or dis- No
server. abled
[no] arp-disable Default: Disabled;
Config Mode > Service > SLB > Virtual Server ARP replies are
enabled.
VRRP-A VRID to use for backing up the VIP. Shared partition: No
Virtual router [no] vrid {num | default} 1-31 or “default”
ID (VRID) Private partition:
“default”
Default: If
VRRP-A is
enabled, the
“default” VRID is
used.
HA group ID HA group ID to use for session backup. 1-31 No
[no] ha-group group-id Default: Not set
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.
[no] ha-dynamic server-weight

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
OSPF Explicitly include or exclude the VIP in OSPF Set or not set No
redistribution redistribution. Default: Not set
Setting this option enables you to selectively redis-
tribute individual VIPs. Without this option, the VIP
is automatically redistributed if VIP redistribution is
enabled in OSPF.
• To redistribute a VIP, set this option on the VIP,
and enter the following command at the OSPF
configuration level: redistribute vip
only-flagged
• To exclude this VIP from redistribution, set this
option on the VIP, and enter either of the follow-
ing commands at the OSPF configuration level:
redistribute vip only-not-flagged or redistrib-
ute vip
[no] redistribution-flagged
Statistics Enables or disables collection of statistical data for Enabled or No
collection the virtual server. disabled
stats-data-disable
Extended Enables collection of peak connection statistics. Enabled or No
Config Mode > Service > SLB > Virtual Server Default: disabled

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Virtual Service Port Parameters

Table 39 lists the parameters you can configure on individual service ports
on virtual servers.
TABLE 39 Virtual Service Port Parameters

Configurable in
Supported Virtual Port
Virtual Service port number and service type. Port number: N/A
service port [no] port port-num service-type 0-65534
number and Default: not set
service type
Virtual Server Port
In the CLI, this is set at the virtual server configura-
tion level. In the GUI, this is set on the Virtual
Server Port page.
For a list of valid service types (virtual port types),
see Table 38 on page 703.
Notes:
• Fast-HTTP is optimized for very high perfor-
mance information transfer in comparison to reg-
ular HTTP. Due to this optimization, fast-HTTP
does not support all the comprehensive capabili-
ties of HTTP such as header insertion and
manipulation. It is recommended not to use fast-
HTTP for applications that require complete data
transfer integrity.
• The AX device allocates processing resources to
HTTPS virtual ports when you bind them to an
SSL template. This results in increased CPU utili-
zation, regardless of whether traffic is active on
the virtual port.
Virtual Name of the virtual service. 1-31 characters No
service name [no] name string Default:
Config Mode > Service > SLB > Virtual Service _VIPaddr_
type_
portnum
Virtual State of the virtual service port. Enabled or No
service port [no] {disable | enable} disabled
state Default: Enabled
Virtual Server Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 39 Virtual Service Port Parameters (Continued)
Configurable in
Virtual port Configuration template of virtual port parameters. Name of a config- N/A
template [no] template virtual-port ured virtual port
template-name template
Config Mode > Service > SLB > Virtual Server - 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
[no] service-group group-name
Virtual Server Port
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 619.
Virtual Server Port
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 619.)
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]
Virtual Server Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
aFleX policy aFleX policy to use for custom SLB processing. Name of a config- No
[no] aflex aflex-name ured aFleX policy.
Config Mode > Service > SLB > Virtual Server - Default: None
Virtual Server Port
Connection Number of concurrent connections allowed on the 0-8000000 (8 mil- Yes, but the range
limit virtual service port. lion) is 1-1048575
By default, after the connection limit is exceeded, 0 means no limit.
new connections are silently dropped and no reset is Default: Not set.
sent to the client. You can use the reset option to When the feature
send a connection reset to the client instead. is enabled, the
[no] conn-limit number reset option is dis-
[reset] [no-logging] abled and logging
is enabled.
Virtual Server Port
Session Backs up session information on the Standby AX Enabled or No
synchroniza- device in an HA configuration. When this option is disabled
tion enabled, sessions remain up even following a Default: Disabled
(connection failover.
mirroring) [no] ha-conn-mirror
Virtual Server Port
Note: In HA deployments, HA session synchroniza-
tion is required for persistent sessions (source-IP
persistence, and so on), and is therefore automati-
cally enabled for these sessions by the AX device.
Persistent sessions are synchronized even if session
synchronization is disabled in the configuration.
Client Always uses the same outbound link for a given cli- Enabled or No
stickiness for ent’s traffic. disabled
outbound LLB [no] clientip-sticky-nat Default: Disabled
Virtual Server Port
Notes:
• The Sticky NAT option applies only to LLB. The
option does not apply to other features, such as
SLB.
• The sticky NAT option is not supported with the
ip-rr (IP round-robin) option.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
Destination Destination NAT translates the destination address Enabled or No
NAT of server replies from the AX interface address to disabled
the client’s address, and changes the source of the Disabled: Destina-
reply from the real server’s address to the VIP tion NAT is
address. enabled.
In Direct Server Return (DSR) deployments, the
AX device does not change the server reply. Server
replies go directly to clients. Disabling destination
NAT is required for Direct Server Return (DSR).
The port-translation option applies only to wildcard
VIPs. On wildcard VIPs, the port-translation option
enables the AX device to translate the destination
protocol port in a client request before sending the
request to a server. This option is useful if the real
port number on the server is different from the vir-
tual port number of the VIP. Without this option, the
AX device sends the request to the server without
changing the destination port number. This option
does not change the destination IP address of the
request.
[no] no-dest-nat
[port-translation]
Virtual Server Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 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 the “Policy-
Based SLB (PBSLB)” chapter of the AX Series Sys-
tem Configuration and Administration Guide.)
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 Mode > Service > SLB > Virtual Server - Default: Not set
Virtual Server Port
Note: This option is not applicable to the mms or
rtsp service types.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
VIP Source Enables IP NAT support for the VIP. Enabled or No
NAT Source IP NAT can be configured on a virtual port disabled
in the following ways: Default: Disabled
• ACL-Source NAT binding at the virtual port level
• VIP source NAT at the global configuration level
• aFleX policy bound to the virtual port
• Source NAT pool at the virtual port level
These methods are used in the order shown above.
For example, if IP source NAT is configured using
an ACL on the virtual port, and the VIP source NAT
is also enabled globally, then a pool assigned by the
ACL is used for traffic that is permitted by the ACL.
For traffic that is not permitted by the ACL, the
globally configured VIP source NAT can be used
instead.
[no] snat-on-vip
Virtual Server Port
Note: The current release does not support source
IP NAT on FTP or RTSP virtual ports.
Smart NAT Automatically creates NAT mappings using the AX Enabled or No
interface connected to the real server. disabled
[no] source-nat auto [precedence] Default: Disabled
The precedence option is applicable if standard
NAT pools are also used by the virtual port. In this
case, using the precedence option causes Smart
NAT to be used before the standard NAT pools are
used.
(See “Smart NAT for Virtual Ports” on page 569.)
Virtual Server Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
Software- Protects against TCP SYN floods. Enabled or No
based [no] syn-cookie [expand] disabled
protection Default: Disabled
against TCP The expand option includes extended TCP options
SYN flood in SYN cookies.
attacks Config Mode > Service > SLB > Virtual Server -
Virtual Server Port
Note: If hardware-based SYN cookies are sup-
ported on the AX model you are configuring, use
that version of the feature instead.
For more information about the SYN-cookie fea-
ture, see the “Traffic Security Features” chapter of
the AX Series System Configuration and Adminis-
tration Guide.
Use receive Sends replies to clients back through the last hop on Enabled or No
hop for which the request for the virtual port's service was disabled
responses received. Default: Disabled
[no] use-rcv-hop-for-resp
Virtual Server Port
Reset after Sends a TCP reset (RST) to clients if server selec- Enabled or No
server tion fails. disabled
selection [no] reset-on-server-selection- Default: disabled
failure fail
Virtual Server Port
Note: For more information about this option, see
“Sending a Reset After Server Selection Failure” on
page 755.
Default Forwards client traffic at Layer 3, if SLB server Enabled or No
forwarding selection fails. disabled
after server Note: This option applies only to wildcard VIPs Default: disabled.
selection (VIP address 0.0.0.0). If SLB server
failure [no] use-default-if-no-server selection fails, the
Config Mode > Service > SLB > Virtual Server - traffic is dropped.
Virtual Server Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
Default Continues checking for an available server in other Enabled or No
selection if service groups if all of the servers are down in the disabled
preferred first service group selected by SLB. Default: Enabled
server During SLB selection of the preferred server to use
selection fails 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
Virtual Server Port )

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configurable in
GSLB enable Enables a DNS port to function as a proxy for Enabled or No
(DNS proxy Global Server Load Balancing (GSLB) for this vir- disabled
ports only) tual port. Default: disabled
[no] gslb-enable
Virtual Server Port
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.
aFlow Helps avoid packet drops and retransmissions when Enabled or Yes
a real server port reaches its configured connection disabled
limit. (See “aFlow Request Queuing” on page 736.) Default: disabled
[no] aflow
Virtual Server Port
Layer 7 reset Sends a reset to the Layer 7 client and the server Enabled or Yes
upon failover. upon a failover. disabled
[no] reset-l7-on-failover Default: disabled
Virtual Server Port
Allow other Allows initial SYN packets to contain other flags. Enabled or Yes
flags in TCP- [no] allow-syn-otherflags disabled
SYN packets. Config Mode > Service > SLB > Virtual Server - Default: disabled
Virtual Server Port
Statistics Enables or disables collection of statistical data for Enabled or No
collection the virtual port. disabled
stats-data-disable
Virtual Server Port
Extended Enables collection of peak connection statistics. Enabled or No
Config Mode > Service > SLB > Virtual Server - Default: disabled
Virtual Server Port

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012
Overview
Default Server and 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.
Modifying a Default Template

You can modify a default template by creating a new one named “default”
and modifying the settings you want to change. The new template replaces
the previous one.
Note: In addition to configuring custom server, port, virtual-server, or virtual-

port templates, you can modify the default templates.
Caution: Before changing a default template, make sure the changes you plan
to make are applicable to all servers or ports that use the template.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Parameters That Can Be Configured Using Server and Port

Templates
Table 40 describes the server and port parameters you can configure using
templates.
TABLE 40 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 502.)
Connection limit Specifies the maximum number of connections allowed on
any server that uses the template. (See “Connection Limit-
ing” on page 727.)
Connection rate Limits the rate of new connections the AX is allowed to
limiting send to any server that uses the template. (See “Connection
Rate Limiting” on page 729.)
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 731.)
Load-balancing weight Biases load-balancing selection of this server. A higher
weight gives more favor to the server relative to the other
servers.
For an example of weighted SLB, see “FTP Load Balanc-
ing” on page 133. (The example configures weights directly
on the real service ports rather than using templates, but still
illustrates how the weight option works.)
Note: This option option applies only to the service-
weighted-least-connection load-balancing method. This
option does not apply to the weighted-least-connection or
weighted-round-robin load-balancing methods.
Statistics collection Enables or disables collection of statistical data for the
server.
Extended statistics Enables collection of peak connection statistics.
Spoofing cache support Enables support for a spoofing cache server. A spoofing
cache server uses the client’s IP address instead of its own
as the source address when obtaining content requested by
the client.
This option applies to the Transparent Cache Switching
(TCS) feature. (See “Transparent Cache Switching” on
page 395.)
HA priority cost Decreases the HA priority of an HA group, if the real
server’s health status changes to Down.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
TABLE 40 SLB Port and Server Template Parameters (Continued)
Real Server Dynamic server creation using DNS
(cont.) The following parameters apply to dynamic server creation using DNS. (For more
information about this feature, see “Dynamic Real Server Creation Using DNS” on
page 743.)
DNS query interval Specifies how often the AX device sends DNS queries for
the IP addresses of dynamic real servers.
Dynamic server prefix Changes the prefix added to the front of dynamically cre-
ated servers.
Minimum TTL ratio Specifies the minimum initial value for the TTL of dynamic
real servers.
Maximum dynamic Specifies the maximum number of dynamic real servers that
servers can be created for a given hostname.
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 502.)
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 525.
Connection limit Specifies the maximum number of connections allowed on
any real port that uses the template. (See “Connection Lim-
iting” on page 727.)
limiting send to any real port that uses the template. (See “Connec-
tion Rate Limiting” on page 729.)
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 77.
Member priority for Sets the initial TTL for dynamically created service-group
dynamically created members. (See “Dynamic Real Server Creation Using
servers DNS” on page 743.)
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 the “Network Address Translation”
chapter in the AX Series System Configuration and Adminis-
tration Guide. Also see “Network Address Translation for
SLB” on page 557.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Real Server Port Slow start Provides time for real ports that use the template to ramp-up
(cont.) after TCP/UDP service is enabled, by temporarily limiting
the number of new connections on the ports. (See “Slow-
Start” on page 731.)
Down grace period Specifies the number of seconds the AX device will con-
tinue to forward packets to a Down port. This option is use-
ful for taking servers down for maintenance without
immediately impacting existing sessions on the servers.
(See “Graceful Shutdown” on page 735.)
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.
SSL support Disables SSL for server-side connections. This option is
useful if a server-SSL template is bound to the virtual port
that uses this real port, and you want to disable encryption
on this real port.
DSCP Sets the differentiated services code point (DSCP) value in
the IP header of a client request before sending the request
to a server.
HA priority cost Decreases the HA priority of an HA group, if the real
server’s health status changes to Down.
Statistics collection Enables or disables collection of statistical data for the
server.
Extended statistics Enables collection of peak connection statistics.
Virtual Server Connection limit Specifies the maximum number of connections allowed on
any VIP that uses the template. (See “Connection Limiting”
on page 727.)
limiting send to any VIP that uses the template. (See “Connection
Rate Limiting” on page 729.)
ICMP/ICMPv6 rate Limits the rate at which ICMP packets can be sent to the
limiting VIP. (See the “Traffic Security Features” chapter in the
AX Series System Configuration and Administration Guide.)
Gratuitous ARPs for Enables gratuitous ARPs for all VIPs in a subnet VIP. (See
subnet VIPs “Gratuitous ARPs for Subnet VIPs” on page 735.)
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 727.)
limiting send to any virtual service port that uses the template. (See
“Connection Rate Limiting” on page 729.)
aFlow request queuing Avoids packet drops and retransmissions when a real server
port reaches its configured connection limit.
(See “aFlow Request Queuing” on page 736.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring Server and Port Templates
Virtual Server Port Reset unknown Enables sending of a TCP Reset (RST) in response to a ses-
(cont.) connections sion mismatch. (See “TCP Reset Option for Session Mis-
match” on page 738.)
Ignore TCP MSL Immediately reuses TCP sockets after session termination,
without waiting for the SLB Maximum Session Life (MSL)
time to expire.
Source-NAT MSL Sets the TCP MSL for virtual port NAT sessions. (See “Vir-
tual-port TCP Maximum Segment Life for NATted Ses-
sions” on page 573.)
DSCP Sets the Differentiated Services Code Point (DSCP) value in
client requests before forwarding them to the server.
Client port preserva- Preserves the client’s source port for the traffic destined to
tion for source NAT the virtual port. (See “Client Port Preservation” on
page 740.)
Layer 7 reset upon Sends a reset to the Layer 7 client and the server upon a
failover. failover.
Allow other flags in Allows initial SYN packets to contain other flags.
TCP-SYN packets.

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 section for the template appears.
4. Enter a name for the template (if the template is new).

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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).
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 724.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Applying a Server or Service Port Template

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 41 lists the types of bindings that are supported for server and port
templates.
TABLE 41 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 40 on page 719.
Binding a Server Template to a Real Server
USING THE GUI

2. Click Server on the menu bar.
3. Click on the server name.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
4. Select the template from the Server Template drop-down list. To create
one, click Add.
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
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. In the Port section, select the template from the Server Port Template
drop-down list. To create one, click Add.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
4. Select the template from the Virtual Server Template drop-down list. To
create one, click Add.
USING THE CLI
Enter the following command at the configuration level for the virtual
server:
[no] template virtual-server template-name
Binding a Virtual Server Port Template to a Virtual Service Port
USING THE GUI

2. Click Virtual Server on the menu bar.
3. Click on the virtual server name.
4. In the Port section, 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Connection Limiting
3. In the Server section, select the server port template from the Server
Port Template drop-down list.
4. Click OK.
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-8000000 (8 mil-
lion). By default, the connection limit is 8000000 (8 million).
• 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
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.
• Logging – By default, the AX device generates a log message when the
connection limit is exceeded.
Connection limiting can be set in real server templates, real port templates,
virtual server templates, and virtual port templates.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Connection Limiting
Note: If you change the connection limiting configuration on a virtual port or
virtual server that has active sessions, or in a virtual-port or virtual-server
template bound to the virtual server or virtual port, the current connection
counter for the virtual port or server in show command output and in the
GUI may become incorrect. To avoid this, do not change the connection
limiting configuration until the virtual server or port does not have any
active connections.
Setting a Connection Limit
To set a connection limit in a server or port template, use either of the fol-
lowing methods.
USING THE GUI

1. Select one of the following:
• Config Mode > Service > SLB > Template > Server
• Config Mode > Service > SLB > Template > Server Port
2. Click on the template name or click Add if configuring a new one.
3. Select the Connection Limit Status checkbox to display the configura-

tion fields.
4. In the Connection Limit field, enter the maximum number of concurrent

connections to allow on the server or port.
5. (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.
6. (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.
7. 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:
[resume connections] [no-logging]

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Connection Rate Limiting
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]
[no-logging]
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

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
requesting the connection. The default action is to silently drop the
excess connection requests.
• Logging – By default, the AX device generates a log message when the
connection rate limit is exceeded.
When a server or service port reaches its connection limit, the AX device
stops using the server or service port.
USING THE GUI

In the configuration section for the template:
3. Select the Connection Rate Limit checkbox to activate the configuration

fields.
4. Enter the connection rate limit in the field next to the checkbox.
5. Select the sampling interval: 100ms or 1 second.
6. Select the action to take for connections that exceed the limit: Drop or
Reset.
7. (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.
8. 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:
[per {100ms | 1sec}] [no-logging]
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Slow-Start
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:
[per {100ms | 1sec}] [reset] [no-logging]
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
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 total concurrent 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: The slow-start feature is not used for a port if the real-port template is
applied to the port as part of the member configuration in a service group.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Slow-Start
In this case, if slow-start is configured in the port template, the slow-start
settings are ignored for that service-group member.
Ramp-Up Parameters
By default, slow-start allows a maximum of 128 new connections during the

first interval (anywhere between 0 and 10 seconds). During each subsequent
10-second interval, the total number of concurrent connections allowed to
the server is doubled. Thus, during the first 20 seconds, the server is allowed
to have a total of 256 concurrent connections. After 59 seconds, slow-start
ends the ramp-up and no longer limits the number of concurrent connec-
tions. Table 41 shows the default ramp-up.
TABLE 42 Default Slow-Start Ramp-Up

Total Maximum Concurrent
Number of Seconds After Connections Allowed After
Server Restart Server Restart
0-9 128
10-19 256
20-29 512
30-39 1024
40-49 2048
50-59 4096
60+ Slow-start ends – No limit
Note: The initial ramp-up interval can be any duration from 0 up to the config-
ured interval (10 seconds by default). After the initial ramp up, each sub-
sequent ramp-up occurs at the end of the configured interval.
You can configure the following ramp-up parameters:

• Starting connection limit – The starting connection limit is the maxi-
mum number of concurrent connections to allow on the server or service
port after it first comes up. You can specify from 1-4095 concurrent con-
nections. The default is 128.
• Connection increment – The connection increment specifies the amount
by which to increase the maximum number of concurrent connections
allowed. You can use one of the following methods to specify the incre-
ment:
• Scale factor (This is the default.) – The scale factor is the number by
which to multiply the starting connection limit. For example, if the
scale factor is 2 and the starting connection limit is 128, the AX
device increases the connection limit to 256 after the first ramp-up
interval. The scale factor can be 2-10. The default is 2.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Slow-Start
• Connection addition – As an alternative to specifying a scale factor,
you can instead specify how many more concurrent connections to
allow. You can specify 1-4095 new connections.
• Ramp-up interval – The ramp-up interval specifies the number of sec-
onds between each increase of the number of concurrent connections
allowed. For example, if the ramp-up interval is 10 seconds, the number
of concurrent connections to allow is increased every 10 seconds. The
ramp-up interval can be 1-60 seconds. The default is 10 seconds.
• Ending connection limit – The ending connection limit is the maximum
number of concurrent connections to allow during the final ramp-up
interval. After the final ramp-up interval, the slow start is over and does
not limit further connections to the server. You can specify from
1-65535 connections. The default is 4096.
Note: For the connection increment, you can specify a scale factor or a connec-
tion addition. The ending connection limit must be higher than the starting
connection limit.
If a normal runtime connection limit is also configured on the server or
port (for example, by “Connection Limiting” on page 727), and the nor-
mal connection limit is smaller than the slow-start ending connection
limit, the AX device limits slow-start connections to the maximum
allowed by the normal connection limit.
Behavior When Slow Start Is Also Configured on the Real Server

Itself
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 tem-
plates. It is recommended to configure slow start only in a server template
or port template, not on the real server.
If you do configure slow-start both on the real server itself and in a real
server template or real port template, the actual slow-start behavior can dif-
fer from the behavior configured in the template.
• If slow start is configured on the real server and in a real server tem-
plate, the slow-start settings on the real server are used and the settings
in the template are ignored. It is recommended to configure slow start
only in a real server template or real port template.
• If slow start is configured on the real server and in a real port template,
the lower number of connections allowed by either of the configurations
at a given interval is used.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Slow-Start
USING THE GUI
In the configuration section for the real server template or real port tem-
plate:
3. Select the Slow Start checkbox to activate the configuration fields.
4. Enter the starting connection limit in the field to the right of “From”.
5. Enter the connection increment method: Multiplying or Adding.
6. Enter the connection increment in the field next to the increment method
you selected.
7. Enter the ramp-up interval in the Every field.
8. Enter the ending connection limit in the Till field.
9. 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]
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-0026 - Ver. 2.7.0 11/1/2012
Graceful Shutdown
Graceful Shutdown
You can configure a grace period for Down servers. The AX device will
continue to forward packets to Down ports for the duration of the grace
period.
This option is useful for taking servers down for maintenance without
immediately impacting existing sessions on the servers. The grace period
can be 1-86400 seconds.
Notes:
• The service group must contain 2 or more servers for this feature to
work.
• This feature supports stateless and stateful load balancing. However, the
feature is not supported for stateful hash load-balancing methods, such
as source-IP-based or destination-IP-based hashing.
USING THE GUI
The current release does not support configuration of this option using the
GUI.
USING THE CLI
To configure the grace period, use the following command at the configura-
tion level for the real port template:
[no] down-grace-period seconds
Gratuitous ARPs for Subnet VIPs

Virtual server templates have an option to enable gratuitous ARPs for all
VIPs in a subnet VIP. (A subnet VIP is a range of VIPs created from a range
of IP addresses within a subnet.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
aFlow Request Queuing
By default, the AX device sends gratuitous ARPs for only the first IP
address in a subnet VIP. You can enable the AX device to send gratuitous
ARPs for all the IP addresses within a subnet VIP.
Note: This option applies only to VIPs that are created using a range of subnet
IP addresses. The option has no effect on VIPs created with a single IP
address.
USING THE GUI

2. On the menu bar, select Template > Virtual Server.
4. Select the Subnet Gratuitous ARP checkbox.
5. Click OK.
USING THE CLI
To enable gratuitous ARPs for all VIPs in subnet VIPs, use the following
command at the configuration level for the virtual server template used to
configure the VIPs:
subnet-gratuitous-arp
CLI Example
The following commands modify the default virtual server template to

enable gratuitous ARPs for subnet VIPs. The change applies to all subnet
VIPs that use the default template for virtual server configuration.
AX(config)#slb template virtual-server default
AX(config-vserver)#subnet-gratuitous-arp

aFlow helps avoid packet drops and retransmissions when a real server port
reaches its configured connection limit.
When aFlow is enabled, the AX device queues HTTP/HTTPS packets from

clients when a server port reaches a configured connection limit, instead of
dropping them. The AX device then monitors the port, and begins forward-
ing the queued packets when connections become available again. To pre-

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
vent flooding of the port, the AX device forwards the queued packets at a
steady rate.
aFlow applies to HTTP and HTTPS virtual ports.
Note: Earlier releases provide this capability with the SmartFlow option in con-
nection-reuse templates. The aFlow feature in AX Release 2.6 does not
require use of a connection-reuse template. You can enable aFlow in a vir-
tual port template instead.
For backwards compatibility, you still can enable aFlow using a connec-
tion-reuse template. However, only one implementation, either in a virtual
server template or in a connection-reuse template, is supported. If you
change from one implementation to the other, a reload or reboot is
required to place the change into effect.
aFlow Control Operation

aFlow control is triggered when either of the following occurs:
• If connection limit is configured on the real server or real port – The
backend real server or real port reaches its configured connection limit.
• If connection limit is not configured on the real server or real port – The
response time of the backend real server or real port increases dramati-
cally. The response time is the time between when the AX device for-
wards a request to the server, when the AX device receives the first
reply packet from the server.
When aFlow control is triggered, the AX device queues request packets

instead of forwarding them to the server. After the response time returns to
normal, the AX device sends the queued packets to the server.
Note: In the current release, it is recommended to use the first method for trig-
gering aFlow, by configuring connection limits on the real servers or real
ports. The second method of triggering aFlow is still being refined and is
considered to be in Beta status.
Note: If you change the aFlow setting for a virtual port, or the connection limit
or connection rate limit of a real server or port used by the virtual port,
you must reload the AX device to place the change into effect. Otherwise,
the changed setting might not work correctly.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TCP Reset Option for Session Mismatch
USING THE GUI

3. Select the aFlow checkbox and click OK.
4. If the template is not already bound to the virtual port, select the tem-
plate from the Virtual Server Port Template drop-down list on the con-
figuration page for the virtual port. Click OK when finished.
USING THE CLI

1. Enable aFlow control, using the following command at the configura-
tion level for a virtual-port template:
aflow
2. Bind the virtual-port template to the HTTP or HTTPS virtual port.
CLI Example
The following commands enable aFlow control for an HTTP virtual port:
AX(config)#slb template virtual-port afc
AX(config-vport)#aflow
AX(config-slb vserver-vport)#template virtual-port afc

Virtual port templates have an option that enables sending of a TCP Reset
(RST) in response to a session mismatch. A session mismatch occurs when
the AX device receives a TCP packet for a TCP session that is not in the
active session table on the AX device.
This option is useful in cases where a session ages out or is deleted on the
AX device, but the client does not receive a RST or FIN for the session. In
this case, without a RST, the session could remain open on the client until
the session ages out. When this option is enabled, TCP RSTs are sent in the
cases listed in Table 43.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
TABLE 43 Processing When Session Is To Be Deleted

Session Termination Packet Type Sent by Client or
Method Server After Session Termination AX Response
Session is terminated by Any packet type other than SYN Maintain connection as long as there is
FINs from client and traffic. When there is no traffic, remove
server the connection one second later.
Session ages out Any packet type other than SYN Move session from delete queue back into
active session table.
The option is disabled by default, which means the AX device does not send
a RST in response to a session mismatch. You can enable the option in indi-
vidual virtual port templates.
Note: This option does not apply to sessions that are in the delete queue. If the
AX device receives a packet for a session that has been moved to the
delete queue, the AX device does not send a TCP RST. Instead, the AX
device reactivates the session and allows it to age out normally.
USING THE GUI

3. Select the Reset Unknown Connection option.
USING THE CLI

To enable sending of TCP RSTs in response to a session mismatch, use the
following command at the configuration level for a virtual port template:
[no] reset-unknown-conn

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Client Port Preservation

Virtual-port templates have an option that attempts to preserve the client’s
source port for the traffic destined to the virtual port.
This option is disabled by default.
Notes
• Port preservation is not always guaranteed and is performed on a best-
effort basis.
• Port preservation does not work for FTP active mode sessions.
• Port preservation works only if source NAT is enabled for the virtual
port.
• For high availability, it is recommended to use VRRP-A, instead of the
older implementation (HA). If you do need to use HA instead of
VRRP-A, it is recommended to use ha-use-all-ports option when config-
uring the IP address pool. This option increases the likelihood that the
AX device can acquire the same source port as the client for this feature.
(See the CLI example below.)
USING THE GUI
On the configuration page for the virtual-port template, select the SNAT
Port Preservation checkbox.
USING THE CLI

At the configuration level for the virtual-port template, use the following
command:
[no] snat-port-preserve
CLI Example
The following command configures a NAT pool:
AX(config)#ip nat pool mypool 30.30.30.40 30.30.30.42 netmask 255.255.255.0
ha-group 1 ha-use-all-ports
The following commands configure the virtual-port template:

AX(config)#slb template virtual-port vport
AX(config-vport)#snat-port-preserve

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands configure the virtual port:
AX(config-vport)#slb virtual-server vip1 192.168.25.25
AX(config-slb vserver-vport)#source-nat pool mypool
AX(config-slb vserver-vport)#ha-group 1
AX(config-slb vserver-vport)#service-group sg1-http
AX(config-slb vserver-vport)#template virtual-port vport

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Dynamic Real Server Creation Using DNS
You can use DNS to simplify real server creation, by specifying a DNS
hostname instead of an IP address. In this case, the AX device periodically
sends a DNS query for the hostname’s IP address, and dynamically creates a
real server with the IP address returned by DNS. The AX device also creates
a service-group member for the server, in each service group that contains
the server.
To create and maintain dynamic real servers, the AX device sends a DNS
query for each hostname real server, at a configurable interval.
• If the DNS server replies with an Address (A) record for a hostname real
server, the AX device creates the server or, if the server is already cre-
ated, the AX device refreshes its TTL. The AX device also creates ser-
vice-group members for the server and its ports.
• If the DNS server replies with a CNAME record, the AX device also
sends a DNS query for the CNAME.
The AX device supports multiple servers with the same hostname. For
example, if the DNS server replies with a different IP address for a host-
name real server that has already been created, the AX device creates a sec-
ond real server with the same hostname and the new IP address.
If the IP address returned by the DNS server matches the IP address of a

statically configured real server, the server is not created.
Service groups can contain both static and hostname servers.
Dynamic Server Aging

Dynamically created real servers do not persist indefinitely. Instead, they
age out based on the TTL values returned by the DNS server.
The AX device sets a server’s initial TTL when the server is created. The
initial TTL value is the greater of the following:
• TTL value in the DNS reply
• DNS query interval multiplied by the min-ttl-ratio (described in “Tem-

plate Options for Dynamically Created Real Servers” on page 744)
The server’s TTL is decremented by 60 every minute. The TTL is refreshed

each time the DNS server replies with the address.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Template Options for Dynamically Created Real Servers
If the TTL reaches 0, the dynamically created server is removed. If the DNS
server replies with the IP address after this, the server is dynamically cre-
ated again.
Note: When a dynamically created real server ages out, only that instance of the
server (its port and service group member) is removed. Other instances
(other IP addresses) for the same server (hostname) are not removed,
unless they also age out. The real server configuration that you entered,
used by the AX device to dynamically create servers, is not removed.
Template Options for Dynamically Created Real

Servers
The options that can be configured for static servers and ports also apply to
dynamic servers and ports.
In addition, server and server port templates have some new options, specif-
ically for dynamic real servers.
Note: These template options take effect when you apply a template to a
dynamic server configuration. After this, any dynamic real servers that
are created using the dynamic server configuration use the template val-
ues that were set when the template was applied to the dynamic server
configuration, even if the values are later changed in the template.
Server template options for hostname real servers:

• dynamic-server-prefix – Specifies a short string to add to the front of the
name for each dynamically created real server. Dynamically created
servers are named using the following format:
prefix-ipaddr-hostname
• The prefix is the string added by the AX device. You can specify a
string of 1-3 characters. The default is “DRS”, for Dynamic Real
Servers.
• The ipaddr is the IP address returned in the DNS reply.
• The hostname is the hostname you specify when you create the
The maximum total length of a dynamic server name is 63 bytes. If the
name becomes longer than 63 characters, the AX device truncates the
name to 63 bytes.
• dns-query-interval – Specifies the interval at which the AX device sends
DNS queries for the IP addresses of the dynamic real servers. You can
specify 1-1440 minutes (one day). The default is 10 minutes.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Template Options for Dynamically Created Real Servers
• max-dynamic-server – Specifies the maximum number of real servers
that can be dynamically created for a given hostname. You can specify
1-1023. The default is 255. After the maximum number of servers is cre-
ated, the AX device deletes the oldest servers, as determined by the time
it was created, to make room for new ones.
• min-ttl-ratio – Specifies the minimum initial value for the TTL of
dynamic real servers. This option prevents dynamic real servers from
aging out too quickly due to a small TTL value from the DNS server.
To calculate the minimum TTL value for a dynamic real server, the AX
device multiplies the dns-query-interval by the min-ttl-ratio. For exam-
ple, if the min-ttl-ratio is 2 and the dns-query-interval is 10 minutes (600
seconds), then the minimum TTL for dynamic real servers is 1200.
The min-ttl-ratio can be 1-15. The default is 2.
Server port template options for dynamic service-group members:

• dynamic-member-priority and decrement-delta – Sets the initial priority
of dynamic service-group members, and specifies how much to decre-
ment from the priority after each DNS query.
Within a service group, the priorities of the members determine which
of those members can be used to service client requests. Normally, only
the highest priority members can be used. Decrementing the priorities of
dynamic members provides a way to ensure that the service group uses
newer dynamically created members instead of older ones.
The initial priority can be 1-16, and the default is 16. The delta can be
0-8, and the default is 0.
The priority value decrements only when the IP address is not refreshed
after a DNS query. For example, assume a DNS query returns IP address
1.1.1.1, and the AX device creates a dynamic server with priority 16.
However, the latest DNS query returns IP address 2.2.2.2 only. In this
case, the priority of 1.1.1.1 is decremented by the delta value. If a later
DNS query returns 1.1.1.1 again, the priority of server 1.1.1.1 is reset to
16.
If you leave the delta set to its default (0), service-group member priori-
ties are not decremented.
Note: Settings that also apply to static servers and ports, such as connection and
rate limits, apply individually to each dynamically created server or port.
For example, the connection-rate limit configured in a server template
applies individually to each dynamically created server for a given host-
name. The limit is not applied collectively to all dynamically created serv-
ers for the hostname.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring Dynamic Real Server Creation

You can configure dynamic real servers using the GUI or CLI.
USING THE GUI

3. Click Add.
4. Enter a name for the dynamic real server in the Name field.
5. In the IP Address/Host, enter the hostname known to DNS.
6. Configure additional options for the real server and add ports, as appli-
cable to your deployment.
USING THE CLI

To configure a dynamic real server, use the following command at the
slb server server-name hostname
This command does not in itself create functioning dynamic servers.

Instead, the command enables the AX device to create dynamic servers for
the hostname, based on DNS replies.
To configure server options for dynamic real servers, use the following
commands at the configuration level for a server template:
dns-query-interval minutes
This command specifies how often the AX device sends DNS queries for
the IP addresses of dynamic real servers. You can specify 1-1440 minutes
(one day). The default is 10 minutes.
dynamic-server-prefix string
Changes the prefix added to the front of dynamically created servers. You
can specify a string of 1-3 characters. The default is “DRS”, for Dynamic
Real Servers.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
max-dynamic-server num
This command specifies the maximum number of dynamic real servers that
can be created for a given hostname. You can specify 1-1023. The default is
255.
min-ttl-ratio num
This command specifies the minimum initial value for the TTL of dynamic
real servers. The AX device multiplies this value by the DNS query interval
to calculate the minimum TTL value to assign to the dynamically created
server. The min-ttl-ratio can be 1-15. The default is 2.
To configure server port options for dynamic real servers, use the following
command at the configuration level for a server port template:
dynamic-member-priority num decrement delta
The num option sets the initial TTL for dynamically created service-group
members, and can be 1-16. The delta option specifies how much to decre-
ment the TTL if the IP address is not included in the DNS reply, and can be
0-7. When configuring the service group, add the port template to the mem-
ber. The default priority value is 16 and the default delta is 0.
To display information about dynamically created real servers, use the fol-
lowing commands:
• show slb server server-name detail
• show slb service-group
CLI Example
The following commands configure hostname server parameters in a server
port template and a server template:
AX(config)#slb template port temp-port
AX(config-rport)#dynamic-member-priority 12
AX(config)#slb template server temp-server
AX(config-rserver)#dns-query-interval 5
AX(config-rserver)#min-ttl-ratio 3
AX(config-rserver)#max-dynamic-server 16

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands configure a hostname server, add a port to it, and
bind the server template to it:
AX(config)#slb server s-test1 s1.test.com
AX(config-real server)#template server temp-server
The following commands configure a static real server:

AX(config)#slb server s-test2 10.4.2.1
The following commands configure a service group and add the hostname
server and static server to it. The port template is bound to the member for
the hostname server and port.
AX(config)#slb service-group sg-test tcp
AX(config-slb svc group)#member s-test1:80 template temp-port
AX(config-slb svc group)#member s-test2:80
The following commands adds the DNS server to use for resolving the real
server hostname into server IP addresses:
AX(config)#ip dns primary 10.10.10.10
The following command displays detailed information for the hostname

server. The configuration details are shown first, followed by details for the
dynamically created servers.
AX#show slb server s-test1 detail
Server name: s-test1
Hostname: s1.test.com
Last DNS reply: Tue Nov 17 03:41:59 2009
State: Up
Server template: temp-server
DNS query interval: 5
Minimum TTL ratio: 3
Maximum dynamic server: 16
Health check: none
Current request: 0
Total connection: 1919

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Total request: 1919
Total request success: 1877
Total forward bytes: 546650
Total forward packets: 5715
Total reverse bytes: 919730
Total reverse packets: 5631
Peak connection: 24411
Dynamic server name: DRS-10.4.2.5-s1.test.com
Last DNS reply: Tue Nov 17 03:41:59 2009
TTL: 4500
State: Up
Server template: test
DNS query interval: 5
Minimum TTL ratio: 15
Maximum dynamic server: 1023
Health check: none
Current request: 0
Total connection: 1919
Total request: 1919
Total request success: 1877
Total forward bytes: 546650
Total forward packets: 5715
Total reverse bytes: 919730
Total reverse packets: 5631
Peak connection: 2811
The following command displays service-group information. A separate

row of information appears for each dynamically created member.
AX#show slb service-group
Total Number of Service Groups configured: 40
Current = Current Connections, Total = Total Connections
Fwd-p = Forward packets, Rev-p = Reverse packets
Peak-c = Peak connections
Service Group Name
Service Current Total Fwd-p Rev-p Peak-c
------------------------------------------------------------------------------
*sg-test State: All Up
DRS-10.4.2.6-s2.test.com:80 0 0 0 0 0
DRS-10.4.2.5-s1.test.com:80 36 1919 5714 5631 55
s-test2:80 0 53 265 212 311

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following command displays detailed statistics for the dynamically cre-
ated service-group members:
AX#show slb service-group sg-test
Service group name: sg-test State: All Up
Service selection fail drop: 0
Service selection fail reset: 0
Service peak connection: 0
Service: DRS-10.4.2.6-s2.test.com:80 UP
Forward packets: 0 Reverse packets: 0
Forward bytes: 0 Reverse bytes: 0
Current connections: 0 Persistent connections: 0
Current requests: 0 Total requests: 0
Total connections: 0 Response time: 0.00 msec
Total requests succ: 0
Peak conn: 0
Service: DRS-10.4.2.5-s1.test.com:80 UP
Peak conn: 0
Service: s-test1:80 UP
Peak conn: 0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following command displays configuration information for the service
group. In this example, the service group has dynamic members and a static
member.
AX#show slb service-group sg-test config
Service group name: sg-test
Type: tcp Distribution: Round Robin
Health Check: None
Member Count:4
Member4: DRS-10.4.2.6-s2.test.com:80 Priority: 1
Member3: DRS-10.4.2.5-s1.test.com:80 Priority: 16
Member1: DRS-10.4.2.5-s-test2:80 Priority: 1
Member2: s-test1:80 Priority: 1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
VIP Creation Based on Subnet
The AX device provides a simple method to configure a range of VIPs,

based on IP subnet. Using this method, you can create a set of virtual serv-
ers that have contiguous IP addresses, simply by specifying the beginning
and ending IP addresses in the range.
The IP addresses in the specified range can not belong to an IP interface,

real server, or other virtual server configured on the AX device.
Notes
• The largest supported subnet length is /16.
• Statistics are aggregated for all VIPs in the subnet virtual server.
• In the GUI, only the first VIP in the range is visible.
• The current release supports this feature only for DNS ports on the
default DNS port number (TCP port 53 or UDP port 53).
USING THE GUI

2. On the menu bar, select Virtual Server, if not already selected.
3. Click Add.
4. Enter a name for the VIP range in the name field.
5. In the IP Address or CIDR Subnet field, enter the subnet address and
network mask, in the following format:
ipaddr/mask-length
Do not use a space before or after the forward slash.
The ipaddr is the starting host address in the range and must be a valid
host address. (For example, entering 192.168.1.0/24 is not valid.)
6. Configure additional VIP options as required for your deployment.
7. When finished, click OK at the bottom of the VIP creation page. The
VIP appears in the VIP table.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE CLI

To configure a set of virtual servers based on subnet, use the following com-
[no] slb virtual-server server-name starting-ip

{subnet-mask | /mask-length}
The starting-ip option specifies the beginning IP address in the range. The
subnet-mask | /mask-length option specifies the size of the range.
Note: If you do not specify a network mask, the virtual server is a standard VIP
that has the IP address you specify as the starting-ip address.
CLI Example
The following command configures a set of VIPs for IP addresses 1.1.1.5-
1.1.1.255:
AX(config)#slb virtual-server vs1 1.1.1.5 /24

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Sending a Reset After Server Selection Failure
The AX device provides an option to send a TCP reset (RST) to clients if

server selection fails. Server selection failure can occur as the result of any
of the following conditions:
• Server or port connection limit is reached
• Server or port connection rate limit is reached
• Client in a PBSLB black/white list reaches its connection limit
• The def-selection-if-pref-failed option is disabled and SLB is unable to

select a server for any reason
• All servers are down
The reset-on-server-selection-fail option can be enabled at either of the fol-

lowing levels:
• Service group
• Virtual port
Enabling the reset-on-server-selection-fail option at the service-group level

allows selective use of the option based on service group. Figure 168 on
page 756 shows an example of a Policy-Based SLB (PBSLB) solution that
uses the reset-on-server-selection-fail option.
Note: The TCP template reset-rev option also can be used to send a RST to cli-
ents. In AX releases prior to 2.2.2, the reset-rev option would send a RST
in response to a server selection failure. In AX Release 2.2.2 and later, the
new reset-on-server-selection-fail option must be used instead.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
FIGURE 168 PBSLB Used With reset-on-server-selection-fail Option

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
This deployment categorizes clients as follows:

• White-list clients
• Grey-list clients
• Black-list clients
In this solution, if a white-list client exceeds the connection limit specified

in the black/white list, the AX device sends a RST to the client. However, if
a grey-list or black-list client exceeds its connection limit, the AX device
drops the connection, instead of sending a RST.
To implement this solution, a separate service group is configured for each

client category. In the black/white list, each client is assigned to one of the
service groups, according to the client’s category. For example, client
192.168.1.1 is a white-list client, and is therefore assigned to the white-list
service group.
To configure the AX device to send a RST to white-list clients upon server

selection failure, but not to grey-list or black-list clients, the reset-on-server-
selection-fail option is used in the white-list service group only. The default
PBSLB action, drop, is used for the other service groups.
The virtual port to which clients will send mail traffic is bound to all three
service groups. In addition, the def-selection-if-pref-failed option is dis-
abled. This option must be disabled so that the AX device does not attempt
to use other configuration areas of the system to select a server, if SLB is
unable to select a server.
A policy template is used to identify the black/white list and the service
group assignments, and is bound to the virtual port.
Note: This example uses a separate server for each client category. However,
traffic for all clients could be sent to the same server. The essential parts
of this solution are use of a separate service group for each client cate-
gory, enabling of the reset-on-server-selection-fail option in the white-list
service group, and disabling of the def-selection-if-pref-failed option on
the virtual port.
USING THE CLI
The reset-on-server-selection-fail option is disabled by default.
To enable the option in a service group, use the following command at the
configuration level for the group:
[no] reset-on-server-selection-fail

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To enable the option on a virtual port, use the following command at the
configuration level for the port:
[no] reset-on-server-selection-fail
CLI Example
The commands below implement the solution shown in Figure 168 on
page 756.

AX(config)#slb server ms1 10.10.10.11
AX(config-real server)#port 25

AX(config)#slb service-group white-list
AX(config-slb service group)#member ms1:25
AX(config-slb service group)#reset-on-server-selection-fail
AX(config)#slb service-group grey-list
AX(config)#slb service-group black-list
The following commands configure the policy template:

AX(config)#slb template policy pbslb1
AX(config-policy)#bw-list name bw-list-1
AX(config-policy)#bw-list id 1 service-group white-list
AX(config-policy)#bw-list id 2 service-group grey-list
AX(config-policy)#bw-list id 3 service-group black-list

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
The following commands import black/white list “bw-list-1.txt” onto the

AX device:
AX(config)#bw-list bw-list-1.txt tftp://myhost/TFTP-Root/AX_bwlists/bw-list-1.txt
AX(config)#show bw-list
Name Url Size(Byte) Date
------------------------------------------------------------------------------
bw-list-1.txt tftp://myhost/TFTP-Root/AX_ N/A N/A
bwlists/bw-list-1.txt
Total: 1

AX(config)#slb virtual-server mail-vip 10.10.10.10
AX(config-slb virtual-server)#port 25 tcp
AX(config-slb virtual server-slb virtua...)#service-group white-list
AX(config-slb virtual server-slb virtua...)#service-group grey-list
AX(config-slb virtual server-slb virtua...)#service-group black-list
AX(config-slb virtual server-slb virtua...)#template policy pbslb1
AX(config-slb virtual server-slb virtua...)#no def-selection-if-pref-failed

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Servers
Alternate Servers and Ports for Individual Backup
You can assign one or more backup servers as alternates for a given primary
server. If that specific primary server goes down, one of its alternate servers
takes over. Likewise, you also can assign alternates for backing up individ-
ual ports.
These features are described in the following sections:

• “Alternate Servers” on page 761
• “Alternate Ports” on page 766
Alternate Servers
You can assign up to 16 alternate servers to a primary server. Only 1 alter-
nate server for a given primary server can be active at a time.
Note: This feature places an alternate server into service only if the primary
server goes down. Other features such as connection limiting or connec-
tion-rate limiting can not cause an alternate server to be used.
Sequence Numbering of Alternate Servers

Each alternate server must have a sequence number, 1-16. You specify the
sequence number of an alternate server when you assign it to its primary
server.
For example, the following set of servers consists of one primary server and
3 alternate servers:
• rs1 – Primary server
• rs1-a1 – Alternate server with sequence number 1
The alternate servers are used according to their sequence numbers, begin-
ning with the lowest sequence number. For example, if all servers are up,
then rs1 goes down, rs1-a1 takes over. If rs1-a1 also goes down, rs1-a2 takes
over, and so on.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Servers
Note: The sequence numbering of alternate servers is different from server pri-
ority. You do not need to change the priority values of the primary server
or its alternate servers.
Re-Activation of Down Servers

When a down server comes back up, the server is placed back into service.
New sessions can be sent to the server. The alternate server is gracefully
removed from service. Existing sessions on the alternate server are allowed
to continue until they are terminated or they time out.
Configuration
To configure alternate servers for backup:

1. Add each of the alternate servers to the configuration.
2. Add the primary servers to the configuration. During configuration of

each of the primary servers, specify the alternate servers to use as the
primary server’s backups.
3. Configure a service group. Add only the primary servers to the group.
Do not add the alternate servers to the group.
4. Configure the virtual server. Bind the service group to a virtual port on
the server.
The configuration options for the alternate servers are the same as those for
primary servers. Likewise, the configuration options for the service group
and virtual server are the same as those for configurations that do not use
alternate servers.
The only server that is unique to use of alternate servers is specification of

those servers in the configuration of the primary servers.
USING THE GUI
On the server configuration page for a primary server, next to Alternate

Server:
1. Select an alternate server from the Name drop-down list.
2. Enter the sequence number in the Number field.
3. Click Add.
4. Repeat for each alternate server to be used by the primary server as a

backup.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Servers
USING THE CLI
To assign an alternate server as a dedicated backup for a primary server, use

the following command at the configuration level for the primary server:
[no] alternate sequence-num server-name
The sequence-num specifies the priority of the alternate server as a backup.

You can specify 1-16. (See “Sequence Numbering of Alternate Servers” on
page 761.)
The server-name specifies the name of the alternate server.
To list the alternate servers that are currently in use, use the following com-
mand:
show slb virtual-server bind
CLI Example
The following commands configure some real servers to be used as alter-
nate servers for backup:
AX(config)#slb server rs1-a1 10.10.10.51

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Servers
The following commands configure 2 primary servers, and assign alternate

servers to each of them:
AX(config-real server)#alternate 1 rs1-a1
The following commands configure a service group. Only the primary serv-
ers are added to the group. The alternate servers are not added to the group.
AX(config)#slb service-group http1 tcp
The following commands configure a virtual server that uses the service
group configured above:
AX(config)#slb virtual-server http-with-alternates 192.168.10.10
AX(config-slb vserver-vport)#service-group http1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Servers
The following command indicates whether alternate servers are in use:
AX(config)#show slb virtual-server bind
Total Number of Virtual Services configured: 1
---------------------------------------------------------------------------------
*Virtual Server : http-with-alternates(A) 192.168.10.10 Functional Up
+port 80 http ====>http1 State :Functional Up

+rs1:80 10.10.10.10 State : Up
Alternate: rs1-a1, rs1-a2, rs1-a3
+rs2:80 10.10.10.20 State : Down
Alternate: rs2-a1*, rs2-a2, rs2-a3
The primary servers are listed under the virtual port. Under each primary
server, that server’s alternate servers are listed.
If an asterisk is shown at the end of an alternate server name, the primary

server is down and the alternate server is active instead. In the example
above, rs2 is down, so alternate rs2-a1 is being used instead.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Ports
Alternate Ports
For more granularity, you can specify alternates for individual ports. In this
case, if a primary port that has an alternate goes down, the AX device uses
the alternate for that port, but continues to use the primary server for other
ports, if those other ports are still up. Figure 169 shows an example.
FIGURE 169 Alternate server ports
This deployment uses two primary servers, “linux-01” and “linux-02”. An

alternate server is configured for each of the primary servers. The server
“windows-01” is an alternate server for “linux-01”. Likewise, “win-
dows-02” is an alternate server for “linux-02”.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Ports
Each primary server, and each of its alternate servers, has the following
ports:
• TCP port 80 (or 8080)
• TCP port 443
• UDP port 53
As shown in this example, the port numbers on the primary and alternate
servers are not required to be the same. TCP port 8080 on the alternate serv-
ers provides the backup for port 80 on the primary servers.
Although port 80 has its own alternate port, the deployment in this example
does not use alternate ports for 443 or 53. If port 443 or 53 on a primary
server goes down, the AX device starts using the alternate server, for all the
primary server’s ports (443 and 53).
However, if only port 80 goes down, the AX device begins using port 8080
on the alternate server, but continues using the primary server for ports 443
and 53. This is because port 80 has its own alternate port.
Note: For simplicity, this example shows only a single alternate server for each
primary server. In fact, a primary server can have up to 16 alternate serv-
ers. In either case, for a given primary server, only one alternate server
can be in use at a time. Likewise, a port can have up to 16 alternate ports
but only one of those ports can be in use at any given time. Priority ranges
from highest (1) to lowest (16).
Note: For more information about how the alternate-server feature works, see
“Alternate Servers” on page 761.
Configuration
To configure alternate ports:

1. Configure an alternate server.
2. Configure the primary server.

a. Add the alternate server to the primary server.
b. Add the protocol ports. On each port for which you want to provide
an individual backup, add the alternate server and port.
Note: Make sure to use the same sequence number for the alternate server and
the alternate port. This is required.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Ports
3. Configure the service group.
Within the service group configuration, there is no specific configura-
tion required for the alternate servers and ports. Add only the primary
server and ports as members of the group. Do not add the alternate serv-
ers or ports to the service group. No service group is required for the
alternate servers and ports.
4. Configure the virtual server. Make sure to bind the primary server’s ser-
vice group to the virtual port. Within the virtual server configuration,
there is no specific configuration required for the alternate servers and
ports.
Notes
• The sequence number of an alternate port must be the same as the
sequence number of the alternate server.
• A given alternate server can be used by only one primary server within
the same service group.
USING THE GUI

The current release does not support configuration of alternate ports using
the GUI.
USING THE CLI
To configure alternate ports:

1. Configure an alternate server using the following command at the con-
figuration level for the real server:
[no] alternate sequence-num server-name
The sequence-num can be 1-16.
2. Access the configuration level for the primary server port:

[no] port port-num {tcp | udp}
3. Use the following command to configure an alternate port for the pri-
mary port:
[no] alternate sequence-num server-name port
portnum
The sequence-num and server-name must be the same as the values
specified for the alternate server in step 1.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Ports
To display VIP information that indicates status of alternate servers and
ports, use the following command:
show slb virtual-server bind
CLI Example
The commands in this example configure the deployment shown in
To begin, the following commands configure the alternate servers:
AX(config)#slb server windows-01 172.16.119.176
AX(config-real server-node port)#slb server windows-02 172.16.119.171
The following commands configure the primary servers:

AX(config)#slb server linux-01 172.16.119.216
AX(config-real server)#alternate 1 windows-01
AX(config-real server-node port)#alternate 1 windows-01 port 8080
AX(config-real server-node port)#slb server linux-02 172.16.119.217
AX(config-real server)#alternate 2 windows-02
AX(config-real server-node port)#alternate 2 windows-02 port 8080
Note: The fact that these servers are not used as alternates for other servers
makes these “primary servers”.
The following commands configure the service groups. A separate service

group is configured for each service:
AX(config-real server-node port)#slb service-group linux-http tcp
AX(config-slb svc group)#member linux-01:80
AX(config-slb svc group)#slb service-group linux-ssl tcp

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Alternate Ports
AX(config-slb svc group)#slb service-group linux-dns udp

AX(config-slb svc group)#slb virtual-server vip1 192.168.19.120
AX(config-slb vserver-vport)#service-group linux-http
AX(config-slb vserver-vport)#port 443 https
AX(config-slb vserver-vport)#service-group linux-ssl
AX(config-slb vserver-vport)#port 53 dns-udp
AX(config-slb vserver-vport)#service-group linux-dns
The following command displays binding information for the virtual server.
This information includes the status of the primary and alternate servers and
ports, for the service-group members bound to the virtual port.
AX(config)#show slb virtual-server bind
Total Number of Virtual Services configured: 3
------------------------------------------------------------------------------
*Virtual Server : vip1(A) 192.168.19.120 Functionally Up
+port 80 http ====>linux-http State : Functionally Up

+linux-01:80 172.16.119.216 State : Down
+linux-02:80 172.16.119.217 State : Up
+port 443 https ====>linux-ssl State :Up
+linux-01:443 172.16.119.216 State : Up
Alternate: windows-01
+linux-02:443 172.16.119.217 State : Up
+port 53 dns-udp ====>linux-dns State :Up
+linux-01:53 172.16.119.216 State : Up
+linux-02:53 172.16.119.217 State : Up
The output indicates that port 80 on “linux-80” is Down. Therefore, alter-

nate port 8080 on server “windows-01” is used instead.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Priority Affinity
Priority affinity is a service-group option that allows the AX device to con-

tinue using backup servers (servers with lower priority) even when the pri-
mary (high priority) servers come back up.
Overview
Default Behavior (Priority Affinity Disabled)
By default, the priority affinity feature is disabled when a service group is
created. With priority affinity disabled, the AX device’s default behavior is
such that:
1. The AX device sends traffic to the service-group members with the
highest priority.
2. If these high-priority servers go down, then the AX device selects the

service-group members with the next-highest priority.
3. However, if one or more of the high-priority servers return to service,

the AX device stops sending traffic to the low-priority servers and rese-
lects the high-priority servers.
Default Behavior (Priority Affinity Enabled)

If the priority affinity feature is enabled for the service group, then the
behavior of the AX device can best be describe as “less fickle”, with the AX
device continuing to send clients to the lower-priority servers, even after the
higher-priority servers have come back online.
Note: Previous releases provided an option (min-active-member) that enables

the AX to continue using backup servers. This approach can ensure the
availability of a configured minimum number of active servers, but unlike
priority affinity, the min-active-member option lacks a way to ensure traf-
fic is only sent to the backup servers.
Note: If the AX device stops using the primary servers due to other features (for
example, exceeding connection limits), then the priority affinity feature
will take effect just as if the switchover were triggered by a change in the
status of the primary servers. If the higher-priority servers subsequently
become available due to the number of connections dropping below the
configured threshold, then the AX device will not use them, but will
instead continue using the lower-priority backup servers.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
EXAMPLE
The following example helps illustrate how priority affinity works.
Assume a service group contains five members, as shown below:

• s1:80 priority 10
All five members of this service group (servers s1-s5) are up and available.
However, the AX device uses only members s1 and s2, because they have a
priority of 10. Members s3 and s4 are used only if both s1 and s2 go down.
Member s5 is a last-resort member that is used only if all other members are
down.
If server s1 goes down, as shown in Figure 170 below, the AX device con-
tinues sending traffic to the other highest-priority server, s2.
FIGURE 170 Priority Affinity – first server fails

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Next, assume server s2 also goes down, as shown in Figure 171 below.
Because s1 and s2 are both down, the AX device begins using the backup
servers (s3 and s4).
FIGURE 171 Priority Affinity – second server fails
By default, without priority affinity, if s1 or s2 returns to an available state,

the AX device stops using s3 and s4 and shifts back to s1 and s2. However,
with priority affinity enabled, the AX device continues to use s3 and s4 and
does not start using s1 or s2 again, despite their availability.
Note: If the AX continues to use the lower-priority servers and you wish to
force the AX to use the higher-priority servers again, you must adminis-
tratively reset the priority affinity.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Priority Affinity Options

Within the priority affinity feature, there are sub-options that enable you to
define specific actions that will occur if the higher-priority service-group
members fail.
This ability to specify a particular action to occur during a failover may be

helpful because it allows you to prevent your lower-priority secondary serv-
ers, (which are presumably less robust than your higher-priority servers),
from being overwhelmed by a flood of traffic that could occur during
failover.
Actions (drop, reset, and others) can be tied to a general failure, such as ser-
vice-group members becoming disabled, a failed health check, or to traffic
that is exceeding the configured connection-limits or connection-rate-limits.
Actions Available
You can configure the AX device to respond to service-group member fail-
ures by taking one of the following actions:
• Reset: Sends a reset to the client if all nodes with this same priority fail
for any reason
• Reset-if-exceed-limit: Sends a reset to the client if all nodes with this
same priority fail, and if failure is due to one or more nodes exceeding
the configured connection-limit or connection-rate-limit
• Drop: Drops the request if all nodes with this same priority fail for any
reason
• Drop-if-exceed-limit: Drops the request if all nodes with this same pri-
ority fail, and if one or more nodes exceed the configured connection-
limit or connection-rate-limit
• Proceed: The AX device uses the node(s) with the next-highest
priority if all nodes with the currently-selected priority fail (this is the
default behavior)
Note: Actions are tied to a certain priority levels and are not tied to individual
servers. Therefore, an action is only triggered when all service-group
members of a given priority become unavailable.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Triggers
The reset or drop actions can be triggered for the following reasons:
• If a health check fails
• If a user disables a server or port
• If another Load Balancing feature causes the currently-used priority to

become unavailable (for example, min-active-member)
• If a connection-limit or connection-rate-limit is exceeded
Actions Tied to Exceeded Limits

The following examples show scenarios in which the AX device performs a
certain action based on general failures or exceeded connection limits or
exceeded connection rate limits.
Simple Scenario – Service Group with Two Priorities

Consider the service-group below, which has two priorities (10 and 5). The
reset-if-exceed-limit or drop-if-exceed-limit command can be applied to
the higher priority level in order to reset the connection if the connection
limit is exceeded.
Slb service-group sg1 tcp
Priority 10 reset-if-exceed-limit
Member A:80 priority 10
Member B:80 priority 5
With this configuration, if member A (priority 10) exceeds the configured

connection-limit, the AX device responds by sending a reset to the client.
This reset will only happen if the connection limit is exceeded. If member A
should goes down for a different reason, such as failing a health check, then
the AX device will not perform the specified action. Instead, the AX device
will act according to its default behavior, meaning it will reselect the server
within the service-group that has the next-highest priority. In this example,
this means member B (priority of 5), would be used.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
More Complex Scenario – Multiple Members with Same Priority
This next example is slightly more complex. Assume the service-group has
several members with the same priority level.
Member C:80 priority 10
Member D:80 priority 5
In this case, members A, B, and C all have a priority of 10. The specified
action (reset-if-exceed-limit) only occurs if all three high-priority members
fail, and if one or more of the failures is caused by an exceeded connection
limit. If members A, B , and C were to go down for any other reason, such
as a failed health check, then the AX device would follow its default behav-
ior and send traffic to the lower-priority service-group member D.
Different Actions for Different Priority Levels

You can define different actions for different priority levels. Members A, B,
C, and D in the next example below each have different priority levels.
Different actions are associated with each of the different priority levels.
Priority 8 drop-if-exceed-limit
Member C:80 priority 5
Member D:80 priority 1
Details:
• The Priority Options feature operates at Layer 4 feature and thus will not
work if applied to virtual-ports, such as HTTP and SMTP, which are
Layer 7. A10 suggests you use L4 virtual-ports.
• The Priority Options feature is only supported for the default service-
group binding under the virtual-port. If the service-group has been con-
figured under aFleX, or a black/white list, or a class list, then the speci-
fied action (e.g. drop, reset, proceed) will not take effect.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• Rate limiting and priority are not supported with stateless load balanc-
ing. Therefore, the Priority Options feature is also not supported in state-
less load balancing implementations.
USING THE GUI
This is configurable on the configuration page for the service group.
USING THE CLI
Basic Priority Affinity Commands

To enable priority affinity in a service group, use the following command at
the configuration level for the group:
[no] priority-affinity
To display the current priority affinity value for a service group, use the fol-
lowing command:
show service-group group-name
After priority affinity is triggered, it remains in effect. To reset the feature

and return to using the primary servers, use the following command:
priority-affinity reset
This command resets priority affinity for the current service group and does
to affect the priority settings in other service groups.
Commands for Configuring Priority Affinity Actions

To configure the priority affinity actions within a service-group, configure
an SLB service-group. Add the members to the group and assign them each
a priority, using the following command:
member server-name:portnum priority num
Use the following command to specify the action for a specific priority
value:
priority num
[
drop |
drop-if-exceed-limit |
proceed |
reset |
reset-if-exceed-limit |
]

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
You can choose from the following actions to be applied to all service-group
members having the same priority:
• Send a TCP reset (RST) back to the client
• Drop the current request
• Proceed to use nodes with the next-highest priority in the service-group

(this is the default behavior)
• Reset-if-exceed-limit – Sends a reset to the client if one or more nodes
exceed the configured connection-limit or connection-rate-limit
• Drop-if-exceed-limit: Drops the request if one or more nodes exceed the
configured connection-limit or connection-rate-limit
Note: The actions above are mutually exclusive, meaning that only one action
can be configured for each priority level. However, the same action can be
used more than once for different priorities.
CLI Example – Basic Priority Affinity

The following commands add members to a service group. Members s1 and
s2 have the highest priority value within the group, so they will be used as
the primary members. Members s3 and s4 will be used only if both s1 and
s2 become unavailable. Member s5 will be used only if all the other mem-
bers are unavailable.
AX(config-slb svc group)#member s1:80 priority 10
The following command enables priority affinity. With this feature enabled,
if the primary members both become unavailable, the secondary members
(s3 and s4) will continue to be used even if s1 or s2 becomes available
again.
AX(config-slb svc group)#priority-affinity

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
In this example, the primary members (the ones with the highest priority
within the service group) are active, so the priority affinity value is the pri-
ority of those members. However, if both the primary members are down
and the secondary members are active, the priority affinity value changes to
the priority of the secondary members.
AX(config-slb svc group)#show service-group sg1
Service group name: sg1 State: All Up
Priority affinity: 5
...
Note: If the output indicates that the priority affinity value is 0, this indicates
that none of the service group’s members have ever had any active SLB
sessions. Typically, 0 appears when the service group is new and has not
yet received any SLB traffic.
CLI Example – Associating Actions with Priority Levels

The following command creates the TCP service-group “http”, and then
defines the reset-if-exceed-limit action for members with priority 10, and it
also defines the drop-if-exceed-limit action for members with priority 8.
AX(config)#slb service-group http tcp
AX(config-slb svc group)#priority ?
<1-16> Priority in the Group
AX(config-slb svc group)#priority 10 ?
drop Drop request when all priority nodes fail
drop-if-exceed-limit Drop request when connection over limit
proceed Proceed to next priority when all priority nodes
fail(default)
reset Send client reset when all priority nodes fail
reset-if-exceed-limit Send client reset when connection over limit
<cr>
AX(config-slb svc group)#priority 10 reset-if-exceed-limit
priority 8 drop-if-exceed-limit
member no30:80 priority 10
member no33:80
member no34:80

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Use the show slb service-group command to display information about the
service-group “http” created above. Output shows there were 23 packets
dropped and 41 connections reset:
AX(config)#show slb service-group http
Service group name: http State: Functional Up
Service: no30:80 DOWN
Total connections: 0 Response time: 0 tick
Peak conn: 0

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
AX Series - Configuration Guide
Overview
Source-IP Persistence Override and Reselect
This chapter describes the Source-IP Persistence Override and Reselect fea-
ture.
Overview
When the Source-IP Persistence Override and Reselect feature is enabled,
the AX device checks for higher-priority servers even if persistent sessions
are already established between client and server.
Default Behavior
Without this feature, if source-IP persistence is enabled and if a persistent
session has already been established between a client and a server, then the
AX device will send traffic to that same node until the node goes down or
the timeout period expires.
This “sticky” behavior (or persistence) is helpful in situations where it is

important to maintain a consistent connection between a client and a server,
such as with online shopping, where it may be desirable to track the client’s
interaction with the website.
The AX device typically uses the priority metric to select the highest prior-
ity server from a service group, and it establishes a persistent session
between the client and the selected server. Once the session is established,
the server selection process is complete, and the priority of one server over
another becomes irrelevant. Even if a higher-priority server becomes avail-
able, the AX device will “ignore” it and continue to honor the persistent ses-
sion that has already been established.
Behavior With Source-IP Persistence Override and Reselect

If the Source-IP Persistence Override and Reselect feature is enabled, then
the AX device no longer honors the source-IP persistence, and it continually
checks for higher-priority servers, even after persistent sessions have been
established between client and server.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
Simplified Example
For example, assume a service group has two servers and traffic is load bal-
anced across the two servers with persistency:
• Server A with priority = 10
• Server B with priority = 5
If Server A goes down, then the traffic is balanced to Server B, which has a
lower priority. A persistent connection is established with Server B.
However, because the Source-IP Persistence Override and Reselect feature
is enabled, when Server A comes back up, the persistence with Server B is
broken and a new persistent session is re-established with Server A.
Use Case Scenario

The behavior described above might be desirable if you want to send clients
to higher-priority servers as they become available. For example, this fea-
ture might be helpful if you have a large service group containing your new-
est and most robust servers, as well as a smaller service group containing a
few older and weaker backup servers that have a lower-priority.
If you are doing off-hours maintenance on the high-priority servers, you

must take them offline. Traffic will be sent to the low-priority servers in the
other service-group.
However, once the maintenance is complete and you bring the high-priority
servers back online, you might want to interrupt the persistent sessions that
clients have established with your inferior backup servers. These persistent
sessions will be broken in order to re-establish persistent sessions with your
more robust, high-priority servers.
USING THE GUI
This feature is not supported in the GUI for this release.
USING THE CLI
To enable Source-IP Persistence Override and Reselect, configure an SLB

template for source-IP persistence and then use the following command:
[no] enforce-higher-priority
The no form of the command can be used to disable the feature.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
CLI Example
Note: This example shows commands required to configure this feature and
does not represent a complete SLB configuration.
The following command creates a source-IP persistence template named
“SIP”.
AX(config)#slb template persist source-ip sip
AX(config-source ip persist)#enforce-higher-priority
The following commands create a virtual-server named “VIP1” at IP

address 1.2.3.4 on TCP port 80. The service-group “HTTP” and source-IP
persistence template “SIP” are then bound to this virtual server.
AX(config-slb vserver-vport)#service-group http
AX(config-slb vserver-vport)#template persist source-ip sip
You can use the show slb persist command to display information about the
status of the Source-IP Persistence Override and Reselect feature. The very
last line in the output below shows that the AX “broke” 30 persistent ses-
sions between a client and a low-priority node. This means server reselec-
tion occurred and new persistent sessions were established with higher-
priority nodes.
AX2500(config)#show slb persist
Total
------------------------------------------------------------------
URL hash persist (pri) 0
...
Cookie persist ok 0
Cookie persist fail 0
Persist cookie not found 0
Enforce higher priority 30

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Scan-All-Members Option in Persistence

Templates
In cookie, source-IP, and destination-IP persistence templates, the

match-type server option has a suboption called scan-all-members. The
scan-all-members option allows a persistent session to continue, even
when the real server port that the session is on becomes unavailable.
This chapter describes the scan-all-members 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-0026 - Ver. 2.7.0 11/1/2012
FIGURE 172 Scan-all-members
VIP 192.168.10.11 uses 3 real servers to provide 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.
For a new session, the SLB load-balancing method enabled on the service
group is used to select a server and port for the client (source IP address).
Because source-IP persistence is enabled, subsequent requests from the
same client are always sent to the same server.
By default, when the match-type is changed to match-type server, the AX

device uses the service group’s load-balancing method for the first request
to select a service-group member (server+port). For subsequent connections
from the same client, the AX device uses fast-path processing to select the
first service-group member that has the same IP address as the server that
was initially selected by the service group’s load-balancing method for the
first request.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
In this example, if the load-balancing method happens to choose port 80 on

server s3 for the first request, subsequent connections also are sent to port
80 on s3, since port 80 is in the first member (server+port) for s3 listed in
the service-group configuration. Because the match-type is set to match-
type server, if port 80 goes down, the next request for the persistent session
is still sent to s3, but to a different port on s3.
If the load-balancing method happens to choose port 8080 on server s3 for

the first request, subsequent requests are sent to port 80 on s3, since port 80
is in the first member (server+port) for s3 listed in the service-group config-
uration.
However, if the member (port 80 on s3) is set to a lower priority or is

administratively disabled, the AX device again will use the load-balancing
method to select a server and port for the next request. Any of the available
service-group members can be selected, even if they are different servers.
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 that 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.
In a match-type server configuration, 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 available service-group member on the same
server as the member that is out of service.
In this example, 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. When s3:80 is
available again, it is selected for any new connections. However, connec-
tions that are already in existence when s3:80 comes back up continue to go
to s3:8080.
CLI Example
The commands in this section configure the source-IP persistence template
and service group in Figure 172 on page 786.
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

AX(config)#slb service-group sg-1

AX(config-slb vserver-vport)#service-group sg-1
AX(config-slb vserver-vport)#template persist source-ip persist-source

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
SSL Certificate Management
This chapter describes how to manage SSL certificates, private keys, 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 279.)
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 the following
SSL and TLS versions:
• SSL v3.0
• TLS v1.0 (the default)
• TLS v1.1
• TLS v1.2
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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, to provide
verification of the content server’s identity. 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.
Figure 173 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 173 Typical SSL Handshake (simplified)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
To begin, the client sends an HTTPS request. The request includes some
encryption details such as the cipher suites supported by the client.
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 contained in the template to the cli-
ent.
The client browser checks its certificate store (sometimes called the certifi-
cate 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.
Certificate Chain
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 browser needs a
copy of the root CA’s certificate. If the CA that signed the server certificate
is not a root CA, the client browser should have another certificate or a cer-
tificate chain that includes the CA that signed the CA’s certificate.
A certificate chain contains the “chain” of signed certificates that leads from
the CA to the signature authority that signed the certificate for the server.
Typically, the certificate authority that signs the server certificate also will
provide the certificate chain. Figure 174 shows an example of a certificate
chain containing three certificates:
FIGURE 174 SSL Certificate Chain Example
-----BEGIN CERTIFICATE-----
ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw
Oi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQAD
gYEAheIVEe8vArUOZxKkUIGjaYymzJAh8Ty0uUPrikLpQ0IGezByVdbDUJ+HQLGp
2eruTPZpBNADaEfymstIPIxrsuCRhyr3Ymsa2rgzwy9kSXeG83H7E7HxRnpxDNZ8
l+uzpU/rk4j3bO/JVxPZMnwzMWriPSYgL1EKYcOSKyReaxQ=
-----END CERTIFICATE-----

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
The certificate chain file and the server certificate files are text files. Each
certificate must begin with the “-----BEGIN CERTIFICATE-----” line and
end with the “-----END CERTIFICATE-----” line.
The certificate at the top of the certificate chain file is the root CA’s certifi-
cate. The next certificate is an intermediary certificate signed by the root
CA. The next certificate is signed by the intermediate signature authority
that was signed the root CA.
A certificate chain in an SSL template must begin at the top with the root
CA’s certificate, followed in order by the intermediary certificates. If the
certificate authority that signs the server certificate does not provide the cer-
tificate chain in a single file, you can use a text editor to chain the certifi-
cates together in a single file as shown in Figure 174.
Certificate Warning from Client Browser

After the client browser validates the server certificate, the client accepts the
certificate and begins an encrypted session with the AX device.
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 175
shows an example of a certificate warning displayed by Internet Explorer.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
FIGURE 175 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.
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).
To ensure that clients receive the required chain of certificates, you also
can send clients a certificate chain in addition to the server certificate.
(See “Certificate Chain” on page 791.)
The example in Figure 173 on page 790 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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. A client-SLS template can
also contain a certificate chain.
• Server-SSL template – Contains CA certificates for SSL-encrypted traf-
fic between servers and the AX device.

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 simple deployment example in Figure 173 on page 790, only the
first option (Certificate) needs to be configured. You may also need to con-
figure the Certificate chain option.
A client-SSL template can contain up to 128 certificates or certificate

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
• Certificate chain – Specifies a named set of server certificates beginning
with a root CA certificate, and containing all the intermediary certifi-
cates in the authority chain that ends with the authority that signed the
server certificate. (See “Certificate Chain” on page 791.)
• 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.
Note: The CRL should be signed by the same issuer as the CA certificate. Oth-
erwise, the client and AX device will not be able to establish a connec-
tion.
• 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.
• 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.
• Session cache size – Specifies the maximum number of cached sessions
for SSL session ID reuse.
• Close notification – Specifies whether the AX device sends a
close_notify message when an SSL transaction ends, before sending a
FIN. This behavior is required by certain types of applications, includ-
ing PHP cgi.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
• SSL False Start – Specifies whether SSL False Start is enabled. SSL
False Start is an SSL modification used by the Google Chrome browser
for web optimization.
Note: The following ciphers are not supported with SSL False Start in the cur-
rent release:
If no other ciphers but these are enabled in the client-SSL template, SSL
False Start handshakes will fail.
• Server name indication – Enables support for the Server Name Indica-
tion (SNI) extension for Transport Layer Security (TLS). The SNI
extension enables servers that manage content for multiple domains at
the same IP address to use a separate server certificate for each domain.
One use for this feature is as part of an SSL Intercept deployment. (See
“SSL Intercept” on page 315.)
• Cipher template – Name of a cipher template containing a set of ciphers
to use with clients. By default, the client-SSL template’s own set of
ciphers is used. (See “Cipher Template Options” on page 798.)
• Forward proxy options – Options that can be used for SSL Intercept.
• 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
• TLS1_RSA_EXPORT1024_RC4_56_SHA

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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. If you need to use multiple CA certifi-
cates in a server-SSL template, see “Multiple CA Certificate Support in
Server-SSL Templates” on page 814.)
• Certificate – Specifies a client certificate that the AX device will send to
a server. When a server requests a client’s digital certificate, the AX
device responds on behalf of the client. Following successful authenti-
cation, the server and AX device communicate over an SSL-encrypted
session, while the client and AX device can communicate over a non-
encrypted session. From the server’s perspective, the server has an
encrypted session with the client.
• Key – Specifies a public key for the client certificate.
• SSL version – Highest (most secure) version of SSL/TLS to use. The

AX device supports the following SSL/TLS versions:
• SSL v3.0
• TLS v1.0 (the default)
• TLS v1.1
• TLS v1.2
• Close notification – Specifies whether the AX device sends a

close_notify message when an SSL transaction ends, before sending a
FIN. This behavior is required by certain types of applications, includ-
ing PHP cgi.
Note: The close notification option may not work if connection reuse is also
configured on the same virtual port. In this case, when the server sends a
FIN to the AX device, the AX device will not send a FIN followed by a
close notification. Instead, the AX device will send a RST.
• Cipher template – Name of a cipher template containing a set of ciphers
to use with servers. By default, the server-SSL template’s own set of
ciphers is used. (See “Cipher Template Options” on page 798.)
• Forward proxy – Enables support for capabilities required for SSL Inter-
cept. (See “SSL Intercept” on page 315.)
• 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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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, for CA certificates. Support for all of them is enabled by default.
Note: For client certificates, the key length for

SSL3_RSA_DES_40_CBC_SHA and SSL3_RSA_RC4_40_MD5 must
be 512 bits or less. The TLS1_RSA_EXPORT1024_RC4_56_MD5 and
TLS1_RSA_EXPORT1024_RC4_56_SHA ciphers are not supported.
Cipher Template Options
A cipher template contains a list of ciphers. A client or server who connects

to a virtual port that uses the cipher template can use only the ciphers that
are listed in the template.
Optionally, you can assign a priority value to each cipher in the template. In
this case, the AX device tries to use the ciphers based on priority. If the cli-
ent supports the cipher that has the highest priority, that cipher is used. If the
client does not support the highest-priority cipher, the AX device attempts
to use the cipher that has the second-highest priority, and so on.
The cipher priority can be 1-100. The highest priority (most favored) is 100.
By default, each cipher has priority 1.
More than one cipher can have the same priority. In this case, the strongest
(most secure) cipher is used.
Notes
• An SSL cipher template takes effect only when you apply it to a client-
SSL template or server-SSL template.
• When you apply (bind) a cipher template to a client-SSL or server-SSL
template, the settings in the cipher template override any cipher settings
in that client-SSL or server-SSL template.
• Priority values are supported only for client-SSL templates. If a cipher
template is used by a server-SSL template, the priority values in the
cipher template are ignored.
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
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 793).
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 801 and “Importing a Certificate and Key” on page 804.
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
key is already on the AX device. If the certificate is not in PEM for-
mat, specify the certificate format (type) when you import it.
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), specify the certificate format (type) when you

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Overview
import it. 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 821.
5. If applicable, import the certificate chain onto the AX device. The certif-
icate chain must be a single text file, beginning with a root CA’s certifi-
cate at the top, followed in order by each intermediate signing
authority’s certificate. (See “Certificate Chain” on page 791.)
Figure 176 shows the most common way to obtain and install a CA-signed
certificate onto the AX device. You also may need to install a certificate
chain file.
FIGURE 176 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-0026 - Ver. 2.7.0 11/1/2012
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 806.

USING THE GUI
1. Select Config Mode > Service > SSL Management, if not already
selected.
2. On the menu bar, select Certificate.
3. Click Add.
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.
Note: If you need to create a request for a wildcard certificate, use an asterisk as
the first part of the common name. For example, to request a wildcard cer-
tificate for domain example.com and it sub-domains, enter the following
common name: *.example.com
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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 804.)
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:
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• Key length, which can be 1024, 2048 or (on some 64-bit ACOS models)
4096 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
• 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(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:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Importing a Certificate and Key
Password []?********
File name [/]?ca-signedcert1

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

selected.
3. To import a certificate or certificate chain:

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 the certificate location:
• Local – The file is on the PC you are using to run the GUI, or is
on a PC or server in the local network.
• Remote – The file is on a remote server.
d. Select the format of the certificate from the Certificate Format drop-
down list.
e. If you selected Local as the file location, click Browse next to the
Certificate Source field and navigate to the location of the certifi-
cate.
If you selected Remote:
– To use the management interface as the source interface for the
connection to the remote device, select Use Management Port. Oth-
erwise, the AX device will attempt to reach the remote server
through a data interface.
– Select the file transfer protocol: HTTP, HTTPS, FTP, TFTP, RCP,
or SCP.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
– In the URL field, enter the directory path and filename.
– If needed, change the protocol port number in the port field. By
default, the default port number for the selected file transfer proto-
col is used.
– In the User and Password fields, enter the username and password
f. Click Open. The path and filename appear in the Source field.
g. If applicable, repeat the steps above for the private key.
h. Click OK. The certificate and key appear in the certificate and key
list.
USING THE CLI
To import a certificate and its key, or a certificate chain, use the following
command at the global Config level of the CLI:
[no] slb ssl-load
{certificate cert-name
[type {der | p7b | pem | pfx}] |
private-key string} url
The type option specifies the format of the certificate.
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:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Generating a Self-Signed Certificate
import ssl-cert file-name url
import ssl-key file-name url

USING THE GUI
selected.
3. Click Add.
4. Enter a name for the certificate.
5. In the Issuer drop-down list, select Self, if not already selected.
6. Enter the rest of the certificate information in the remaining fields of the
Certificate section.
Note: If you need to create a wildcard certificate, use an asterisk as the first part
of the common name. For example, to create a wildcard certificate for
domain example.com and it sub-domains, enter the following common
name: *.example.com
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
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 1024 or 2048 bits
• Common name, 1-64 characters

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
• 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
Note: If you need to create a wildcard certificate, use an asterisk as the first part
of the common name. For example, to create a wildcard certificate for
domain example.com and it sub-domains, enter the following common
name: *.example.com
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(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
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Importing a CRL
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

selected.
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 Privileged EXEC or

import ssl-crl file-name url
path, and filename.
entire URL:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Renewing a Certificate (GUI)
Renewing a Certificate (GUI)

You can easily renew certificates using the GUI. This enhancement applies
to self-signed certificates and to certificates signed by a Certificate Author-
ity (CA).
Renewing a Self-signed Certificate

To renew a certificate signed by the AX device itself (a self-signed
certificate):
1. Select Config Mode > Service > SSL Management > Certificate.
2. Click on the certificate name. The information page for the certificate
appears.
3. Click Renew. The configuration page for the certificate appears.
4. Edit any information that has changed.
5. Click OK.
Renewing a CA-signed Certificate

To renew a certificate signed by a Certificate Authority (CA):
1. Select Config Mode > Service > SSL Management > Certificate.
2. Click on the certificate name. The information page for the certificate
appears.
3. Click Renew. The page for generating a Certificate Signing Request

(CSR) appears.
4. Select Certificate Authority from the Issuer drop-down list, if not

already selected.
5. Enter or select the rest of the certificate information in the remaining

fields of the Certificate section.
6. Enter a passphrase.
7. From the Key Size drop-down list, select the length (bits) for the key.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Exporting Certificates, Keys, and CRLs
8. 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.
9. To save the CSR to your local device:

a. Click Download.
to override the setting. For example, in IE, hold the Ctrl key while click-
ing Download.
b. Click Save.
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-----”.
When you receive the certificate from the CA, import it onto the AX device.

This section describes how to export SSL resources from the AX device to
other devices.
Note: Due to a limitation in Windows, it is recommended to use names shorter

than 255 characters. Windows allows a maximum of 256 characters for
both the file name and the directory path. If the combination of directory
path and file name is too long, Windows will not recognize the file. This
limitation is not present on machines running Linux/Unix.
Exporting a Certificate and Key
USING THE GUI

selected.
3. To export a certificate:
a. Select the certificate. (Click the checkbox next to the certificate
name.)

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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:

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Creating a Client-SSL or Server-SSL Template and Binding it to a VIP
Exporting a CRL
USING THE CLI
To export a CRL, use the following command at the Privileged EXEC or

export ssl-crl file-name url
USING THE GUI

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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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 794, 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-
ure template parameters. (For information, see “SSL Templates” on
page 794 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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
Multiple CA Certificate Support in Server-SSL Templates

If you need to add multiple certificates to a server-SSL template, this sec-
tion describes how to configure it. A server-SSL template can have multiple
CA-signed certificates.
You can add the CA certificates to the server-SSL template in either of the
following ways:
• As separate files (one for each certificate)
• As a single file containing multiple certificates
Adding multiple certificates in a single file can simplify configuration. For

example, you can export the CA certificates from a web browser into a sin-
gle file, then import that file onto the AX device and add it to a server-SSL
template.
Previous releases allow a server-SSL template to have only a single CA-

signed certificate.
Note: A CA-signed certificate is a certificate that is signed by a Certificate

Authority (CA).
Multiple Certificates in Single File – Preparing the File

You can create the multiple certificate file by exporting the certificates from
a browser or you can assemble the file by hand.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To export the certificates from Internet Explorer (IE) version 9:
1. Select Tools > Internet Options.
2. Click on the Content tab.
3. Click Certificates.
4. Click on the Trusted Root Certification Authorities tab.
5. Select all the certificates.
6. Click Export.
7. Click Next.
8. Select PKCS #12 format (PFX), if not already selected.
9. Click Next.
10. When prompted for a file password, enter a password to secure the cer-
tificate file, and click Next.
11. When prompted for a filename:

a. Click Browse to navigate to the save location for the file.
b. Enter the filename and click Save.
12. Click Next.
13. Click Finish.
14. On the AX device:

a. Import the certificate file as a PFX file.
b. Use the GUI or CLI to add the certificate file to a server-SSL certif-
icate.
c. Bind the server-SSL certificate to the virtual port.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
To create the file manually:
1. Copy and paste each certificate to a text file. Make sure to include the "-
----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE----- "
lines for each certificate. For example:
MIIE0zCCA7ugAwIBAgIQGNr
RniZ96LtKIVjNzGs7SjANBg
kqhkiG9w0BAQUFADCB
U2lnbiwgSW5jLiAtIEZvciBhd
XRob3JpemVkIHVzZSBvbmx
5MUUwQwYDVQQDEzxW
2. Save the text file.
3. On the AX device:
a. Import the certificate file as a PEM file.
b. Use the GUI or CLI to add the certificate file to a server-SSL certif-
icate.
c. Bind the server-SSL certificate to the virtual port.
Support for Binding Server-SSL Templates to Individual Real Ports
For additional flexibility, the AX device supports binding of server-SSL

templates to individual real ports. This configuration option is useful in
cases where the real servers load balanced by a VIP have different SSL set-
tings.
If a server-SSL template is be bound to the virtual port instead, all the real
servers load balanced by the VIP must use the same SSL settings.
Template Priority
You can bind a server-SSL template to a real port and also to a virtual port
that uses that real port. In this case, the server-SSL template bound to the
real port is used for traffic sent to that real port. If you remove the server-
SSL template from the real port, the template bound to the virtual port is
used instead.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
USING THE GUI
On the configuration page for the real server, in the Port section, select the
template from the Server-SSL Template drop-down list.
USING THE CLI
To bind a server-SSL template to a real port, use the following command at

the configuration level for the real port:
[no] template server-ssl template-name
CLI Example
The following commands import a CA-signed certificate and key:
AX(config)#slb ssl-load certificate CACert88.pem tftp:
File name [/]?CACert88.pem
.0 minutes 1 seconds
AX(config)#slb ssl-load private-key CAkey tftp:
File name [/]?CAkey88
.0 minutes 1 seconds
The following commands create a server-SSL template and add the certifi-
cate and key to the template:
AX(config)#slb template server-ssl server-ssl1
AX(config-server ssl)#ca-cert CACert88.pem
AX(config-server ssl)#key CAkey88
AX(config-server ssl)#exit
The following commands bind the server-SSL template directly to a port on

a real server:
AX(config-real server-node port)#template server-ssl server-ssl1

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Support for TLS Server Name Indication
Support for TLS Server Name Indication

The AX device support for the Server Name Indication (SNI) extension for
Transport Layer Security (TLS). The SNI extension enables servers that
manage content for multiple domains at the same IP address to use a sepa-
rate server certificate for each domain.
Note: One use for this feature is as part of an SSL Intercept deployment. (See
“SSL Intercept” on page 315.)
To support the SNI extension, the AX device allows you to add multiple
certificates to a single client-SSL template, and map individual certificates
to their domain names.
In the current release, you can configure up to 1024 certificate-to-domain

mappings in a client-SSL template.
Default Certificate and Key

The client-SSL template must contain one certificate and private key pair
that is not mapped to a domain. The unmapped certificate and key are the
default certificate and key for the template. The AX device uses the default
template for negotiating the SSL session with the client.
If the client includes the SNI extension in its hello message, the AX device
uses the certificate that is mapped to the domain requested by the client.
Otherwise, the AX device uses the default certificate.
Partition Support
In the current release, this feature is supported only in the shared partition.
Use of the feature in private partitions is not supported.
USING THE GUI
Before creating the certificate-domain mappings, import the server certifi-

cates onto the AX device.
The configuration page for client-SSL templates has a Server Name Indica-
tion section. In this section, to create a certificate-domain mapping:
1. Enter the domain name in the Server Name field.
2. Select the certificate from the Server Certificate drop-down list.
3. Select the certificate’s private key from the Server Private Key drop-
down list.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring Email Notification for SSL Certificate Expiration
4. Click Add.
5. Repeat for each mapping.
USING THE CLI
To map a certificate to a domain, use the following command at the config-

uration level for the client-SSL template:

cert certificate-name key private-key-name
[partition shared]
The domain-name is the domain that is requested by clients. The cert and
key options specify the certificate and key to map to the domain. When a
client sends a request for the domain, the AX device uses the specified cer-
tificate when setting up the SSL session with the client.
Note: In the current release, the partition shared option has no effect on the
configuration. The configuration always applies only to the shared parti-
tion.
The pass-phrase option specifies the passphrase used to encrypt the key, if
applicable.
Configuring Email Notification for SSL Certificate

Expiration
The AX device can send email notification when an SSL certificate is about
to expire. This feature sends a daily email listing the certificates that are
about to expire or that have recently expired.
By default, this feature is not configured. To configure email notification for

certificate expiration, use either of the following methods.
USING THE GUI

selected.
2. On the menu bar, select Expiration Mail.
3. Enter the email address to which to send the notifications.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Configuring Email Notification for SSL Certificate Expiration
4. In the Before field, specify how many days before expiration to begin
sending notification emails. You can specify 1-5.
5. In the Interval field, specify how many days after expiration to continue
sending notification emails. You can specify 1-5.
6. To exclude a certificate from notification, select it from the Certificate

Name drop-down list and click Add. Repeat for each certificate to
exclude.
7. Click OK.
USING THE CLI

To configure email notification for certificate expiration, use the following
commands:
[no] slb ssl-expire-check

email-address address [...]
[before days] [interval days]
This command enables the feature. Enter this command at the global config-
uration level of the CLI.
The address [...] option specifies the email addresses to which to send the
notifications. You can specify up to 2 email addresses. Use a space between
them.
The before option specifies how many days before expiration to begin send-
ing notification emails. You can specify 1-5. The default is 5.
The interval option specifies how many days after expiration to continue
sending notification emails. You can specify 1-5. The default is 2.
One notification is sent per day. If a certificate is updated before expiration

or at least before the configured interval, no more notification emails are
sent for that certificate.
To exclude specific certificates from notification, use the following com-

mand to configure an exception list:
[no] slb ssl-expire-check exception
{add cert-name | delete cert-name | clean}
The add option adds a certificate to the exception list. The delete option
removes a certificate from the list. The clean option removes all certificates

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Converting Certificates and CRLs to PEM Format
from the list. Enter this command at the global configuration level of the
CLI.
To display certificate notification information, use the following command:

show slb ssl-expire-check
CLI Example
The following command enables certificate notifications to be sent to email
address “admin1@example.com”. Expiration notifications are sent begin-
ning 4 days before expiration and continue for 3 days after expiration.
AX(config)#slb ssl-expire-check email-address admin1@example.com before 4
interval 3

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.
Note: You do not need to convert the certificate into PEM format before import-
ing it. You can specify the format when you import the certificate. The
AX device automatically converts the imported certificate into PEM for-
mat. (See “Importing a Certificate and Key” on page 804.)
If you prefer to convert a certificate before importing it, see the following
sections.
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.

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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.
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

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
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-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Preventing Reset of SLB and Ethernet Statistics
The AX device provides an option to prevent resetting (clearing) of statis-

tics for the following resources: SLB servers, service groups, virtual serv-
ers, and Ethernet interfaces. By default, statistics counters for these types of
resources can be reset by AX admins.
This option applies to statistics counters in the output of the following GUI
pages and CLI commands.
• GUI pages:
• Monitor > Service > SLB > Virtual Server
• Monitor > Service > SLB > Virtual Service
• Monitor > Service > SLB > Server Group
• Monitor > Service > SLB > Server
• Monitor > Network > Interface
• CLI commands:
• show slb virtual-server
• show slb service-group
• show slb server
• show interfaces
By default, clearing of the statistics is allowed. You can disable reset of SLB
and Ethernet statistics, on a global basis. (The setting is global within the
partition you are in. See “Admin Roles That Can Disable or Re-enable
Clearing of SLB and Ethernet Statistics” on page 825.)
Admin Roles That Can Disable or Re-enable Clearing of SLB

and Ethernet Statistics
Admins with the following roles are allowed to disable or re-enable clearing
of SLB and Ethernet statistics.
TABLE 44 Admin Roles That Can Disable Clearing of SLB and Ethernet
Statistics
GUI Roles CLI Roles
ReadWriteAdmin write
SlbServiceAdmin partition-write
The setting takes effect on a partition-wide basis. For example, if an admin

in the shared partition disables clearing of the statistics, this applies to all

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
shared-partition admins. Admins in other partitions are not affected by the

change. Likewise, if a private partition admin disables clearing of the statis-
tics, this change does not affect shared-partition admins or admins of any
other private partitions.
USING THE GUI
To disable reset of SLB and Ethernet statistics:

2. Next to Disable Reset Statistics, select Enabled.
3. Click OK.
To re-enable reset of SLB and Ethernet statistics:

2. Next to Disable Reset Statistics, select Disabled.
3. Click OK.
USING THE CLI
To disable reset of SLB and Ethernet statistics, use the following command
at the global configuration level of the CLI
disable reset statistics
To re-enable reset of the statistics, use the following command at the global
enable reset statistics
CLI Example
The following command disables reset of SLB and Ethernet statistics:
AX(config)#disable reset statistics
The following commands attempt to clear SLB and Ethernet statistics but
are not allowed:
AX(config)#clear slb server all
Reset statistics disabled
AX(config)#clear statistics
Reset statistics disabled

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012

Document No.: D-030-01-00-0026 - Ver. 2.7.0 11/1/2012
Performance by Design
A10 Networks, Inc.

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

Fax: +1-408-325-8666
www.a10networks.com
© 2012 A10 Networks Corporation. All rights reserved.
828

AX SLB ADC Config Guide v2 7-0-20121101

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

AX SLB ADC Config Guide v2 7-0-20121101

Caricato da

Copyright:

Formati disponibili

Application Delivery and Server Load Balancing

AX Series Advanced Traffic Manager

A10 Networks Inc. Software License and End User Agreement

End User License Agreement

IMPORTANT: PLEASE READ THIS END USER LICENSE AGREEMENT CARE-

A10 NETWORKS IS WILLING TO LICENSE THE PRODUCT (AX Series) TO YOU

Performance by Design 3 of 828

Software, Upgrades and Additional Products or Copies. For purposes of this

OTHER PROVISIONS OF THIS AGREEMENT:

Export. Software and Documentation, including technical data, may be subject to

4 of 828 Performance by Design

Disclaimer of Liabilities. REGARDLESS OF ANY REMEDY SET FORTH FAILS

In no event shall A10 Networks’ or its suppliers' or licensors' liability to Customer,

Performance by Design 5 of 828

6 of 828 Performance by Design

Obtaining Technical Assistance

A10 Networks, Inc.

Tel: +1-408-325-8668 (main)

Collecting System Information

To collect system information, use either of the following methods.

USING THE GUI (RECOMMENDED)

3. Email the file as an attachment to support@A10Networks.com.

USING THE CLI

Performance by Design 7 of 828

8 of 828 Performance by Design

About This Document

This document describes features of the A10 Networks AX Series™

FIGURE 1 AX 5630 (front panel view)

Information is available for AX Series products in the following documents.

• AX Series LOM Reference

• AX Series System Configuration and Administration Guide

• AX Series Application Delivery and Server Load Balancing Guide

• AX Series Global Server Load Balancing Guide

• AX Series GUI Reference

• AX Series CLI Reference

• AX Series aFleX Reference

• AX Series MIB Reference

• AX Series aXAPI Reference

Performance by Design 9 of 828

A10 Virtual Application Delivery Community

10 of 828 Performance by Design

Obtaining Technical Assistance 7

About This Document 9

One-Arm Deployment in Route Mode 25

Layer 3 Direct Server Return 43

More SLB Deployment Examples 63

Performance by Design 11 of 828

IPv4 Load Balancing 99

IPv6 Load Balancing 107

Layer 4 TCP/UDP Load Balancing 111

Stateless SLB 123

Stateless Hash-based SLB 127

Auto-switch to Stateless SLB Based on Traffic 129

FTP Load Balancing 133

Streaming-Media Load Balancing 153

HTTP Load Balancing 159

12 of 828 Performance by Design

Web Logging for HTTP and RAM Caching 219

Performance by Design 13 of 828

SIP Load Balancing 225

Generic TCP-Proxy 261

Diameter AAA Load Balancing 263

SSL Offload and SSL Proxy 279

STARTTLS for Secure SMTP 299