AX Series™ Advanced Traffic Manager Configuration Guide

P e r f o r m a n c e
b y
D e s i g n
AX Series Advanced Traffic Manager
Configuration Guide
Document No.: D-030-01-00-0006
Ver. 2.4.3 6/21/2010
Headquarters
A10 Networks, Inc.
2309 Bering Dr.
San Jose, CA 95131-1125 USA
Tel: +1-408-325-8668 (main)
Tel: +1-408-325-8676 (support)
Fax: +1-408-325-8666
www.a10networks.com
A10 Networks, Inc. 6/21/2010 - All Rights Reserved
Information in this document is subject to change without notice.

Trademarks:
A10 Networks, the A10 logo, ACOS, aFleX, aXAPI, IDaccess, IDsentrie, IP-to-ID,
SoftAX, Virtual Chassis, and VirtualN are trademarks or registered trademarks of
A10 Networks, Inc. All other trademarks are property of their respective owners.
Patents Protection:
A10 Networks products including all AX Series products are protected by one or
more of the following US patents and patents pending: 7716378, 7675854, 7647635,
7552126, 20090049537, 20080229418, 20080040789, 20070283429, 20070271598,
20070180101
A10 Networks Inc. software license and end users agreement
Software for all AX Series products contains trade secrets of A10 Networks and its
subsidiaries and Customer agrees to treat Software as confidential information.
Anyone who uses the Software does so only in compliance with the terms of this
Agreement. Customer shall not:
1) reverse engineer, reverse compile, reverse de-assemble or otherwise translate the
Software by any means
2) sublicense, rent or lease the Software.
Disclaimer
The information presented in this document describes the specific products noted
and does not imply nor grant a guarantee of any technical performance nor does it
provide cause for any eventual claims resulting from the use or misuse of the products described herein or errors and/or omissions. A10 Networks, Inc. reserves the
right to make technical and other changes to their products and documents at any
time and without prior notification.
No warranty is expressed or implied; including and not limited to warranties of noninfringement, regarding programs, circuitry, descriptions and illustrations herein.
Environmental Considerations
Some electronic components may possibly contain dangerous substances. For information on specific component types, please contact the manufacturer of that component. Always consult local authorities for regulations regarding proper disposal of
electronic components in your area.
Further Information
For additional information about A10 products, terms and conditions of delivery, and
pricing, contact your nearest A10 Networks, Inc. location which can be found by visiting www.a10networks.com.
EX Series Secure WAN Manager Configuration Guide

-
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3
3 of 950
EX Series Secure WAN Manager Configuration Guide

-
4 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3
AX Series - Configuration Guide

About This Document
Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid A10
Networks Regular and Technical Support service contracts, the A10 Networks Technical Assistance Center provides support services online and
over the phone.
Corporate Headquarters
A10 Networks, Inc.
2309 Bering Dr.
Tel: +1-408-325-8668 (main)
Tel: +1-888-822-7210 (support toll-free in USA)
Tel: +1-408-325-8676 (support direct dial)
Fax: +1-408-325-8666
www.a10networks.com
Collecting System Information

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

1.
2.
3.
4.
5.
6.
7.
b y
Log into the GUI.

Select Monitor > System > Logging.
On the menu bar, click Show Tech.
Click Export. The File Download dialog appears.
Click Save. The Save As dialog appears.
Navigate to the location where you want to save the file, and click Save.
Email the file as an attachment to support@A10Networks.com.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
5 of 950

About This Document
USING THE CLI

1. Log into the CLI.
2. Enable logging in your terminal emulation application, to capture output generated by the CLI.
3. Enter the enable command to access the Privileged EXEC mode of the
CLI. Enter your enable password at the Password prompt.
4. Enter the show techsupport command.
5. After the command output finishes, save the output in a file.
6. Email the file as an attachment to support@A10Networks.com.
Note:
As an alternative to saving the output in a log file captured by your terminal emulation application, you can export the output from the CLI using
the following command:
show techsupport export [use-mgmt-port] url
(For syntax information, see the AX Series CLI Reference.)
6 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

About This Document
About This Document

This document describes the features of the A10 Networks AX Series
Advanced Traffic Manager. Configuration examples of the major features
are provided.
Additional information is available for AX Series systems in the following
documents. These documents are included on the documentation CD
shipped with your AX Series system, and also are available on the A10 Networks support site:
AX Series Installation Guide
AX Series GUI Reference
AX Series CLI Reference
AX Series aFleX Reference
AX Series MIB Reference
AX Series aXAPI Reference
This document assumes that you have already performed the basic deployment tasks described in the AX Series Installation Guide.
System Description The AX Series

FIGURE 1
The AX Series Advanced Traffic Manager
The AX Series is the industrys best performing application acceleration

switch that helps organizations scale and maximize application availability
through the worlds most advanced application delivery platform. The
AX Series Advanced Core Operating System (ACOS) accelerates and
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
7 of 950

About This Document
secures critical business applications, provides the highest performance and
reliability, and establishes a new industry-leading price/performance For
more detailed information, see System Overview on page 25.
Audience
This document is intended for use by network architects for determining
applicability and planning implementation, and for system administrators
for provision and maintenance of the A10 Networks AX Series.
Representations of Layer 2 and Layer 3 Devices

This document uses the following commonly used icons in network topology examples for vendor-agnostic representations of Layer 2 switches and
Layer 3 routers.
Icon
Description
Layer 2 switch
Layer 3 router
8 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
Obtaining Technical Assistance
Collecting System Information.............................................................................................................. 5
About This Document
System Description The AX Series .................................................................................................... 7

Audience.................................................................................................................................................. 8
Representations of Layer 2 and Layer 3 Devices ................................................................................ 8
System Overview
25
AX Series Features............................................................................................................................... 25
ACOS Architecture ............................................................................................................................... 27
AX Software Processes .................................................................................................................. 27
Local File Storage ........................................................................................................................... 29
Hardware Interfaces ............................................................................................................................. 30
Software Interfaces............................................................................................................................... 30
Server Load Balancing......................................................................................................................... 31
Intelligent Server Selection ............................................................................................................. 32
Configuration Templates ................................................................................................................. 32
Global Server Load Balancing............................................................................................................. 34
Outbound Link Load Balancing .......................................................................................................... 34
Transparent Cache Switching ............................................................................................................. 34
Firewall Load Balancing....................................................................................................................... 34
Where Do I Start?.................................................................................................................................. 35
Basic Setup
37
Logging On............................................................................................................................................ 37
Logging Onto the CLI ...................................................................................................................... 38
Logging Onto the GUI ..................................................................................................................... 39
Configuring Basic System Parameters .............................................................................................. 41
Setting the Hostname and Other DNS Parameters ........................................................................ 42
Setting the CLI Banners .................................................................................................................. 43
Setting Time/Date Parameters ....................................................................................................... 44
Configuring Syslog Settings ............................................................................................................ 46
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
9 of 950

Contents
Enabling SNMP .............................................................................................................................. 50

SNMP Traps ................................................................................................................................ 51
SNMP Communities and Views .................................................................................................. 53
SNMP Configuration Steps ......................................................................................................... 54
Configuration Examples .......................................................................................................................57
Emailing Log Messages........................................................................................................................64
Network Setup
71
Overview ................................................................................................................................................71
IP Subnet Support .......................................................................................................................... 72
Transparent Mode .................................................................................................................................73
Configuration Example ................................................................................................................... 74
Transparent Mode in Multinetted Environment ..................................................................................80
Route Mode............................................................................................................................................86
Direct Server Return in Transparent Mode .........................................................................................91
Direct Server Return in Route Mode....................................................................................................96
Direct Server Return in Mixed Layer 2/Layer 3 Environment............................................................99
Open Shortest Path First (OSPF)
105
Support for Multiple OSPFv2 Processes and OSPFv3 Instances...................................................105

Support for OSPFv2 and OSPFv3 on the Same Interface or Link ..................................................105
OSPF MIB Support ..............................................................................................................................105
Configuration Example .......................................................................................................................106
Interface Configuration ................................................................................................................. 106
Global OSPF Parameters ............................................................................................................. 107
OSPF Logging .............................................................................................................................. 108
HTTP Load Balancing
109
Overview ..............................................................................................................................................109
Configuring HTTP Load Balancing....................................................................................................113
10 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
HTTP Options for SLB
125
Overview.............................................................................................................................................. 125
Summary of HTTP Options ........................................................................................................... 125
HTTP Template Configuration ...................................................................................................... 126
URL Hash Switching........................................................................................................................... 128
URL Hash Switching with Server Load Awareness ...................................................................... 130
Configuring URL Hashing ............................................................................................................. 132
URL / Host Switching ......................................................................................................................... 133
Configuring URL / Host Switching ................................................................................................ 136
Using URL / Host Switching along with Cookie Persistence ........................................................ 137
Using URL / Host Switching along with Source IP Persistence .................................................... 141
URL Failover........................................................................................................................................ 141
Configuring URL Failover ............................................................................................................. 142
5xx Retry and Reassignment............................................................................................................. 143
Content Compression ........................................................................................................................ 144
Hardware-Based Compression ..................................................................................................... 146
How the AX Device Determines Whether to Compress a File ...................................................... 147
Configuring Content Compression ................................................................................................ 148
Client IP Insertion / Replacement...................................................................................................... 151
Configuring Client IP Insertion / Replacement .............................................................................. 153
Header Insertion / Erasure ................................................................................................................. 154
Configuring Header Insertion / Replacement ................................................................................ 155
Configuring Header Erasure ......................................................................................................... 158
URL Redirect Rewrite......................................................................................................................... 159
Configuring URL Redirect Rewrite ................................................................................................ 160
Strict Transaction Switching ............................................................................................................. 161
Enabling Strict Transaction Switching .......................................................................................... 162
FTP Load Balancing
163
Overview.............................................................................................................................................. 163
Configuring FTP Load Balancing...................................................................................................... 165
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
11 of 950

Contents
SIP Load Balancing
183
Load Balancing for SIP over UDP......................................................................................................183

Configuring Load Balancing for SIP over UDP ............................................................................. 184
Load Balancing for SIP over TCP/TLS ..............................................................................................197
SIP Multiplexing ............................................................................................................................ 197
Client Keepalive and Server Keepalive ........................................................................................ 200
AX Actions if Selection of a Client or SIP Server Fails ................................................................. 201
SLB Network Address Translation for SIP over TCP / TLS .......................................................... 201
Configuring SIP over TCP / TLS for SIP Multiplexing .................................................................. 202
CLI Example ............................................................................................................................. 213
Displaying SIP SLB Statistics .................................................................................................... 215
CLI Example ............................................................................................................................. 215
Disabling Reverse NAT Based on Destination IP Address..............................................................216
IP NAT for SIP ......................................................................................................................................218
SSL Offload and SSL Proxy
219
Overview ..............................................................................................................................................219
Choosing an SSL Optimization Implementation ........................................................................... 219
Configuring Client SSL .......................................................................................................................220
Configuring HTTPS Offload................................................................................................................224
Configuring the SSL Proxy Feature...................................................................................................231
STARTTLS for Secure SMTP
239
Overview ..............................................................................................................................................239
Configuring STARTTLS ......................................................................................................................241
Streaming-Media Load Balancing
249
Overview ..............................................................................................................................................249
Configuring Streaming-Media SLB....................................................................................................251
Layer 4 TCP/UDP Load Balancing
255
Overview ..............................................................................................................................................255
Configuring Layer 4 Load Balancing.................................................................................................258
IP Protocol Load Balancing
263
Overview ..............................................................................................................................................263
Configuring IP Protocol Load Balancing ..........................................................................................266
12 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
Wildcard VIPs
271
Configuring a Wildcard VIP ............................................................................................................... 271

Configuration Examples ............................................................................................................ 275
SLB Protocol Translation
277
Stateless SLB
285
Stateless Load-Balancing Methods .................................................................................................. 285
Outbound Link Load Balancing
289
Configuring Link Load Balancing .................................................................................................. 291
Transparent Cache Switching
295
Overview.............................................................................................................................................. 295
Configuring Layer 4 TCS.................................................................................................................... 298
Configuring Layer 7 TCS.................................................................................................................... 301
Service Type HTTP Without URL Switching Rules ...................................................................... 304
Service Type HTTP with URL Switching Rules ............................................................................ 305
Optimizing TCS with Multiple Cache Servers ............................................................................... 306
Enabling Support for Cache Spoofing .......................................................................................... 308
Configuring IPv4 TCS in High Availability Layer 3 Inline Mode ..................................................... 309
AX-1 Configuration ....................................................................................................................... 312
Configuring IPv6 TCS in High Availability Layer 3 Inline Mode ..................................................... 316
Configuring TCS for FTP.................................................................................................................... 322
Configuration ................................................................................................................................ 323
Firewall Load Balancing
327
Overview.............................................................................................................................................. 327
FWLB HA with Direct Connection of AX Devices to Firewalls ...................................................... 329
FWLB Parameters............................................................................................................................... 332
TCP and UDP Session Aging ....................................................................................................... 335
Configuring FWLB .............................................................................................................................. 336
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
13 of 950

Contents
Server and Port Templates
353
Overview ..............................................................................................................................................353
Parameters That Can Be Configured Using Server and Port Templates ..................................... 354
Default Server and Service Port Templates ................................................................................. 356
Configuring Server and Service Port Templates..............................................................................357
Applying a Server or Service Port Template.....................................................................................358
Binding a Server Template to a Real Server ................................................................................ 359
Binding a Server Port Template to a Real Server Port ................................................................. 360
Binding a Virtual Server Template to a Virtual Server .................................................................. 360
Binding a Virtual Server Port Template to a Virtual Service Port ................................................. 361
Binding a Server Port Template to a Service Group .................................................................... 361
Connection Limiting............................................................................................................................362
Setting a Connection Limit ........................................................................................................ 363
Connection Rate Limiting...................................................................................................................364
Slow-Start.............................................................................................................................................366
Gratuitous ARPs for Subnet VIPs......................................................................................................369
TCP Reset Option for Session Mismatch..........................................................................................370
Health Monitoring
373
Default Health Checks ........................................................................................................................373

Health Method Timers.........................................................................................................................374
Health Check Operation ............................................................................................................... 375
Health Method Types ..........................................................................................................................377
Protocol Port Numbers Tested by Health Checks ........................................................................ 382
Configuring and Applying a Health Method .....................................................................................382
Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments .............................. 386
Configuring POST Requests in HTTP/HTTPS Health Monitors ................................................... 388
Customizing DNS Health Monitors ............................................................................................... 391
Overriding the Target IP Address or Protocol Port Number ......................................................... 394
Basing a Ports Health Status on Another Ports Health Status ................................................... 397
Service Group Health Checks ............................................................................................................398
Disable Following Failed Health Check.............................................................................................401
In-Band Health Monitoring .................................................................................................................402
Configuring In-Band Health Monitoring ........................................................................................ 404
Consecutive Health Checks Within a Health Check Period ............................................................406
14 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
Maintenance Health Status for Servers in Persistence Configurations ........................................ 407

On-Demand Health Checks................................................................................................................ 408
Enabling Strict Retries ....................................................................................................................... 410
Globally Changing Health Monitor Parameters ............................................................................... 411
Globally Disabling Layer 3 Health Checks .................................................................................... 412
Compound Health Monitors............................................................................................................... 413
Displaying Health Status.................................................................................................................... 417
Using External Health Methods......................................................................................................... 420
Configuration ................................................................................................................................ 420
Script Examples ............................................................................................................................ 422
TCL Script Example .................................................................................................................. 422
Perl Script Example ................................................................................................................... 424
Shell Script Example ................................................................................................................. 425
Global Server Load Balancing
427
Overview.............................................................................................................................................. 427
Advantages of GSLB .................................................................................................................... 429
Zones, Services, and Sites ........................................................................................................... 430
GSLB Policy .................................................................................................................................. 430
Health Checks ........................................................................................................................... 432
Geo-Location ............................................................................................................................. 433
DNS Options ............................................................................................................................. 435
Metrics That Require the GSLB Protocol on Site AX Devices .................................................. 437
Configuration Overview ..................................................................................................................... 438
Configure Health Monitors ............................................................................................................ 439
Configure the DNS Proxy ............................................................................................................. 440
Configure a GSLB Policy .............................................................................................................. 442
Enabling / Disabling Metrics ...................................................................................................... 442
Changing the Metric Order ........................................................................................................ 444
Configuring RTT Settings .......................................................................................................... 445
Passive RTT .............................................................................................................................. 451
Configuring BW-Cost Settings ................................................................................................... 452
Configuring Alias Admin Preference ......................................................................................... 458
Configuring Weighted Alias ....................................................................................................... 459
Loading or Configuring Geo-Location Mappings ....................................................................... 459
Configure Services ....................................................................................................................... 468
Gateway Health Monitoring ....................................................................................................... 469
CLI ExampleSite with Single Gateway Link ........................................................................... 472
CLI ExampleSite with Multiple Gateway Links ....................................................................... 473
Multiple-Port Health Monitoring ................................................................................................. 473
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
15 of 950

Contents
Configure Sites ............................................................................................................................. 475

Configure a Zone .......................................................................................................................... 476
Enable the GSLB Protocol ........................................................................................................... 477
GSLB Parameters................................................................................................................................479
Policy Parameters ........................................................................................................................ 494
Configuration Examples .....................................................................................................................506
CLI Example ................................................................................................................................. 506
Configuration on the GSLB AX Device (GSLB Controller) ........................................................ 506
Configuration on Site AX Device AX-A ..................................................................................... 507
Configuration on Site AX Device AX-B ..................................................................................... 508
GUI Example ................................................................................................................................ 508
Configuration on the GSLB AX Device (GSLB Controller) ........................................................ 508
Configuration on Site AX Devices ............................................................................................. 518
RAM Caching
519
Overview ..............................................................................................................................................519
RFC 2616 Support ....................................................................................................................... 519
If-Modified-Since Header Support ............................................................................................. 520
Support for no-cache and max-age=0 Cache-Control Headers ................................................ 520
Insertion of Age and Via Headers into Cached Responses ...................................................... 521
Cacheability Behavior of AX RAM Cache .................................................................................... 521
Dynamic Caching ......................................................................................................................... 522
Host Verification ........................................................................................................................... 522
Configuring RAM Caching..................................................................................................................523
High Availability
533
Overview ..............................................................................................................................................533
Layer 3 Active-Standby HA .......................................................................................................... 534
Layer 3 Active-Active HA .............................................................................................................. 536
Layer 2 Active-Standby HA (Inline Deployment) .......................................................................... 538
Preferred HA Port ...................................................................................................................... 541
Port Restart ............................................................................................................................... 542
Layer 3 Active-Standby HA (Inline Deployment) .......................................................................... 543
HA Messages ............................................................................................................................... 544
HA Heartbeat Messages ........................................................................................................... 545
Gratuitous ARPs ....................................................................................................................... 545
HA Interfaces ................................................................................................................................ 546
Session Synchronization .............................................................................................................. 547
16 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
Optional Failover Triggers ............................................................................................................ 548

VLAN-based Failover ................................................................................................................ 548
Gateway-based Failover ........................................................................................................... 548
Route-based Failover ................................................................................................................ 549
Real Server or Port Health-based Failover ............................................................................... 549
VIP-based Failover .................................................................................................................... 550
How the Active AX Device Is Selected ......................................................................................... 551
HA Pre-Emption ............................................................................................................................ 554
HA Sets ......................................................................................................................................... 555
HA Configuration Parameters ....................................................................................................... 556
HA Status Indicators .......................................................................................................................... 563
In the GUI .................................................................................................................................. 563
In the CLI ................................................................................................................................... 563
Configuring Layer 3 HA...................................................................................................................... 564
Configuring Layer 2 HA (Inline Mode) .............................................................................................. 574
Layer 2 Inline HA Configuration Example ..................................................................................... 574
Configuring Layer 3 HA (Inline Mode) .............................................................................................. 582
Layer 3 Inline HA Configuration Example ..................................................................................... 583
Configuring Optional Failover Triggers............................................................................................ 588
VLAN-Based Failover Example .................................................................................................... 588
Gateway-Based Failover Example ............................................................................................... 589
Route-Based Failover Example .................................................................................................... 591
VIP-Based Failover Example ........................................................................................................ 593
Forcing Active Groups to Change to Standby Status..................................................................... 595
Enabling Session Synchronization................................................................................................... 595
Configuring OSPF-Related HA Parameters...................................................................................... 597
OSPF Awareness of HA ............................................................................................................... 597
OSPF Support on Standby AX in Layer 3 Inline Mode ................................................................. 598
Synchronizing Configuration Information........................................................................................ 598
Configuration Items That Are Backed Up ..................................................................................... 599
Configuration Items That Are Not Backed Up ........................................................................... 600
Performing HA Synchronization .................................................................................................... 602
Tip for Ensuring Fast HA Failover..................................................................................................... 604
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
17 of 950

Contents
Network Address Translation
607
SLB NAT ...............................................................................................................................................608

SLB Destination NAT ................................................................................................................... 608
SLB Source NAT .......................................................................................................................... 609
IP Source NAT Configuration Limits ......................................................................................... 609
Connection Reuse .................................................................................................................... 609
Source NAT for Servers in Other Subnets ................................................................................ 614
Direct Server Return ..................................................................................................................... 616
IP NAT Support for VIPs .............................................................................................................. 618
Using IP Pool Default Gateways To Forward Traffic from Real Servers ...................................... 619
IP Source NAT......................................................................................................................................619
Configuring Dynamic IP Source NAT ........................................................................................... 621
Configuring Static IP Source NAT ................................................................................................ 627
NAT ALG Support for PPTP ......................................................................................................... 630
Configuring NAT ALG for PPTP ................................................................................................ 631
Fast Aging for IP NATted ICMP and DNS Sessions .................................................................... 634
Client and Server TCP Resets for NATted TCP Sessions ........................................................... 636
Requirements for Translation of DNS Traffic ............................................................................... 636
IP NAT Use in Transparent Mode in Multi-Netted Environment ................................................... 636
NAT Range List Requires AX Interface or Route Within the Global Subnet ................................ 637
IP NAT in HA Configurations ........................................................................................................ 637
Large-Scale Network Address Translation
639
Overview ..............................................................................................................................................639
How LSN Differs from Traditional NAT ......................................................................................... 643
Benefits of LSN ............................................................................................................................ 645
Sticky NAT ................................................................................................................................ 645
Full-Cone NAT .......................................................................................................................... 645
Hairpinning ................................................................................................................................ 647
User Quotas .............................................................................................................................. 647
Static Port Reservation ............................................................................................................. 649
LSN Logging ................................................................................................................................. 650
LSN Operational Logging .......................................................................................................... 650
LSN Traffic Logging .................................................................................................................. 651
LSN NAT Capacities .................................................................................................................... 652
Notes and Limitations ................................................................................................................... 654
Configuring Large-Scale NAT ............................................................................................................655
Configure an LSN NAT Pool ........................................................................................................ 656
Configure a LID ............................................................................................................................ 656
Configure a Class List .................................................................................................................. 657
18 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
Bind the CLass List for Use with LSN ........................................................................................... 658
Enable Inside NAT on the Interface Connected to Internal Clients .............................................. 658
Enable Outside NAT on the Interface Connected to the Internet ................................................. 658
Enable New-path Processing ....................................................................................................... 659
Optional Configuration .................................................................................................................. 659
Configuring Static Mappings ..................................................................................................... 659
Configuring Full-Cone Support .................................................................................................. 659
Configuring External Logging for LSN Traffic Logs ................................................................... 660
Configure the IP Selection Method ............................................................................................ 662
Configuring the LSN SYN Timeout ............................................................................................ 663
Displaying LSN Information............................................................................................................... 663
Clearing LSN Statistics and Sessions .......................................................................................... 664
Configuration Example ...................................................................................................................... 664
Management Security Features
669
Configuring Additional Admin Accounts ......................................................................................... 669

Configuring an Admin Account ..................................................................................................... 670
Deleting an Admin Account .......................................................................................................... 674
Configuring Admin Lockout .............................................................................................................. 675
Securing Admin Access by Ethernet................................................................................................ 677
Displaying the Current Management Access Settings .................................................................. 680
Regaining Access if You Accidentally Block All Access ............................................................... 681
Changing Web Access Settings........................................................................................................ 681
Configuring AAA for Admin Access ................................................................................................. 683
Authentication ............................................................................................................................... 684
Authentication Process .............................................................................................................. 684
Authorization for GUI Access ........................................................................................................ 688
Authorization for CLI Access ........................................................................................................ 688
RADIUS CLI Authorization ........................................................................................................ 688
TACACS+ CLI Authorization ..................................................................................................... 689
Accounting .................................................................................................................................... 690
Command Accounting (TACACS+ only) ................................................................................... 691
TACACS+ Accounting Debug Options ...................................................................................... 691
Configuring AAA for Admin Access .............................................................................................. 691
Configuring Authentication ........................................................................................................ 692
Configuring Authorization .......................................................................................................... 693
Configuring Accounting ............................................................................................................. 694
Configuring Windows IAS for AX RADIUS Authentication ............................................................ 698
Procedure Overview .................................................................................................................. 698
Configure Access Groups ......................................................................................................... 699
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
19 of 950

Contents
Configure RADIUS Client for AX Device ................................................................................... 700

Configure Remote Access Policies ........................................................................................... 702
Add AD Users to AX Access Groups ........................................................................................ 712
Register the IAS Server in Active Directory .............................................................................. 713
Configure RADIUS in the AX Device ........................................................................................ 714
Test the Configuration ............................................................................................................... 714
Traffic Security Features
715
DDoS Protection..................................................................................................................................715
Enabling DDoS Protection ............................................................................................................ 717
Configuring IP Anomaly Filters for System-Wide PBSLB ............................................................. 717
Displaying and Clearing IP Anomaly Statistics ............................................................................. 718
SYN Cookies ........................................................................................................................................718
The Service Provided By SYN Cookies ....................................................................................... 719
Enabling Hardware-Based SYN Cookies ..................................................................................... 720
Configuration when Target VIP and Client-side Router Are in Different Subnets ..................... 721
Enabling Software-Based SYN Cookies ...................................................................................... 722
Configuring Layer 2/3 SYN Cookie Support ................................................................................. 723
ICMP Rate Limiting..............................................................................................................................724
Source-IP Based Connection Rate Limiting .....................................................................................726
Parameters ................................................................................................................................... 727
Log Messages .............................................................................................................................. 727
Deployment Considerations ......................................................................................................... 728
Configuration ............................................................................................................................. 729
Configuration Examples ............................................................................................................... 730
DNS Security........................................................................................................................................731
Access Control Lists (ACLs)..............................................................................................................733
How ACLs Are Used .................................................................................................................... 733
Configuring Standard IPv4 ACLs ................................................................................................. 734
Configuring Extended IPv4 ACLs ................................................................................................. 736
Configuring Extended IPv6 ACLs ................................................................................................. 740
Adding a Remark to an ACL ......................................................................................................... 743
Transparent Session Logging ...................................................................................................... 744
Sample Log Messages for Transparent Sessions .................................................................... 744
Configuration ............................................................................................................................. 745
Applying an ACL to an Interface ................................................................................................... 746
Applying an ACL to a Virtual Server Port ..................................................................................... 747
Using an ACL to Control Management Access ............................................................................ 748
Using an ACL for NAT .................................................................................................................. 748
Resequencing ACL Rules ............................................................................................................ 748
20 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
Policy-Based SLB (PBSLB) ............................................................................................................... 751

Configuring a Black/White List ...................................................................................................... 751
Dynamic Black/White-list Client Entries .................................................................................... 752
Configuring System-Wide PBSLB ................................................................................................ 754
Configuring PBSLB for Individual Virtual Ports ............................................................................. 756
Displaying PBSLB Information .................................................................................................. 764
Configuration ExampleSockstress Attack Protection ................................................................ 766
Geo-location-based Access Control for VIPs .................................................................................. 768
Configuration ............................................................................................................................. 769
Enabling PBSLB Statistics Counter Sharing ............................................................................. 774
Enabling Full-Domain Checking for Connection Limits ............................................................. 775
IP Limiting
777
Overview.............................................................................................................................................. 777
Class Lists .................................................................................................................................... 777
Class List Syntax ....................................................................................................................... 778
IP Address Matching ................................................................................................................. 778
Example Class Lists .................................................................................................................. 779
IP Limiting Rules ........................................................................................................................... 779
Match IP Address ...................................................................................................................... 780
Configuring Source IP Limiting......................................................................................................... 781
Configuring a Class List ................................................................................................................ 781
Configuring the IP Limiting Rules ................................................................................................. 785
Applying Source IP Limits ............................................................................................................. 788
Displaying IP Limiting Information ................................................................................................ 790
CLI ExamplesConfiguration ...................................................................................................... 791
Configure System-Wide IP Limiting With a Single Class .......................................................... 791
Configure System-Wide IP Limiting With Multiple Classes ....................................................... 791
Configure IP Limiting on a Virtual Server .................................................................................. 792
Configure IP Limiting on a Virtual Port ...................................................................................... 793
CLI ExamplesDisplay ................................................................................................................ 793
Class Lists ................................................................................................................................. 793
IP Limiting Rules ....................................................................................................................... 795
IP Limiting Statistics .................................................................................................................. 796
Role-Based Administration
797
Overview.............................................................................................................................................. 798
Resource Partitions ...................................................................................................................... 799
Administrator Roles ...................................................................................................................... 801
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
21 of 950

Contents
Configuring Role-Based Administration...........................................................................................803

Configuring Private Partitions ....................................................................................................... 803
Changing the Maximum Number of aFleX Policies Allowed in a Partition ................................ 804
Migrating Resources Between Partitions .................................................................................. 805
Deleting a Partition .................................................................................................................... 805
Configuring Partition Admin Accounts .......................................................................................... 806
CLI Example ................................................................................................................................. 808
Viewing and Saving the Configuration..............................................................................................809
Viewing the Configuration ............................................................................................................ 809
Saving the Configuration .............................................................................................................. 810
Switching To Another Partition..........................................................................................................811
Synchronizing the Configuration.......................................................................................................812
Operator Management of Real Servers .............................................................................................814
SLB Parameters
819
Service Template Parameters ............................................................................................................819

Cache Template Parameters ....................................................................................................... 821
Client SSL Template Parameters ................................................................................................. 823
Connection Reuse Template Parameters .................................................................................... 826
Cookie Persistence Template Parameters ................................................................................... 827
Destination-IP Persistence Template Parameters ....................................................................... 829
DNS Template Parameters .......................................................................................................... 832
HTTP Template Parameters ........................................................................................................ 832
Policy Template Parameters ........................................................................................................ 839
Server SSL Template Parameters ............................................................................................... 843
SIP Template Parameters (SIP over TCP/TLS) ........................................................................... 844
SIP Template Parameters (SIP over UDP) .................................................................................. 847
SMTP Template Parameters ........................................................................................................ 848
Source-IP Persistence Template Parameters .............................................................................. 850
SSL Session-ID Persistence Template Parameters ..................................................................... 853
Streaming-Media Template Parameters ...................................................................................... 854
TCP Template Parameters ........................................................................................................... 854
TCP-Proxy Template Parameters ................................................................................................ 855
UDP Template Parameters .......................................................................................................... 857
Global SLB Parameters ......................................................................................................................858
Real Server Parameters ......................................................................................................................865
Real Service Port Parameters ............................................................................................................868
Service Group Parameters .................................................................................................................870
22 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Contents
Virtual Server Parameters.................................................................................................................. 874

Virtual Service Port Parameters ........................................................................................................ 877
Dynamic Real Server Creation Using DNS
885
Template Options for Dynamically Created Real Servers............................................................... 886

Configuring Dynamic Real Server Creation ..................................................................................... 888
VIP Creation Based on Subnet
893
Sending a Reset After Server Selection Failure
895
Scan-All-Members Option in Persistence Templates
901
SSL Certificate Management
905
Overview.............................................................................................................................................. 905
SSL Process ................................................................................................................................. 905
Certificate Chain ........................................................................................................................ 907
Certificate Warning from Client Browser ................................................................................... 908
CA-Signed and Self-Signed Certificates ................................................................................... 909
SSL Templates .......................................................................................................................... 910
Certificate Installation Process ..................................................................................................... 912
Requesting and Installing a CA-Signed Certificate ................................................................... 912
Installing a Self-Signed Certificate ............................................................................................ 914
Generating a Key and CSR for a CA-Signed Certificate ................................................................. 915
Importing a Certificate and Key......................................................................................................... 918
Generating a Self-Signed Certificate ................................................................................................ 920
Importing a CRL.................................................................................................................................. 922
Exporting Certificates, Keys, and CRLs ........................................................................................... 923
Exporting a Certificate and Key .................................................................................................... 923
Exporting a CRL ........................................................................................................................... 924
Creating a Client-SSL or Server-SSL Template and Binding it to a VIP ........................................ 925
Creating an SSL Template ........................................................................................................... 925
Binding an SSL Template to a VIP ............................................................................................... 926
Converting Certificates and CRLs to PEM Format .......................................................................... 926
Converting SSL Certificates to PEM Format ................................................................................ 927
Converting CRLs from DER to PEM Format ................................................................................ 928
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
23 of 950

Contents
Using the Management Interface as the Source for Management Traffic
929
Route Tables ........................................................................................................................................929

Management Routing Options ...........................................................................................................930
Enabling Use of the Management Interface as the Source for Automated Management
Traffic ........................................................................................................................................... 931
Using the Management Interface as the Source Interface for Manually Generated
Management Traffic ..................................................................................................................... 932
Commands at the User EXEC Level ......................................................................................... 932
Commands at the Privileged EXEC Level ................................................................................. 932
Commands at the Global Configuration Level .......................................................................... 932
Show Commands ...................................................................................................................... 933
Configuration Management
935
Backing Up System Information ........................................................................................................935

Saving Multiple Configuration Files Locally.....................................................................................937
Configuration Profiles ................................................................................................................... 938
Commands for Local Configuration Management ........................................................................ 938
VLAN-to-VLAN Bridging
945
Configuring VLAN-to-VLAN Bridging ........................................................................................ 946
24 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX Series Features
System Overview
This chapter provides a brief overview of the AX Series system and features. For more information, see the other chapters in this guide.
AX Series Features
Key features of the AX Series include:
Application Delivery Features
Comprehensive IPv4/IPv6 Support
Transparent (Layer 2) and gateway (Layer 3) mode support for
easy deployment into existing infrastructures

Network Address Translation (NAT) IPv4-IPv4, IPv4-IPv6,
IPv6-IPv4, IPv6-IPv6, ALG support for PPTP, Large-Scale NAT
(LSN)
IPv4 RIP, OSPFv2 for IPv4, OSPFv3 for IPv6
IPv4/IPv6 static routes
DHCP relay
Advanced Layer 4/7 Server Load Balancing
Fast TCP, fast UDP, fast HTTP, and full HTTP Proxy
Comprehensive protocol support: HTTP, HTTPS, FTP, TCP,
UDP, SSL, SIP, SMTP, and others
Comprehensive load-balancing methods weight-based, connection-based, request-based, and response-based methods, as
well as simple round robin
Protocol translation support for mixed IPv4/IPv6 environments
Advanced health monitoring
Customizable configuration templates
RAM caching of web content
Firewall Load Balancing (FWLB)
Global Server Load Balancing (GSLB)
Transparent Cache Switching (TCS)
High Availability (HA)

Active-Active, Active-Standby, and Layer 2/3 inline mode configu-
rations with sub-second failover

Layer 4 session synchronization
Configuration synchronization
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
25 of 950

AX Series Features
Acceleration and Security
SSL acceleration and offload
Traffic security
Management access security Local admin database and support
for optional remote RADIUS or TACACS+ AAA

Spam filter support (Policy-Based SLB) High-speed application
of very large black/white lists that filter based on source or destination IP host or subnet address
DoS attack detection and prevention
Access Control Lists (ACLs)
DNS Application Firewall Solution consisting of the following:
Traffic validation Drop or redirect malformed DNS queries
Dynamic traffic flow regulation:
High performance surge protection (connection and rate limit-
ing)
Source-IP based connection rate limiting
Policy-Based SLB (black/white lists)
aFleX Tcl-like Scripting Language
XML Application Programming Interface (aXAPI)
System Management
Dedicated management interface
Multiple access methods SSH, Telnet, HTTPS
Web-based Graphical User Interface (GUI) with language localiza
tion
Industry-standard Command Line Interface (CLI) support
On-demand backup of configuration files, logs, and system files
SNMP, syslog, alerting
Virtualized Management, provided by Role-Based Administration
(RBA)
Troubleshooting tools
Port mirroring
Debug subsystem for packet capture
26 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

ACOS Architecture
ACOS Architecture
AX Series devices use embedded Advanced Core Operating System
(ACOS) architecture. ACOS is built on top of a set of Symmetric Multi-Processing CPUs and uses shared memory architecture to maximize application
data delivery.
ACOS is designed to handle high-volume application data with integrated
Layer 2 / Layer 3 processing and integrated SSL acceleration built into the
system. In addition, ACOS incorporates the A10 Networks customizable
aFleX scripting language, which provides administrators with configuration
flexibility for application data redirection.
ACOS inspects packets at Layers 2, 3, 4, and 7 and uses hardware-assisted
forwarding. Packets are processed and forwarded based on ACOS configuration.
You can deploy the AX device into your network in transparent mode or
gateway (route) mode.
Transparent mode The AX device has a single IP interface. For multi-
netted environments, you can configure multiple Virtual LANs

(VLANs).
Route mode Each AX interface is in a separate IP subnet. Open Short-
est Path First (OSPF) and Routing Information Protocol (RIP) are supported.
In either type of deployment, ACOS performs Layer 4-7 switching based on
the SLB configuration settings.
AX Software Processes
The AX software performs its many tasks using the following processes:
a10mon Parent process of the AX device. This process is executed
when the system comes up. The a10mon process is responsible for the
following:
Responsible for bringing AX user-space processes up and down
Monitors all its child processes and restarts a process and all dependent processes if any of them die.
syslogd System logger daemon that logs kernel and system events.
a10logd Fetches all the logs from the AX Log database.
a10timer Schedules and executes scheduled tasks.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
27 of 950

ACOS Architecture
a10stat Monitors the status of all the main processes of the AX device,
such as a10switch (on models AX2200 and higher) and a10lb.

The a10stat process probes every thread within these processes to ensure
that they are responsive. If a thread is deemed unhealthy, a10stat kills
the process, after which a10mon restarts the process and other processes
associated with it.
a10switch Contains libraries and APIs to program the Switching ASIC
to perform Layer 2 and Layer 3 switching at wire speed.

a10hm Performs health-checking for real servers and services. This
process sends pre-configured requests to external servers at pre-defined

intervals. If a server or individual service does not respond, it is marked
down. Once the server or service starts responding again, it is marked
up.
a10rt Routing daemon, which maintains the routing table with routes
injected from OSPF and RIP routing protocols, as well as static routes.
a10rip Implements RIPv1 and v2 routing protocols.
a10ospf Implements the OSPFv2 routing protocol.
a10snmpd SNMPv2c and v3 agent, which services MIB requests.
a10wa Embedded Web Server residing on the AX device. This process
serves the Web-based management Graphical User Interface (GUI).

a10gmpd Global SLB (GSLB) daemon.
a10snpm_trapd Handles SNMP traps initiated by a10lb.
a10lb The heart of the AX device. This process contains all the intelli-
gence to perform Server Load Balancing.

rimacli This process is automatically invoked when an admin logs into
the AX device through an interface address. The admin is presented a

Command Line Interface (CLI) that can issue and save commands to
configure the system.
28 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

ACOS Architecture
Local File Storage

Every AX model includes one of the following types of local file storage
device:
Solid State Drive (SSD) Used in 64-bit ACOS models: AX 2500,
AX 2600, AX 3000, AX 5100 and AX 5200

Hard disk Used in 32-bit ACOS models: AX 1000, AX 2000,
AX 2100, AX 2200, AX 3100, and AX 3200

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

certificate and key files, black/white list files, class-list files, log messages,
CLI audit log messages, core dump files, show techsupport files (up to 30days worth), and other miscellaneous files. The size of all application files
varies depending on the configuration of the system and other factors. The
show techsupport files use no more than 3-4 G. aFleX scripts range from
0-500 KB.
Monitoring data includes objects for CPU, disk, memory, global statistics,
port statistics, and 30-day SLB statistics. The 30-day SLB statistics include
objects for real servers, virtual servers, real ports, virtual ports, server
groups, service groups, and service-group members.
The 30-day SLB statistics use the most storage among the monitoring
objects. For the maximum configuration, the 30-day SLB statistics can use
the following amounts of storage on 64-bit ACOS models:
AX 2500, AX 2600 3 G or less
AX 3000 9 G or less
AX 5100, AX 5200 26 G or less
If there is a storage shortage, the software dynamically adjusts the maximum number of SLB monitoring objects to prevent consumption of the
remaining storage.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
29 of 950

Hardware Interfaces
Hardware Interfaces
1000BaseT (GOC) + SFP Mini GBIC Fiber Ports
On models AX 3100, AX 3200, AX 5100, and AX 5200, 10G XFP-SR
(short range) single-mode fiber port or XFP-LR (long range) multimode fiber port, depending on order
Management Ethernet Port
RJ-45 Console Port
Generally, the fiber ports do not require any configuration other than IP
interface(s). When you plug in a port, the port speed and mode (full-duplex
or half-duplex) are automatically negotiated with the other end of the link.
The management Ethernet port allows an out-of-band IP connection to the
switch for management. The management interface traffic is isolated from
the traffic on the other Ethernet ports.
The serial console port is for direct connection of a laptop PC to the AX
device.
Software Interfaces
Graphical User Interface (GUI)
Command Line Interface (CLI) accessible using console, Telnet, or
Secure Shell (v1 and v2)

Simple Network Management Protocol (SNMP) v1, v2c, and v3
XML Application Programming Interface (aXAPI)
The configuration examples in this manual show how to configure the
AX Series using the CLI and GUI. For more information about the AX
management interfaces, see the following documents:
AX Series GUI Reference
AX Series CLI Reference
AX Series MIB Reference
AX Series aXAPI Reference
30 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Server Load Balancing

Server Load Balancing (SLB) is a suite of resource management features
that make server farms more reliable and efficient.
You can easily grow server farms in response to changing traffic flow, while
protecting the servers behind a common virtual IP address. From the perspective of a client who accesses services, requests go to and arrive from a
single IP address. The client is unaware that the server is in fact multiple
servers managed by an AX device. The client simply receives faster, more
reliable service.
Moreover, you do not need to wait for DNS entries to propagate for new
servers. To add a new server, you simply add it to the AX configuration for
the virtual server, and the new real server becomes accessible immediately.
FIGURE 2
b y
SLB Example
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
31 of 950

Intelligent Server Selection

The services managed by the AX device are controlled by service groups. A
service group is a set of real servers. The AX device selects a real server for
a clients request based on a set of tunable criteria including server health,
server response time, and server load. These criteria can be tuned for individual servers and even individual service ports.
The AX device provides a robust set of configurable health monitors for
checking the health (availability) of servers and individual services. For
more information, see Health Monitoring on page 373.
Configuration Templates
SLB configuration is simplified by the use of templates. Templates simplify
configuration by enabling you to configure common settings once and use
them in multiple service configurations. The AX device provides templates
to control server and port configuration parameters, connectivity parameters, and application parameters.
The AX device provides the following types of server and port configuration templates:
Server Controls parameters for real servers
Port Controls parameters for service ports on real servers
Virtual server Controls parameters for virtual servers
Virtual port Controls parameters for service ports on virtual servers
The AX device provides the following types of connectivity templates:

TCP-Proxy Controls TCP/IP stack parameters
TCP Controls the idle timeout for unused sessions and specifies
whether the AX device sends TCP Resets to clients or servers after a

session times out
UDP Controls the idle timeout for unused sessions and specifies how
quickly sessions are terminated after a server response is received

The following types of application templates are provided:
HTTP Provides a robust set of options for HTTP header manipulation
and for load balancing based on HTTP header content or the URL
requested by the client, and other options
32 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Policy Uses Policy-based SLB (PBSLB) to permit or deny clients, or
direct them to service groups, based on client black/white lists

Cache Caches web content on the AX device to enhance website per-
formance for clients

Client SSL Offloads SSL validation tasks from real servers
Server SSL Validates real servers on behalf of clients
Connection reuse Reduces overhead from TCP connection setup by
establishing and reusing TCP connections with real servers for multiple
client requests
Cookie persistence Inserts a cookie into server replies to clients, to
direct clients to the same service group, real server, or real service port
for subsequent requests for the service
Source-IP persistence Directs a given client, identified by its IP
address, to the same service port, server, or service group

Destination-IP persistence Configures persistence to real servers based
on destination IP address
SSL session-ID persistence Directs all client requests for a given vir-
tual port, and that have a given SSL session ID, to the same real server
and real port
SIP Customizes settings for load balancing of Session Initiation Proto-
col (SIP) traffic

SMTP Configures STARTTLS support for Simple Mail Transfer Pro-
tocol (SMTP) clients

Streaming-media Directs client requests based on the requested con-
tent
Where applicable, the AX device automatically applies a default template
with commonly used settings. For example, when you configure SLB for
FTP, the AX device automatically applies the default TCP template. If
required by your application, you can configure a different template and
apply that one instead. The configuration examples in this guide show how
to do this.
See the following chapters for examples of SLB configurations:
HTTP Load Balancing on page 109
FTP Load Balancing on page 163
SIP Load Balancing on page 183
SSL Offload and SSL Proxy on page 219
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
33 of 950

STARTTLS for Secure SMTP on page 239
Streaming-Media Load Balancing on page 249
Layer 4 TCP/UDP Load Balancing on page 255
For descriptions of all the parameters you can control using templates, see
Server and Port Templates on page 353 and Service Template Parameters on page 819.

Global Server Load Balancing (GSLB) allows you to manage multiple SLB
sites and direct clients to the best site. Site selection is based on metrics
including the sites health and the sites geographic proximity to the client.
For more information, see Global Server Load Balancing on page 427.

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

Transparent Cache Switching (TCS) enables you to improve server
response times by redirecting client requests for content to cache servers
containing the content. For more information, see Transparent Cache
Switching on page 295.

Firewall Load Balancing (FWLB) maximizes throughput through firewall
bottlenecks by load balancing server-client sessions across the firewalls. For
more information, see Firewall Load Balancing on page 327.
34 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Where Do I Start?
Where Do I Start?
To configure basic system settings, see Basic Setup on page 37.
To configure network settings, see Network Setup on page 71 and
Routing Parameters on page 835.

To configure traffic management features (SLB, GSLB, LLB, TCS, and
FWLB), see the remaining chapters in this guide.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
35 of 950

Where Do I Start?
36 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Logging On
Basic Setup
This chapter describes how to log onto the AX device and how to configure
the following basic system parameters:
Hostname and other Domain Name Server (DNS) settings
CLI banner messages
Date/time settings
System log (Syslog) settings
Simple Network Management Protocol (SNMP) settings
After you are through with this chapter, go to Network Setup on page 71.
Note:
The only basic parameters that you are required to configure are date/time
settings. Configuring the other parameters is optional.
Note:
This chapter does not describe how to access the out-of-band management interface. For that information, see the AX Series Advanced Traffic
Manager Installation Guide.
Caution:
When you make configuration changes, be sure to remember to save

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

values to configure or manage the device. You can access the GUI using
either of the following protocols:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
37 of 950

Logging On
Secure protocol Hypertext Transfer Protocol over Secure Socket
Layer (HTTPS)
Unsecure protocol Hypertext Transfer Protocol (HTTP)
Note:
By default, Telnet access is disabled on all interfaces, including the management interface. SSH, HTTP, HTTPS, and SNMP access are enabled by
default on the management interface only, and disabled by default on all
data interfaces.
Federal Information Processing Standards (FIPS) Compliance
To comply with FIPS security standards, beginning in AX Release 2.4.2,
management access to the AX device has the following requirements:
Web access to GUI The browser used to access the AX GUI must sup-
port encryption keys of 128 bits or longer. Shorter encryption keys (for
example, 40 bits) are not supported. The browser also must support
SSLv3 or TLS 1.0. Browsers that support only SSLv2 are not supported.
SSH access to CLI The SSH client used to access the CLI must sup-
port SSHV2. SSHv1 is not supported. The SSHv2 client must support
one of the following encryption ciphers:
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
Other ciphers are not supported.
Logging Onto the CLI

Note:
The AX Series provides advanced features for securing management

access to the device. This section assumes that only the basic security settings are in place. (For more information about securing management
access, see Management Security Features on page 669.)
To log onto the CLI using SSH:
1. On a PC connected to a network that can access the AX devices management interface, open an SSH connection to the IP address of the
management interface.
2. Generally, if this the first time the SSH client has accessed the AX
device, the SSH client displays a security warning. Read the warning
carefully, then acknowledge the warning to complete the connection.
(Press Enter.)
38 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

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

Platform
Browser
IE 7.0, 6.0
Firefox 3.x, 2.x
Safari 3.0
Chrome
Windows
Supported
Linux
N/A
Supported
Not Supported
Not Supported
Supported
N/A
N/A
MAC
N/A
N/A
Supported
N/A
A screen resolution of at least 1024x768 is recommended.

1. Open one of the Web browsers listed in Table 1.
2. In the URL field, enter the IP address of the AX devices management
interface.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
39 of 950

Logging On
3. If the browser displays a certificate warning, select the option to continue to the server (the AX device).
A login dialog is displayed. The name and appearance of the dialog
depends on the browser you are using.
FIGURE 3
GUI Login Dialog (Internet Explorer)
4. Enter your admin username and password and click OK.

Note:
The default admin username and password are admin, a10.

The Summary page appears, showing at-a-glance information for your
AX device.
You can access this page again at any time while using the GUI, by
selecting Monitor > Overview > Summary.
40 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring Basic System Parameters
FIGURE 4
Monitor > Overview > Summary
For more information about the GUI, see the AX Series GUI Reference or
the GUI online help.
Note:

This section describes the basic system parameters and provides CLI and
GUI steps for configuring them.
Note:
b y
If you plan to use the GUI, the Basic System page under Config Mode
also provides configuration access to most of the system parameters
described in this chapter. For information, navigate to Config Mode >
Basic System, then click Help.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
41 of 950

Setting the Hostname and Other DNS Parameters

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

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

1. Access the global configuration level of the CLI:
AX>enable
Password:enable-password
AX#config
AX(config)#
2. Use the following command to change the hostname:
hostname string
After you enter this command, the command prompt should change to
the same value as the new hostname.
Note:
The > or # character and characters in parentheses before # indicate the CLI level you are on and are not part of the hostname.
3. To set the default domain name (DNS suffix) for hostnames on the AX
device, use the following command:
ip dns suffix string
42 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

4. To specify the DNS servers the AX should use for resolving DNS
requests, use the following command:
ip dns {primary | secondary} ipaddr
The primary option specifies the DNS server the AX device should
always try to use first. The secondary option specifies the DNS server
that the AX device should use if the primary DNS server is unavailable.
Setting the CLI Banners

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

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

1. Select Config > System > Settings.
2. On the menu bar, select Terminal > Banner.
3. To configure a banner:
a. Select the banner type, single-line or multi-line.
b. If you selected multi-line, enter the delimiter value in the End
Marker field.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
43 of 950

c. Enter the message in the Login Banner or Exec Banner field.
If the message is a multi-line message, press Enter / Return at the
end of every line. Do not type the end marker at the end of the message. The GUI automatically places the end marker at the end of the
message text in the configuration.
4. If you are configuring both messages, repeat step 3 for the other message.
5. Click OK.
USING THE CLI

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

To configure time/date parameters:
Set the timezone.
Set the system time and date manually or configure the AX device to use
a Network Time Protocol (NTP) server.

The default timezone is Europe/Dublin, which is equivalent to Greenwich
Mean Time (GMT). The time and date are not set at the factory, so must
manually set them or configure NTP.
Note:
44 of 950
You do not need to configure Daylight Savings Time. The AX device

automatically adjusts the time for Daylight Savings Time based on the
timezone you select.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

1. Select Config > System > Time. The Date/Time page appears.
To set the time and date by synchronizing them with the time and
date on the PC from which you are running the GUI, click Sync
Local Time.
To configure the time and date manually:
a. Enter the date in the Date field or select the date using the calendar.
b. Enter the time in the Time field.
To set the time and date using NTP:
a. Select the Automatically Synchronize with Internet Time Server
checkbox.
b. In the NTP Server field, enter the NTP servers IP address.
c. In the Update System Clock Every field, enter the number of minutes you want the AX device to wait between synchronizations with
the NTP server.
2. To select the timezone:
a. Click Time Zone.
b. From the Time Zone Name pull-down list, select the time zone.
c. Click OK.
d. Click Date/Time to re-display the section, if not already displayed.
3. Click OK.
USING THE CLI

To set the timezone
Enter the following command at the global configuration level of the CLI:
clock timezone timezone [nodst]
The nodst option disables Daylight Savings Time (DST) for the zone. DST
is enabled by default, if applicable to the timezone.
To view the available timezones, enter the following command:
clock timezone ?
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
45 of 950

To configure the AX device to use NTP
1. To specify the NTP server to use, enter the following command at the
global configuration level of the CLI:
ntp server {hostname | ipaddr} [minutes]
The minutes option sets the synchronization interval, which specifies
how often the AX polls the NTP server for updated time information.
You can specify 1-518400 minutes. The default is 1440 minutes.
You can configure a maximum of 4 NTP servers.
2. To enable NTP and synchronize the AX clock with the NTP server,
enter the following command:
ntp enable
To set the time and date manually
1. Return to the Privileged EXEC level of the CLI by entering the exit
command.
2. Enter the following command at the Privileged EXEC level of the CLI:
clock set time day month year
Enter the time and date in the following format:
time hh:mm:ss
day 1-31
month January, February, March, ...
year 2008, 2009 ...
Note:
The clock is based on 24 hours. For example, for 1 p.m., enter the hour as
13.
3. To display clock settings, use the following command:
show clock [detail]
Configuring Syslog Settings

The AX device logs system events with Syslog messages. The AX device
can send Syslog messages to the following places:
Local buffer
Console CLI session
Console SSH and Telnet sessions
46 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

External Syslog server
Email address(es)
SNMP servers (for events that are logged by SNMP traps)
Logging to the local buffer and to CLI sessions is enabled by default. Logging to other places requires additional configuration. The standard Syslog
message severity levels are supported:
Emergency 0
Alert 1
Critical 2
Error 3
Warning 4
Notification 5
Information 6
Debugging 7
Table 2 lists the configurable Syslog parameters.

TABLE 2
Configurable System Log Settings
Parameter
Disposition
(message target)
Description
Output options for each message level. For each message level, you can select which of the following output options to enable:
Supported Values
The following message levels can be
individually selected for each output
option:
Console Messages are displayed in Console sessions.
Emergency (0)
Buffered Messages are stored in the system log

buffer.
Critical (2)
Email Messages are sent to the email addresses

in the Email To list. (See below.)
Warning (4)
SNMP SNMP traps are generated and sent to the

SNMP receivers.
Alert (1)
Error (3)
Notification (5)
Information (6)
Syslog Messages are sent to the external log

servers specified in the Log Server fields. (See
below.)
Debug (7)
Monitor Messages are displayed in Telnet and

SSH sessions.
Only Emergency, Alert, Critical, and

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

can be selected for SNMP.
Note: For information about emailing log messages,

see Emailing Log Messages on page 64.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
47 of 950

TABLE 2
Configurable System Log Settings (Continued)
Parameter
Facility
Description
Standard Syslog facility to use.
Log Buffer
Entries
Maximum number of log entries the log buffer can

store.
Log Server
IP addresses or fully-qualified domain names of

external log servers.
Only the message levels for which Syslog is selected
in the Disposition list are sent to log servers.
Log Server Port

Email To
Note: By default, the AX device can reach remote

log servers only if they are reachable through the AX
devices data ports, not the management port. To
enable the AX device to reach remote log servers
through the management port, see Using the Management Interface as the Source for Management
Traffic on page 929.
Protocol port to which log messages sent to external
log servers are addressed.
Email addresses to which to send log messages.
Only the message levels for which Email is selected
in the Disposition list are sent to log servers.
SMTP Server
SMTP Server
Port
IP address or fully-qualified domain name of an

email server using Simple Message Transfer Protocol.
Note: By default, the AX device can reach SMTP
servers only if they are reachable through the AX
devices data ports, not the management port. To
enable the AX device to reach SMTP servers through
the management port, see Using the Management
Interface as the Source for Management Traffic on
page 929.
Protocol port to which email messages sent to the
SMTP server are addressed.
Supported Values
Standard Syslog facilities listed in
RFC 3164.
10000 to 50000 entries
Default: 30000
Any valid IP address or fully-qualified domain name.
Default: None configured
Any valid protocol port number

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

Default: 25
Log Rate Limiting

The AX device uses a log rate limiting mechanism to ensure against overflow of external log servers and the internal logging buffer.
The rate limit for external logging is 15,000 messages per second from the
AX device.
48 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The rate limit for internal logging is 32 messages per second from the AX
device.
If the number of new messages within a one-second interval exceeds 32,
then during the next one-second interval, the AX sends log messages
only to the external log servers.
If the number of new messages generated within the new one-second
interval is 32 or less, then during the following one-second interval, the

AX will again send messages to the local logging buffer as well as the
external log server. In any case, all messages (up to 15,000 per second)
get sent to the external log servers.
USING THE GUI

2. Select Log on the menu bar.
3. Change settings as needed. (For descriptions of the settings, see
Table 2.)
4. Click OK.
USING THE CLI

1. To change the severity level of messages that are logged in the local
buffer, use the following command:
logging buffered severity-level
2. To change the severity level of messages that are logged in other places,
use the following command:
logging target severity-level
The target can be one of the following:
console Serial console
email Email
monitor Telnet and SSH sessions
syslog external Syslog host
trap external SNMP trap host
Note:
b y
Only severity levels emergency, alert, critical, and notification can be

sent by email. Sending log messages by email requires additional configuration. See Emailing Log Messages on page 64.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
49 of 950

3. To configure the AX device to send log messages to an external Syslog
server, use the following command to specify the server:
logging host ipaddr [ipaddr...]
[port protocol-port]
You can enter more than one server IP address on the same command
line. The default protocol port is 514. You can specify only one protocol
port with the command. All servers must use the same protocol port to
listen for syslog messages.
If you use the command to add some log servers, then need to add a new
log server later, you must enter all server IP addresses in the new command. Each time you enter the logging host command, it replaces any
set of servers and syslog port configured by the previous logging host
command.
4. To configure the AX device to send log messages by email, use the following commands to specify the email server and the email addresses:
smtp {hostname | ipaddr} [port protocol-port]
The port option specifies the protocol port to which to send email. The
default is 25.
logging email-address address [...]
To enter more than one address, use a space between each address.
5. To send event messages to an external SNMP server, see Enabling
SNMP on page 50.
Enabling SNMP
AX devices support the following SNMP versions: v1, v2c, v3. SNMP is
disabled by default.
You can configure the AX device to send SNMP traps to the Syslog and to
external trap receivers. You also can configure read (GET) access to SNMP
Management Information Base (MIB) objects on the AX device by external
SNMP managers.
Note:
SNMP access to the AX device is read-only. SET operations (write

access) are not supported.
The AX device supports the following SNMP-related RFCs:
RFC 1157, A Simple Network Management Protocol (SNMP)
RFC 1901, Introduction to Community-based SNMPv2
RFC 2233, The Interfaces Group MIB using SMIv2
50 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework

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

RFC 3411, An Architecture for Describing Simple Network Manage-
ment Protocol (SNMP) Management Frameworks

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

RFC 3413, Simple Network Management Protocol (SNMP) Applica-
tions
RFC 3414, User-based Security Model (USM) for version 3 of the Sim-
ple Network Management Protocol (SNMPv3)

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

RFC 3635, Definitions of Managed Objects for the Ethernet-like Inter-
face Types
SNMP Traps
Table 3 lists the SNMP traps supported by the AX device. All traps are disabled by default.
TABLE 3
AX SNMP Traps
Trap Category
SNMP
Trap
Link Up
Link Down
b y
Description
Indicates that an Ethernet interface has come up.
Indicates that an Ethernet interface has gone down.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
51 of 950

TABLE 3
AX SNMP Traps (Continued)
Trap Category
System
Trap
Start
Shutdown
Restart
Control CPU utilization
Description
Indicates that the AX device has started.
Indicates that the AX device has shut down.
Indicates that the AX device is going to reboot or reload.
Indicates that the control CPU utilization is higher than
90%.*
Data CPU utilization
Indicates that data CPU utilization is higher than 90%.*

Indicates that the temperature inside the AX chassis is too
high (68 C or higher).*
High Temperature
If you see this trap, check for fan failure traps. Also check
the installation location to ensure that the chassis room temperature is not too high (40 C or higher) and that the chassis
is receiving adequate air flow.
Indicates that a system fan has failed. Contact A10 Networks.
Indicates that a power supply has failed. Contact A10 Networks.
Indicates that the primary Hard Disk has failed or the RAID
system has failed. Contact A10 Networks. In dual-disk models, the primary Hard Disk is the one on the left, as you are
facing the front of the AX chassis.
Indicates that the secondary Hard Disk has failed or the
RAID system has failed. Contact A10 Networks. The secondary Hard Disk is the one on the right, as you are facing
the front of the AX chassis.
Fan Failure
Power Supply Failure
Primary Hard Disk
Secondary Hard Disk
High Disk Usage

High Memory Usage
Packet Buffer drop
Network
Trunk Ports Threshold
Active
Standby
Active-Active
52 of 950
Note: This trap does not apply to the following models:

AX 2500, AX 2600, AX 3000, AX 5100, or AX 5200.
Indicates that hard disk usage on the AX device is high
(85% or higher).*
Indicates that the memory usage on the AX device is high
(95% or higher).*
Indicates that the AX device is dropping too many packets
(100 or more during a 10-second interval).*
Indicates that the trunk ports threshold feature has disabled
trunk members because the number of up ports in the trunk
has fallen below the configured threshold.
Indicates that the AX device is going from HA Standby
mode to Active mode.
Indicates that the AX device is going from HA Active mode
to Standby mode.
Indicates that an Active-Active HA configuration has been
enabled.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 3
AX SNMP Traps (Continued)
Trap Category
(SLB)
Trap
Server Up
Server Down
Service Up
Service Down
Server Connection
Limit
Server Connection
Resume
Service Connection
Limit
Service Connection
Resume
Virtual Server
Connection Limit
Virtual Port
Connection Limit
Virtual Server
Connection-Rate Limit
Virtual Port
Connection-Rate Limit
Virtual Port Up
Virtual Port Down

Application Buffer
Threshold
Description
Indicates that an SLB server has come up.
Indicates that an SLB server has gone down.
Indicates that an SLB service has come up.
Indicates that an SLB service has gone down.
Indicates that an SLB server has reached its configured connection limit.
Indicates that an SLB server has reached its configured connection-resume value.
Indicates that an SLB service has reached its configured
connection limit.
Indicates that an SLB service has reached its configured
connection-resume value.
Indicates that the connection limit configured on a virtual
server has been exceeded.
Indicates that the connection limit configured on a virtual
port has been exceeded.
Indicates that the connection rate limit configured on a virtual server has been exceeded.
Indicates that the connection rate limit configured on a virtual port has been exceeded.
Indicates that an SLB virtual service port has come up. An
SLB virtual servers service port is up when at least one
member (real server and real port) in the service group
bound to the virtual port is up.
Indicates that an SLB virtual service port has gone down.
Indicates that the configured SLB application buffer threshold has been exceeded.*
* This threshold is configurable. To use the GUI, navigate to Config > System > Settings >
General > Threshold. In the CLI, use the monitor command at the global configuration level.
SNMP Communities and Views

You can allow external SNMP managers to access the values of MIB
objects from the AX device. To allow remote read-only access to AX MIB
objects, configure one or both of the following types of access.
SNMP Community Strings
An SNMP community string is a string that an SNMP manager can present
to the AX device when requesting MIB values.
Community strings are similar to passwords. You can minimize security risk
by applying the same principles to selecting a community name as you
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
53 of 950

would to selecting a password. Use a hard-to-guess string and avoid use of
commonly used community names such as public or private.
You also can restrict access to specific Object IDs (OIDs) within the MIB,
on an individual community basis. OIDs indicate the position of a set of
MIB objects in the global MIB tree. The OID for A10 Networks AX Series
objects is 1.3.6.1.4.1.22610.
SNMP Views
An SNMP view is like a filter that permits or denies access to a specific OID
or portions of an OID. You can configure SNMP user groups and individual
SNMP users, and allow or disallow them to read specific portions of the AX
MIBs using different views.
When you configure an SNMP user group or user, you specify the SNMP
version. SNMP v1 and v2c do not support authentication or encryption of
SNMP packets. SNMPv3 does. You can enable authentication, encryption,
or both, on an individual SNMP user-group basis when you configure the
groups. You can specify the authentication method and the password for
individual SNMP users when you configure the users.
SNMP Configuration Steps

To configure SNMP:
1. Optionally, configure location and contact information.
2. Optionally, configure external SNMP trap receivers.
3. Optionally, configure one or more read-only communities.
4. Optionally, configure views, groups, and users.
5. Enable the SNMP agent and SNMP traps.
6. Save the configuration changes.
You are not required to perform these configuration tasks in precisely this
order. The workflow in the GUI is slightly different from the workflow
shown here.
Note: By default, the AX device can reach remote logging and trap servers only if
they are reachable through the AX devices data ports, not the management port. To
enable the AX device to reach remote logging and trap servers through the management port, see Using the Management Interface as the Source for Management
Traffic on page 929.
54 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

To configure support for SNMPv3 or to configure views, groups, and
users, use the CLI. The current release does not support configuration of
SNMPv3 using the GUI.
Note:
1. Select Config > System > SNMP.

2. In the General section, configure general settings:
a. To enable SNMP, select Enabled next to System SNMP Service.
b. In the System Location field, enter a description of the AX devices
location.
c. In the System Contact field, enter the name or email address of the
AX administrator to contact for system issues.
3. In the Community section, configure community strings:
a. Click Community.
b. In the SNMP Community field, enter a community name.
c. To restrict SNMP access to a specific host or subnet, enter a hostname or an IP address and network mask in the Hostname (IP/
Mask) field.
By default, any host can access the SNMP agent on the AX device.
d. In the Object Identifier field, enter the OID at which SNMP management applications can reach the AX device.
e. Click Add.
f. Repeat step b through step e for each combination of community
string, management host, and OID.
4. In the Trap section, specify external trap receivers:
a. Click Trap.
b. In the Community field, enter the name of the community sending
the traps.
c. In the IP Address (host) field, enter the IP address or fully-qualified
hostname of the SNMP trap receiver.
d. If the trap receiver does not use the standard protocol port to listen
for traps, change the port number in the Port field.
e. Select SNMP the version from the Version drop-down list:
V1
V2c
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
55 of 950

f. Click Add to add the receiver.
g. Repeat step b through step f for each trap receiver.
5. In the Trap List section, enable traps:
a. Click Trap List.
b. To enable all traps, select All Traps. Otherwise, select the individual
traps you want to enable.
6. Click OK.
7. To save the configuration changes, click the Save button.
Note:
When there are unsaved configuration changes on the AX device, the

Save button flashes.
USING THE CLI

All SNMP configuration commands are available at the global configuration level of the CLI.
1. To configure location and contact information, use the following commands:
snmp-server location location
snmp-server contact contact-name
2. To configure external SNMP trap receivers, use the following command:
snmp-server host trap-receiver
[version {v1 | v2c}]
community-string
[udp-port port-num]
3. To configure one or more read-only communities, use the following
command:
snmp-server community read ro-community-string
[oid oid-value]
[remote {hostname | ipaddr mask-length |
ipv6-addr/prefix-length}]
56 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuration Examples
4. To configure views, groups, and users, use the following commands:
snmp-server view view-name oid [oid-mask]
{included | excluded}
snmp-server group group-name
{v1 | v2c | v3 {auth | noauth | priv}}
read view-name
snmp-server user username group groupname
{v1 | v2 | v3 [auth {md5 | sha} password
[encrypted]]}
5. To enable the SNMP agent and SNMP traps, use the following command:
snmp-server enable
[
traps [
snmp [trap-name] |
system [trap-name] |
network [trap-name] |
ha [trap-name] |
slb [trap-name]
]
]
6. To save the configuration changes, use the following command at the
Privileged EXEC level or any configuration level of the CLI:
write memory
The following examples show how to configure the system settings
described in this chapter.
GUI EXAMPLE
The following examples show the GUI screens used for configuration of the
basic system settings described in this chapter.
Note:
b y
The GUI does not support configuration of SNMPv3 settings.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
57 of 950

FIGURE 5
58 of 950
Config > Network > DNS > DNS
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 6
b y
Config > System > Time > Date/Time
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
59 of 950

FIGURE 7
60 of 950
Config > System > Settings > Log
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 8
b y
Config > System > SNMP
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
61 of 950

62 of 950
FIGURE 9
Config > System > SNMP > Trap List
FIGURE 10
Save Button
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

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

AX-SLB2(config)#ntp server enable
The following commands configure the AX device to send system log messages to an external syslog server and to email Emergency messages to the
system admins. In this example, the message levels sent to the external
server are left at the default, Error (3) and above. By default, the same mesP e r f o r m a n c e
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
63 of 950

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

You can configure the AX device to email log messages, using email log filters. By default, emailing of log messages is disabled.
Log email filters consist of the following parameters:
Filter ID Filter number, 1-8.
Conditions One or more of the following:
Severity Severity levels of messages to send in email. If you do
not specify a message level, messages of any severity level match

the filter and can be emailed.
Software Module Software modules for which to email messages.
Messages are emailed only if they come from one of the specified
software modules. If you do not specify a software module, messages from all modules match the filter and can be emailed.
Regular Expression Message text to match on. Standard regular
expression syntax is supported. Only messages that meet the criteria
of the regular expression can be emailed. The regular expression
64 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

can be a simple text string or a more complex expression using standard regular expression logic. If you do not specify a regular expression, messages with any text match the filter and can be emailed.
Operators Set of Boolean operators (AND, OR, NOT) that specify
how the conditions should be compared. (See Boolean Operators on

page 65.)
Trigger option Specifies whether to buffer matching messages or send
them immediately.
Boolean Operators
A logging email filter consists of a set of conditions joined by Boolean
expressions (AND / OR / NOT).
The CLI Boolean expression syntax is based on Reverse Polish Notation
(also called Postfix Notation), a notation method that places an operator
(AND, OR, NOT) after all of its operands (in this case, the conditions list).
After listing all the conditions, specify the Boolean operator(s). The following operators are supported:
AND All conditions must match in order for a log message to be
emailed.
OR Any one or more of the conditions must match in order for a log
message to be emailed.
NOT A log message is emailed only if it does not match the conditions
(For more information about Reverse Polish Notation, see the following
link: http://en.wikipedia.org/wiki/Reverse_Polish_notation.)
USING THE GUI

2. On the menu bar, select Log.
3. In the Logging Email Filter section, click Add. A configuration page for
the filter appears.
4. In the ID field, enter the filter ID, 1-8.
5. To immediately send matching messages in an email instead of buffering them, select Trigger. Otherwise, matching messages are buffered
until the message buffer becomes full or the send timer for emailed log
messages expires.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
65 of 950

6. Construct the rest of the filter by selecting the conditions.
Note:
The conditions must be selected in the order described here. Otherwise,

the filter will be invalid. If you accidentally configure an invalid filter,
you can click Clear to remove the filter conditions and start again.
a. Select the message severity level from the Level drop-down list, and
click Add. To add more severity levels, repeat this step for each
severity level.
b. Optionally, select a software module from the Module drop-down
list, and click Add. To add more modules, repeat this step for each
module.
c. Optionally, enter a regular expression in the Pattern field to specify
message text to match on, and click Add.
d. Select the operator from the Operator drop-down list, and click Add.
7. Click OK. The new filter appears in the Logging Email Filter section on
the Log page.
8. Optionally, to change the maximum number of log messages to buffer
before sending them in email, edit the number in the Logging Email
Buffer Number field. You can specify 16-256 messages. The default is
50.
9. Optionally, to change the number of minutes the AX device waits before
sending all buffered messages, edit the number in the Logging Email
Buffer Time field. This option takes affect if the buffer does not reach
the maximum number of messages allowed. You can specify 10-1440
minutes. The default is 10.
10. When finished configuring log settings, click OK.
66 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 11
section)
Config > System > Settings > Log - Add (Logging Email Filter
FIGURE 12
Config > System > Settings > Log (Logging Email Filter added)
USING THE CLI

To configure log email settings, use the following commands at the global
configuration level of the CLI:
[no] logging email buffer [number num]
[time minutes]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
67 of 950

This command configures message buffering. The number option specifies
the maximum number of messages to buffer. You can specify 16-256. The
default is 50. The time option specifies how long to wait before sending all
buffered messages, if the buffer contains fewer than the maximum allowed
number of messages. You can specify 10-1440 minutes. The default is 10.
Whenever an email is triggered, the email will contain all buffered log messages.
[no] logging email
operators [trigger]
filter
filter-num
conditions
The filter-num option specifies the filter number, and can be 1-8.
The conditions list can contain one or more of the following:
level severity-levels Specifies the severity levels of messages to send
in email. You can specify the severity levels by number (0-7) or by

name: emergency, alert, critical, error, warning, notification, information, or debugging.
mod software-module-name Specifies the software modules for which
to email messages. Messages are emailed only if they come from one of
the specified software modules. For a list of module names, enter ?
instead of a module name, and press Enter.
pattern regex Specifies the string requirements. Standard regular
expression syntax is supported. Only messages that meet the criteria of

the regular expression will be emailed. The regular expression can be a
simple text string or a more complex expression using standard regular
expression logic.
The operators are a set of Boolean operators (AND, OR, NOT) that specify
how the conditions should be compared. (See Filter Syntax below.)
The trigger option immediately sends the matching messages in an email
instead of buffering them. If you omit this option, the messages are buffered
based on the logging email buffer settings.
Considerations
You can configure up to 8 filters. The filters are used in numerical order,
starting with filter 1. When a message matches a filter, the message will
be emailed based on the buffer settings. No additional filters are used to
examine the message.
A maximum of 8 conditions are supported in a filter.
68 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The total number of conditions plus the number of Boolean operators
supported in a filter is 16.

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

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

matching messages.
AX(config)#logging email filter 1 level information pattern "abc" and trigger
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
69 of 950

70 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Network Setup
This chapter describes how to insert the AX device into your network.
After you complete the setup tasks in this chapter that are applicable to your
network, the AX device will be ready to configure for its primary function:
load balancing.
This chapter includes an example for Routing Information Protocol (RIP).
For information about Open Shortest Path First (OSPF), see Open Shortest Path First (OSPF) on page 105.
Note:
Overview
AX Series devices can be inserted into your network with minimal or no
changes to your existing network. You can insert the AX device into your
network as a Layer 2 switch or a Layer 3 router.
The same Layer 4-7 features are available with either deployment option.
You can deploy the AX device as a single unit or as a High Availability
(HA) pair. Deploying a pair of AX devices in an HA configuration provides
an extra level of redundancy to help ensure your site remains available to
clients. For simplicity, the examples in this chapter show deployment of a
single AX device. For information about HA, see High Availability on
page 445.
Examples are provided in this chapter for the following types of network
deployment:
Transparent mode
Transparent mode in multinetted environment
Route mode (also called gateway mode)
Direct Server Return (DSR) in transparent mode
DSR in route mode
DSR in mixed Layer 2/Layer 3 environment
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
71 of 950

Overview
IP Subnet Support
Each AX device has a management interface and data interfaces. The management interface is a physical Ethernet port. A data interface is a physical
Ethernet port, a trunk group, or a Virtual Ethernet (VE) interface.
The management interface can have a single IP address.
An AX device deployed in transparent mode (Layer 2) can have a single IP
address for all data interfaces. The IP address of the data interfaces must be
in a different subnet than the management interfaces address.
An AX device deployed in route mode (Layer 3) can have separate IP
addresses on each data interface. No two interfaces can have IP addresses
that are in the same subnet. This applies to the management interface and all
data interfaces.
72 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Transparent Mode
Transparent Mode
Figure 13 shows an example of an AX Series device deployed in transparent mode.
FIGURE 13
AX Deployment Example Transparent Mode
The blue arrows show the traffic flow for client-server traffic; in this example, between clients and server 10.10.10.3.
In this example, the AX device is inserted directly between the gateway
router and the real servers. The AX device and real servers are all in the
same subnet and all use the router as their default gateway.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
73 of 950

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 SLB Source
NAT on page 609.)
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.
Configuration Example
This section shows the GUI screens and CLI commands needed to implement the configuration shown in Figure 13.
USING THE GUI

The following figures show the GUI screens used to implement the configuration shown in Figure 13. Here and elsewhere in this guide, the command
paths used to access a GUI screen are listed in the figure caption.
Interface Configuration
FIGURE 14
74 of 950
Config > Network > Interface > Transparent
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Transparent Mode
For reference, Figure 14 shows the entire interface. Subsequent figures
show only the relevant configuration page.
Note:
FIGURE 15
Config > Network > Interface > LAN
Real server configuration

The following screen examples show the GUI pages for basic SLB configuration.
To implement changes entered on a GUI configuration page, click OK at the
bottom of the page.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
75 of 950

Transparent Mode
FIGURE 16
76 of 950
Config > Service > SLB > Server
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Transparent Mode
Service group configuration
FIGURE 17
b y
Config > Service > SLB > Service Group
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
77 of 950

Transparent Mode
Virtual server configuration
78 of 950
FIGURE 18
Config > Service > SLB > Virtual Server
FIGURE 19
Config > Service > SLB > Virtual Server - Virtual Server Port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Transparent Mode
USING THE CLI

The following commands configure the global IP address and default gateway:
AX(config)#ip address 10.10.10.2 /24
AX(config)#ip default-gateway 10.10.10.1
The following commands enable the Ethernet interfaces used in the example:
AX(config)#interface ethernet 1
AX(config-if:ethernet1)#enable
AX(config-if:ethernet1)#interface ethernet 2
AX(config-if:ethernet3)#exit
The following commands add the SLB configuration. (For more information about SLB commands, see the SLB configuration chapters in this
guide. Also see the AX Series CLI Reference.)
Commands to configure the real servers
AX(config)#slb server rs1 10.10.10.3
AX(config-real server)#port 80 tcp
AX(config-real server-node port)#exit
AX(config-real server)#exit
Commands to configure the service group

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

AX(config)#slb virtual-server vip1 10.10.10.99
AX(config-slb virtual server)#port 80 fast-http
AX(config-slb virtual server-slb virtua...)#service-group sg-web
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
79 of 950

Transparent Mode in Multinetted Environment

Figure 20 shows an example of an AX device deployed in transparent
mode, in a multinetted environment.
FIGURE 20
AX Deployment Example Transparent Mode in Multinetted
Environment
This example is similar to the example in Figure 13, except the real servers
are in separate subnets. Each server uses the router as its default gateway,
but at a different subnet address.
80 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The blue arrows show the traffic flow for client-server traffic; in this example, between clients and server 10.10.10.4.
To enable the AX device to pass traffic for multiple subnets, the device is
configured with multiple VLANs. The interfaces in subnet 10.10.10.x are in
VLAN 1. The interfaces in the 10.10.20.x subnet are in VLAN 2.
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.)
Note:
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
devices 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 specified 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:
b y
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.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
81 of 950

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 73.
USING THE GUI
82 of 950
FIGURE 21
Config > Network > VLAN
FIGURE 22
Config > Service > IP Source NAT > IPv4 Pool
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 23
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
83 of 950

USING THE CLI

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

NAT. The pool is in the same subnet as real server 10.10.20.4.
AX(config)#ip nat pool pool1 10.10.20.100 10.10.20.101 netmask /24 gateway
10.10.20.1
The following commands add the SLB configuration. The source-nat command 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.)
84 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010



AX(config-slb virtual server-slb virtua...)#source-nat pool pool1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
85 of 950

Route Mode
Route Mode
Figure 24 shows an example of an AX device deployed in route mode.
FIGURE 24
AX Deployment Example Route Mode
The blue arrows show the traffic flow for client-server traffic; in this example, between clients and server 192.168.4.101. This example shows a database 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 database server through the AX device just as they would through any other
86 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 subnets on each of the interfaces connected to the network. The AX device can
be configured with static IP routes and can be enabled to run RIP and OSPF.
In this example, the device is enabled to run RIP. 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 High Availability on page 445.)
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 73.
Note:
In the current release, the GUI does not support configuration of RIP or
OSPF.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
87 of 950

Route Mode
USING THE GUI
88 of 950
FIGURE 25
Config > Network > Interface > LAN > IPv4
FIGURE 26
Config > Network > Route > IPv4 Static
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Route Mode
USING THE CLI

The following commands enable the Ethernet interfaces used in the example and configure IP addresses on them:
AX(config-if:ethernet1)#ip address 10.10.10.2 /24
The following command configures the default route through 10.10.10.1:

AX(config)#ip route 0.0.0.0 /0 10.10.10.1
The following commands configure the AX device as a RIP router. In this

example, a simple text string (myrip) is used to authenticate route updates
exchanged between the AX device and its neighboring RIP routers.
AX(config-if:ethernet1)#ip rip authentication string myrip
AX(config)#router rip
AX(config-router-rip)#network 10.10.10.0 /24
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
89 of 950

Route Mode
AX(config-router-rip)#exit


AX(config-slb virtual server)#port 80 http
90 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Direct Server Return in Transparent Mode

Figure 27 shows an example of an AX device deployed in transparent
mode, in a Direct Server Return (DSR) configuration. In a DSR configuration, replies from real servers do not necessarily pass through the AX
device.
FIGURE 27
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
91 of 950

link can be on a single Ethernet port or a trunk. This example uses a single
Ethernet port.
The blue arrows show the traffic flow for client-server traffic; in this example, 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.
Note:
VIP redistribution is not supported for VIPs that are configured for Direct
Server Return (DSR).
DSR Health Checking
Layer 3 and Layer 4-7 health checks are supported in DSR configurations.
The target of the Layer 3 health checks can be the real IP addresses of the
servers, or the virtual IP address, depending on your preference.
To send the Layer 3 health checks to the real server IP addresses, you
can use the default Layer 3 health method (ICMP).

To send the Layer 3 health checks to the virtual IP address instead:
Configure an ICMP health method with the transparent option
enabled, and with the alias address set to the virtual IP address.
Globally enable DSR health checking.
Layer 4-7 health checks are sent to the same IP address as the Layer 3 health
checks, and then addressed to the specific protocol port. You can use the
default TCP and UDP health monitors or configure new health monitors.
This example uses the default TCP health monitor.
Requirements
This configuration has certain requirements:
Requirements on the AX device:
The AX device, virtual server, and the real servers all must be in the
same subnet.
The virtual server IP address must be configured as a loopback
interface on each real server. (This is performed on the real server
itself, not as part of the real servers configuration on the AX
device.)
DSR must be enabled on the virtual service ports. (Enabling DSR is
equivalent to disabling destination NAT.)
Note:
92 of 950
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 27.
USING THE GUI

This example does not include configuration of the real servers, or configuration of the virtual server other than the steps for enabling DSR.
Note:
Specify the AX devices IP address and default gateway

1. Select Config > Network > Interface.
2. On the menu bar, select Transparent.
3. Enter the IP address, network mask or prefix length, and default gateway 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 example, e3).
4. Click Enable. The icon in the Status column changes to a green checkmark to indicate that the interface is enabled.
Enable DSR on virtual ports
1. Select Config > Service > Server > Virtual Server.
2. Select the virtual server or click Add to create a new one.
3. Select the virtual port and click Edit, or click Add to create a new one.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
93 of 950

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 enable the Ethernet interface connected to the clients and server:

94 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
95 of 950

Direct Server Return in Route Mode

Figure 28 shows an example of an AX device deployed in a DSR configuration in route mode.
FIGURE 28
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 91.)
Note:
96 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

This section shows how to implement the configuration shown in Figure 28.
The following examples only show the part of the configuration that differs 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.
Note:
USING THE GUI

Configure an IP address on the Ethernet port
2. On the menu bar, select LAN.
3. In the Interface column, click on the interface name (for example, e3).
4. In the General section, click Enabled next to Status.
5. In the IPv4 section, enter the IP address and network mask.
6. Click OK.
Configure a default route
1. Select Config > Network > Route.
2. On the menu bar, select IPv4 Static.
3. Click Add.
4. Enter 0.0.0.0 in the IP Address and Netmask fields.
5. Enter the IP address of the gateway router in the Gateway field.
6. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
97 of 950

USING THE CLI

The following commands enable the Ethernet interface used in the example
and configure an IP address on it:
The following command configures the default route through 10.10.10.1:

AX(config)#ip route 0.0.0.0 /0 10.10.10.1
The rest of the configuration commands are the same as those shown in
Direct Server Return in Transparent Mode on page 91, beginning with
configuration of the real servers.
98 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 29 shows an example that
uses a backup server in a different subnet.
The deployment described in this section is useful for deploying backup
servers to use only if primary servers are unavailable.
Note:
FIGURE 29
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 functions. 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
99 of 950

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, destination NAT is disabled on virtual ports used for DSR. However, destination 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
servers IP address does not need to be changed. It can remain on a different 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 template does not apply to the same port when used in other service
groups.
Note:
USING THE GUI

Configure a port template to enable destination NAT on the
backup servers port
1. Select Config > 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.
100 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

5. Select Disabled next to Direct Server Return.
6. Click OK.
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.
If you are modifying a member that is already in the list, click the checkbox in the row containing the member information, select the priority,
then click Update.
Note:
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.
c. Select the port template for the backup server from the Server Port
Template drop-down list. This is the template configured in Configure a port template to enable destination NAT on the backup
servers port on page 100.
d. Leave 1 selected in the Priority drop-down list.
e. Click Add.
7. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
101 of 950

FIGURE 30
Config > Service > SLB > Template > Server Port
FIGURE 31
To set the priority values of the primary servers to a higher value than the
backup server, re-add the members for the primary servers ports, and use
the priority option. Set the priority to a value higher than 1 (the default).
Use the same priority value on each of the primary servers member ports.
102 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
103 of 950

104 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Support for Multiple OSPFv2 Processes and OSPFv3 Instances
Open Shortest Path First (OSPF)

The AX device supports the following OSPF versions:
OSPFv2 for IPv4
OSPFv3 for IPv6
This chapter provides configuration examples. For detailed CLI syntax

information, see OSPF Command Reference on page 207.
Support for Multiple OSPFv2 Processes and OSPFv3

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

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

AX Release 2.4.3 includes support for the following OSPF MIBs:
RFC 1850 OSPFv2 Management Information Base
draft-ietf-ospf-ospfv3-mib-08 OSPFv3 Management Information Base
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
105 of 950

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

On VE 3, an IPv4 address is configured. On VE 4, an IPv4 address and an
IPv6 address are configured.
OSPFv2 authentication is configured on VE 3, and the OSPF cost is set to
20.
On VE 4, the OSPF cost is set to 15. Another dynamic routing protocol,
RIP, is also enabled.
interface ve 3
ip address 1.1.1.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 abc
ip ospf cost 20
!
106 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

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

The router ID is set to 3.3.3.3. A stub area is added, redistribution is
enabled, and the SPF timer is changed.
router ipv6 ospf 1
router-id 3.3.3.3
redistribute static metric 5 metric-type 1
redistribute ip-nat
redistribute floating-ip
area 1 stub
timers spf exp 500 50000
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
107 of 950

OSPF Logging
To enable logging for OSPF:
1. Configure router log file settings.
2. Enable OSPF logging (debugging).
The following commands configure router log file settings:
router log file name routerlog
router log file per-protocol
router log file size 10
router log file rotate 4
These commands create a router log file named routerlog. The per-protocol option will log messages for each routing protocol separately. The log
file will hold a maximum 10 MB of data, after which the messages will be
saved in a backup and the log file will be cleared. The log will be backed up
a maximum of 4 times, after which the oldest backup will be deleted to
make room for a new backup.
The following commands enable logging for OSPFv2:
debug a10 ospf
debug ospf all
The following commands enable logging for OSPFv3:

debug a10 ipv6 ospf
debug ipv6 ospf all
For each level, both debug commands are required.

The all option in the debug ospf all and debug ipv6 ospf all commands
enables all OSPFv2 or OSPFv3 logging options. For descriptions if the individual options, see debug on page 266.
108 of 950
Note:
Log file settings are retained across reboots but debug settings are not.
Note:
Enabling debug settings that produce lots of output, or enabling all debug
settings, is not recommend for normal operation.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
HTTP Load Balancing

This chapter describes HTTP load balancing and how to configure it.
Overview
HTTP load balancing manages HTTP traffic across a Web server farm.
Figure 32 shows an example of an HTTP load balancing deployment.
The network topologies in application examples such as this one are simplified to focus on the application. For example, the Internet router connecting 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 Availability (HA).
Note:
FIGURE 32
b y
HTTP Load Balancing
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
109 of 950

Overview
In this example, a server farm consisting of three servers provides content
for Web site www.example.com. Clients access the site through its virtual
IP address, 192.168.10.11. When the AX device receives a client request for
the HTTP port (80) on 192.168.10.11, the AX device selects a real server
and sends the client request to the server.
For simplicity in this example, the real servers use the default protocol port
number for HTTP (80). The port numbers on the real and virtual servers are
not required to match.
The client is unaware of the real IP address of the real server, nor is the client 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 clients
perspective, the Web session is between the client and port 80 on
192.168.10.11.
SERVICE GROUPS
A service group contains a set of real servers from which the AX device can
select to service a client request.
This example uses a single service group that contains all the real servers
and the applicable service port (80). During configuration, you bind the service 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
110 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
type. Also use this service type for stream-based applications such as
RAM Caching and compression.
Fast-HTTP Streamlined hybrid stack for high performance. If you do
not plan to offload SSL or customize any templates, use Fast-HTTP.

(For a complete list of the service types, see Virtual Service Port Parameters on page 877.)
TEMPLATES
Templates are sets of configuration parameters that apply to specific service
types or to servers and service ports. This example uses the default settings
for each of the templates that are automatically applied to the HTTP service
type and to the real and virtual servers and ports. The rest of the information
in this section is for reference but is not required reading to continue with
this example.
For some of types of templates, the AX configuration has a default template that is automatically applied to a service port unless you apply another
template of the same type instead. (See Service Template Parameters on
page 819.)
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 609.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
111 of 950

Overview
The following types of templates also can be used with HTTP service ports.
However, these types of templates do not have default templates that are
applied automatically.
Cookie Persistence Inserts a cookie in the HTTP header of a server
reply before sending the reply to the client. The cookie ensures that subsequent 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 configurable timer on the AX device. The granularity of the persistence can
be set to always use the same real server port, the same real server, or
the same service group.
(For an example that uses a source-IP persistence template, see Layer 4
TCP/UDP Load Balancing on page 255.)
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 353 in this guide
Config Commands: SLB Templates chapter in the AX Series CLI Ref-
erence
Config > Service > SLB > Template section in the Config Mode
chapter of the AX Series GUI Reference
112 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring HTTP Load Balancing
HEALTH MONITORS
This example uses the following types of health monitors to check the real
servers:
Ping A Layer 3 health method that sends an ICMP echo request to the
real servers IP address. The server passes the health check if the AX
device receives a ping reply.
TCP By default, every 30 seconds the AX device sends a connection
request (TCP SYN) to each load balanced TCP port on each server, in
this case ports 80 and 443. A TCP port passes the health check if the
server replies to the AX device by sending a TCP SYN ACK. By
default, the AX device completes the TCP handshake.
In addition to these default health checks, you can configure health monitors
for specific service types. This example uses an HTTP health monitor, with
the following default settings.
Every 30 seconds, the AX device sends an HTTP GET request for the
default index page.

The HTTP service port passes the health check if the requested page is
present on the server and the server replies with an OK message (200).
(For more information about health monitors and their configurable options,
see Health Monitoring on page 373.)

To configure the HTTP load balancing solution described in Overview on
page 109, 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
113 of 950

USING THE GUI

To configure an HTTP health method
1. Select Config > Service > Health Monitor.
2. Select Health Monitor on the menu bar.
3. Click Add.
4. 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.
6. Optionally, select or enter additional options for the health monitor. (See
Health Monitoring on page 373.)
In this example, you can use all the default settings
7. Click OK. The new monitor appears in the health monitor table.
FIGURE 33
114 of 950
Config > Service > Health Monitor > Health Monitor
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

To configure the real servers
Perform the following procedure separately for each real server.
2. Select Server on the menu bar.
3. Click Add.
4. 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.
Enter the servers real address, not the virtual server IP address.
Note:
6. In the Health Monitor drop-down list, select ping or leave the monitor
unset.
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 373.)
Note:
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 114.
9. Click Add. The port appears in the port list.
10. Click OK. The real server appears in the server table.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
115 of 950

Note:
FIGURE 34
FIGURE 35
Config > Service > SLB > Server (real servers added)
The AX device begins sending health checks to a real servers IP address

and service ports as soon as you finish configuring the server. The overall
health status for the server is shown in the Health column. If the status is
Down (
) instead of Up (
), verify that health monitors are configured for all the service ports. The default Layer 3 health method is auto-
116 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

matically used for the Layer 3 health check, unless you selected another
health method instead.
To configure the service group
1. Select Config > Service > SLB, if not still selected.
2. Select Service Group on the menu bar.
3. Click Add.
4. 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
117 of 950

FIGURE 36
118 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

To configure the virtual server
1. Select Config > Service > SLB, if not still selected.
2. Select Virtual Server on the menu bar.
3. Click Add. The General 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.
6. In the Port section, click Add. The Virtual Server Port section appears.
7. In the Type drop-down list, select the service type. In this example,
select Fast-HTTP.
8. In the Port field, enter the service port number. In this example, enter
80.
9. In the Service Group drop-down list, select the service group.
10. Click OK. The port appears in the Port list of the Port section.
11. Click OK. The virtual server appears in the virtual server table.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
119 of 950

120 of 950
FIGURE 37
FIGURE 38
section
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

The command syntax shown in this section is simplified for the configuration example in this chapter. For complete syntax information about any
command, see the AX Series CLI Reference.
Note:
1. To configure HTTP and HTTPS health methods, use the following commands:
health monitor monitor-name
Enter this command at the global configuration level of the CLI, for
each monitor to be configured. The command changes the CLI to the
configuration level for the monitor. At the monitor configuration level,
enter the following command:
method http
Entering this command, without entering additional commands at this
level, configures the monitor to use all the default settings for the HTTP
method.
To customize settings for a health monitor, use additional commands at
the configuration level for the monitor.
2. To configure the real servers, use the following commands:
slb server server-name ipaddr
This command changes the CLI to the configuration level for the real
server, where you can use the following command to add the HTTP port
to the server:
port port-num tcp
The port-num specifies the protocol port number. In this example, specify 80.
This command adds the port and changes the CLI to the configuration
level for the port, where you can use the following command to enable
the HTTP health check:
health-check monitor-name
For monitor-name, specify the name of the HTTP health monitor configured in step 1.
3. To configure the service group, use the following commands:
slb service-group group-name tcp
This command changes the CLI to the configuration level for the service
group, where you can use the following command to add the real servers
and service ports to the group:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
121 of 950

member server-name:portnum
The portnum is the protocol port number of the service to be load balanced. In this example, specify 80.
Repeat the command for each real server.
4. To configure the virtual server and virtual port, 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 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.
The port command changes the CLI to the configuration level for the
virtual port, where you can use the following command to bind the virtual port to the service group:
service-group group-name
The group-name is the name of the service group configured in step 3.
CLI EXAMPLE
The following commands configure the HTTP health monitor:
AX(config)#health monitor http-monitor
AX(config-health:monitor)#method http
AX(config-health:monitor)#exit
The following commands configure the real servers:

AX(config)#slb server web-2 10.10.10.2
AX(config-real server-node port)#health-check http-hmon
122 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following commands configure the service group:

AX(config-slb service group)#member web-2:80
The following commands configure the virtual server:

AX(config)#slb virtual-server web-vip 192.168.10.11
AX(config-slb virtual server-slb virtua...)#exit
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
123 of 950

124 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
HTTP Options for SLB

This chapter describes the HTTP options you can configure in HTTP templates, and provides examples of their use.
Overview
HTTP templates provide many SLB options. Some options control selection
of real servers or service groups, while other options modify HTTP header
information or enhance website performance.
Summary of HTTP Options

This section briefly describes each of the options you can configure in
HTTP templates.
Options for Server and Service Group Selection
You can use the following HTTP options to select real servers or service
groups. The server selection options override selection by the load-balancing 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 128.)
URL / host switching Selects a service group based on the URL path
or domain in the clients GET request. (See URL / Host Switching on

page 133.)
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 141.)
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 143.)
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 rebalP e r f o r m a n c e
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
125 of 950

Overview
ancing of server selection. (See Strict Transaction Switching on
page 161.)
Performance Enhancing Option
Content Compression You can configure the AX device to offload
content compression from real servers. Enabling content compression

on the AX device can help increase overall website performance by
freeing real server resources from CPU-intensive compression tasks.
(See Content Compression on page 144.)
Options that Modify HTTP Requests
Client IP insertion Inserts the clients 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 client address to a different field instead; for example: X-Forwarded-For.
(See Client IP Insertion / Replacement on page 151.)
Header insertion / erasure Inserts a field:value pair into requests or
responses, or deletes a header. (See Header Insertion / Erasure on

page 154.)
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 159.)
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 template 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:
126 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
USING THE GUI

To configure an HTTP template:
1. Select Config > Service > Template.
2. Select Application > HTTP on the menu bar.
3. Click Add. The HTTP section appears.
4. Enter a name for the template.
5. Select or enter values for the template options you want to use. The
remaining sections in this chapter describe the fields for configuring
each option.
Some settings are on the other HTTP template sections (App switching,
Redirect Rewrite, and Compression).
Note:
6. When finished, click OK. The template appears in the HTTP template
list.
To bind a template to a virtual service port:
3. To edit an existing virtual server, select it. To configure a new one, Click
Add. The General 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
127 of 950

URL Hash Switching
USING THE CLI

To configure an HTTP template, enter the following command at the global
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 configuring each option.
To bind a template to a virtual service port, enter the following command at
the configuration level for the port:
template http template-name
URL Hash Switching

URL hash switching provides a simple method for optimizing a server farm
in which the same content is served by multiple servers. This feature
enhances website performance by taking advantage of content caching on
the real servers.
When enabled, URL hashing selects a real server for the first request for
given content, and assigns a hash value to the server for the content. The
AX device then sends all subsequent requests for the content to the same
real server.
Figure 39 shows an example of URL hashing.
128 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

URL Hash Switching
FIGURE 39
URL Hashing
In this example, a service group contains three real servers. Each of the real
servers contains the same set of .html(l), .pdf, and .jpg files. The AX device
is configured to calculate a hash value based on the last 3 bytes of the URL
string in the client request, and assign the hash value to a server.
After assigning a hash value to a server, the AX device sends all requests
that match the hash value to the same real server. In this example, all
requests that end with pdf are sent to the same server.
If the real server becomes unavailable, the AX device selects another server,
assigns a hash value to it, and uses that server for all subsequent requests for
URL strings that have the same hash value.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
129 of 950

URL Hash Switching
Hash Options
You can specify the following hash options:
Bytes Specifies how many bytes of the URL string to use to calculate
the hash value.

First or last Specifies which end of the URL string to use to calculate
the hash value.

The example in Figure 39 calculates hash values based on the last 3 bytes of
the URL strings.
URL Hash Switching with Server Load Awareness

AX Release 2.4.3 has a new URL hash switching option that provides
server load awareness. This feature allows servers to act as backups to other
servers, based on server 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 servers 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
servers responses. The header must have one of the following values: 0, 1,
or 2.
Server-Status: load=[0,1,2]
The AX device manages requests to the server based on the Server-Status
code. Table 4 describes the valid load status codes that can be reported by a
server.
130 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

URL Hash Switching
TABLE 4
Server-Status Load Values
Load Status
Reported by
Server
0
Description
Server is able to handle all of its own
requests.
AX Action
AX device continues using the server for the
URLs hashed to the server.
Server also can handle requests for other

servers if necessary.
If necessary, AX device also uses the server

to help with URLs hashed to servers that have
load status 2.
AX device continues using the server for the
URLs hashed to the server.
Server is able to handle its own requests.

However, server can not handle requests for
other servers.
Server is overloaded and needs help handling

its own requests. Requests are distributed
among this server and at least one other
server (with load status 0), in round robin
fashion.
AX device does not use the server to help

handle requests for other servers.
AX device uses servers that have load
status 0 to help handle the overloaded
servers requests.
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 calculate 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. Subsequent requests are load balanced as listed in Table 4.
TABLE 5
Server
S1
S2
S3
Server-Status Load-Balancing Example

Load Status
Reported by
Server
0
0
0
b y
AX Action
New requests for /article-new1 are sent only to server S1.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
131 of 950

URL Hash Switching
TABLE 5
Server-Status Load-Balancing Example (Continued)
Server
S1
S2
S3
S1
S2
S3
Load Status
Reported by
Server
2
0
0
2
1 or 2
0
AX Action
New requests for /article-new1 are distributed between S1 and S2, using
round robin.
New requests for /article-new1 are distributed between S1 and S3, using
round robin.
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 Template Configuration on page 126.)
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. Click OK.
132 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

URL / Host Switching
USING THE CLI

Enter the following command at the configuration level for the HTTP template:
url-hash-persist {first | last} bytes
[use-server-status]
CLI Examples
The following commands implement the URL hashing configuration shown
in Figure 39 on page 129.
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 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 clients GET request. The selection overrides the service group
configured on the virtual port.
You can configure an HTTP template with one of the following servicegroup switching options:
URL switching Selects a service group based on the URL path in the
GET line of the HTTP requests header

Host switching Selects a service group based on the domain name in
the Host field of the HTTP requests header

Note:
b y
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-
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
133 of 950

tence template. (See Using URL / Host Switching along with Cookie
Persistence on page 137.)
Figure 40 shows an example of URL switching.
FIGURE 40
URL Switching
In this example, the AX device is configured to use separate service groups

for URLs in the www.example.com domain. The real servers in service
group sg-abc provide content for www.example.com/abc. The real servers
in service group sg-123 provide content for www.example.com/123.
URL switching rules configured on the AX device select a service group
based on the beginning of the URL on the GET line of client requests.
Requests for URLs that begin with /abc are sent to service group sg-abc.
Likewise, requests for URLs that begin with /123 are sent to service
group sg-123.
134 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

An HTTP template can be configured with only one type of service-group
switching, URL switching or host switching.
Note:
Match Options
URL / host switching selects a service group based on rules that map part of
the URL string or host (domain name) to the service group. You can use the
following match options in URL / host switching rules:
Starts-with string matches only if the URL or host name starts with the
specified string.
Contains string matches if the specified string appears anywhere
within the URL or host name.

Ends-with string matches only if the URL or host name ends with the
specified string.
These match options are always applied in the following order, regardless of
the order in which the rules appear in the configuration. The service group
for the first match is used.
Starts-with
Contains
Ends-with
If a template has more than one rule with the same option (starts-with, contains, or ends-with) and a URL or host name matches on more than one of
them, the most-specific match is always used. For example, if a template
has the following rules, requests for host www.ddeeff.org will always be
directed to service group http-sgf:
host-switching contains d service-group http-sgd
host-switching contains dd service-group http-sge
host-switching contains dde service-group http-sgf
If you use the starts-with option with URL switching, use a slash in front of
the URL string. For example:
url-switching starts-with /urlexample service-group http-sg1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
135 of 950

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.
USING THE CLI

Enter one of the following commands at the configuration level for the
HTTP template:
url-switching
{starts-with | contains | ends-with} url-string
service-group service-group-name
136 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

host-switching
{starts-with |contains | ends-with} host-string
CLI Example
The following commands implement the URL switching configuration
shown in Figure 40 on page 134.
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
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 template.
By default, the service-group option is disabled in cookie persistence templates. 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
137 of 950

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 41 shows an example.
FIGURE 41
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.
138 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

If the clients 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 clients 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 switching, the AX device inserts a cookie into the server's reply, to ensure that the
same server is used the next time URL switching selects sgabc. The first
time service group sg123 is selected by URL switching, the AX device
inserts a second cookie into the servers 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 clients
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 following 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.
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.
Note:
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.
Set-Cookie: cookiename=rserverIP
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
139 of 950

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 service group selected by URL switching or host switching. URL switching or host switching is still used for every request.
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 service group selected by URL switching or host switching. URL
switching or host switching is still used for every request.
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 configuration 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 following command: match-type service-group
To use the service-group option with server-level granularity, enter the following 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
140 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

URL Failover
Using URL / Host Switching along with Source IP Persistence

By default, if URL / host switching is configured along with source IP persistence, 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 servicegroup option in the source IP persistence template.
For more information, see the description of the slb template persist
source-ip command in the Config Commands: SLB Templates chapter of
the AX Series CLI Reference.
URL Failover
The AX device can send an HTTP 302 Redirect message to a client when
the real servers for the URL requested by the client are unavailable.
FIGURE 42
b y
URL Failover
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
141 of 950

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 template, and binding the template to the virtual port.
Note:
The URL failover option does not affect redirect messages sent by real
servers. To alter redirect messages from real servers, use the URL redirect-rewrite option instead. (See URL Redirect Rewrite on page 159.)
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

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
142 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

5xx Retry and Reassignment
The following commands bind the HTTP template to virtual port 80:
AX(config-slb virtual server-slb virtua...)#template http urlfailover
5xx Retry and Reassignment

By default, if a real server replies to a request with a 5xx status code (for
example, HTTP 503 Service Unavailable), the AX device forwards the
error to the client.
HTTP templates have an option to override this behavior. You can configure
the AX device to retry sending a clients 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 status code, the AX device will not reassign the request to s3, because the maximum 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 sending 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 or

source-IP persistence are configured on the virtual port. These features
override the server re-selection.
Note:
Use of this HTTP template option also requires the strict-transactionswitch option to be used in the same HTTP template. (See Strict Transaction Switching on page 161.)
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
143 of 950

Content Compression
The first command continues to use the service port and server for client
requests, even after a reassignment has occurred. The second command
stops using the service port and server for 30 seconds after a reassignment
occurs.
The num option specifies the number of times the AX device will resend the
request to the server before assigning the request to another server. You can
specify 1-3 retries. The default is 3.
An HTTP template can contain only one of the commands shown above.
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
CLI Example
The following commands configure an HTTP template to reselect a server if
the initially selected server responds 4 times to a clients 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
Content Compression
Most types of real servers are able to compress media (content) before sending it to clients. Compression reduces the amount of bandwidth required to
send content to clients.
Although compression optimizes bandwidth, compression also can sometimes 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.
144 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Content Compression
Compression is supported only for HTTP and HTTPS virtual ports. Compression is not supported of fast-HTTP virtual ports.
Note:
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 clients 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 content before sending it in the reply. The AX device compresses the content,
then sends the reply with the compressed content to the client.
If you still want the server to compress some content, you can configure the
AX device to leave the Accept-Request field unchanged. In this case, compression 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:
b y
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).
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
145 of 950

Content Compression
Hardware-Based Compression
Hardware-based compression is available using an optional hardware module in the following AX models: AX 2100, AX 2200, AX 3100, AX 3200,
and AX 5200.
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 compression level, are used.
Note:
146 of 950
Hardware-based compression is automatically set on the module and can

not be set using a template. The module always uses the same compression level, regardless of the compression level configured in an HTTP
template.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Content Compression
How the AX Device Determines Whether to Compress a File

The AX device uses the following process to determine whether to compress a file before sending it to a client.
FIGURE 43
Note:
b y
Content Compression
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.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
147 of 950

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 126.)
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 Compression 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 > Service > SLB.
b. On the menu bar, select Global.
c. Select Enabled next to Hardware Compression.
d. Click OK.
Note:
148 of 950
If the Hardware Compression option is not present, your AX device does

not contain a compression module.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 command 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 compression 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 compression. 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
149 of 950

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
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.
Note:
CLI Example
The following commands configure an HTTP template called "http-compress" that uses compression level 5 to compress files with media type
"application" or "image". Files with media type "application/zip" are explicitly excluded from compression.
AX(config)#slb template http http-compress
AX(config-HTTP template)#compression enable
AX(config-HTTP template)#compression level 5
AX(config-HTTP template)#compression content-type image
AX(config-HTTP template)#compression exclude-content-type application/zip
The following command displays HTTP compression statistics. The counters are in bytes and apply to all HTTP compression configured in all HTTP
templates on the AX device. The compression counters are shown in bold
type.
AX(config-HTTP template)#show slb http-proxy
Total
-----------------------------------------------------------------Curr Proxy Conns 58
Total Proxy Conns 49
HTTP requests 306
HTTP requests(succ) 269
No proxy error 0
Client RST 17
Server RST 0
No tuple error 0
Parse req fail 0
150 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Client IP Insertion / Replacement
Server selection fail 0
Fwd req fail 0
Fwd req data fail 0
Req retransmit 0
Req pkt out-of-order 0
Server reselection 0
Server premature close 0
Server conn made 50
Source NAT failure 0
Tot data before compress 1373117
Tot data after compress 404410
The following commands enable hardware-based compression and display

statistics for the feature:
AX(config)#slb hw-compression
AX(config)#show slb hw-compression
Hardware compression device is installed.
Hardware compression module is enabled.
Total
-----------------------------------------------------------------total request count
177157
total submit count
177157
total response count
177157
total failure count
last failure code
compression queue full
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 160 on page 608.)
However, in configurations where IP source NAT is enabled for SLB, the
clients 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 translated the clients IP address.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
151 of 950

To add the clients 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 clients IP address into the header of the clients
GET request before sending the request to a real server.
Figure 44 shows an example of client IP insertion.
FIGURE 44
152 of 950
Client IP Insertion
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

In this example, SLB source NAT changes the source address of the clients
GET request from 192.168.100.3 to 10.20.20.11. However, the clients
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 clients 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.
To insert HTTP header fields with other types of values, or to erase fields,
see Header Insertion / Erasure on page 154.
Note:
Replace Option
By default, the client IP address is appended to addresses already in the target 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 / replacement.
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
153 of 950

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

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 client 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 maximum of 8 headers.
154 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 clients IP address, see Client IP

Insertion / Replacement on page 151.
Note:
Header insertion is not supported on fast-HTTP virtual ports.
Configuring Header Insertion / Replacement

To configure header insertion or replacement, specify the header (the
field:value pair), and the insert or replace option. The insert / replace option
can be one of the following:
Insert-always always inserts the field:value pair. If the request already
contains a header with the same field name, the new field:value pair is
added after the existing field:value pair. Existing headers are not
replaced.
Insert-if-not-exist inserts the header only if the packet does not already
contain a header with the same field name.

Default behavior (neither of the options above) inserts the header. If
the packet already contains one or more headers with the specified field
name, this option replaces the first header.
Effects of the Insert / Replace Options
Here are some examples of the effects of the insert / replace options: insertalways, insert-if-not-exist, and the default (no options). For these examples,
assume that a clients 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
...
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
155 of 950

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 clients 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 clients header is changed only if it does not
contain any Cookie headers. Therefore, the client request in this example
is unchanged:
GET / HTTP/1.1
Cookie: a=1
Cookie: b=2
...
Effect When Default Behavior (Neither Option Above) Is Used
If you configure an HTTP template to insert Cookie: c=3, but you do not
use either the insert-always or insert-if-not-exist option, the header is
always inserted into the request. If the packet already contains a Cookie
header, the header is replaced. If the packet contains multiple Cookie
headers, the first one is replaced. Here is the result:
GET / HTTP/1.1
Cookie: c=3
Cookie: b=2
...
USING THE GUI

2. Click 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-
156 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 command:
[no] response-header-insert field:value
[insert-always | insert-if-not-exist]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
157 of 950

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.
158 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
159 of 950

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 configuration level for the HTTP template:
redirect-rewrite secure {port tcp-portnum}
The default SSL port number (tcp-portnum) is 443. If you do not specify 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 sending a request to the redirect URL.
160 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Strict Transaction Switching
If you do specify the port number, the AX includes the port number in the
redirect URL.
CLI Example
The following commands configure the AX device to change unsecure
URLs to secure URLs in redirect messages.
The following commands configure the HTTP template. Redirect URLs that
begin with http:// are changed to https://. The URLs in the redirect messages 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 session. After the initial selection, all requests within that session are automatically 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:
b y
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.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
161 of 950

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
162 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 balancing 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 45 shows an example of an FTP load balancing solution.
FIGURE 45
b y
FTP Load Balancing
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
163 of 950

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 provides the HTML pages for the download site.
The AX device supports both the passive and port FTP modes.
The AX Series device sends all HTTP requests to server ftp-2, and balances
FTP requests among servers ftp-2, ftp-3, and ftp-4. In this example, the
load-balancing method is changed from the default, round robin, to
weighted round robin.
By assigning a weight to a real server and using a weighted load-balancing
metric, you can bias load-balancing decisions to favor that server. This
example assumes that the servers have equivalent capacity and performance. The differing weights compensate for the greater load to be placed
on the server that is handling the HTTP requests.
Service Groups
This example uses a single service group containing all three servers. To
provide weighted load balancing as described above, the load balancing
method is changed from the default (round robin) to weighted round robin.
Templates
In this example, two TCP templates are required.
For HTTP, the default TCP template is used. You do not need to explic-
itly bind this template to the HTTP port on the virtual server. The AX
device automatically binds this template to a virtual TCP port on a virtual 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 template 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 template 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.
164 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FTP Load Balancing
For more information about templates, see the following:
Service Template Parameters on page 819
Server and Port Templates on page 353
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 373.)

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 servers HTTP
port and enable health checking of the port, using the HTTP health
method configured in step 1.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
165 of 950

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 template.
USING THE GUI

To configure the health monitors
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.
166 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 46
Config > Service > Health Monitor (for HTTP monitor)
FIGURE 47
monitor)
Config > Service > Health Monitor - Method section (for FTP
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
167 of 950

FIGURE 48
monitors)
Config > Service > Health Monitor (showing configured health
To configure the real servers

2. Select Server on the menu bar.
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 166. (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.
168 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 49
b y
Config > Service > SLB > Server (ftp-2)
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
169 of 950

FIGURE 50
170 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 51
FIGURE 52
servers)
Config > Service > SLB > Server (showing configured real
Note:
b y
The Health Monitor column shows the Layer 3 (ICMP ping) health monitors for the real servers, not the Layer4-7 health monitors for individual
server ports.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
171 of 950

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 53
Config > Service > Template > L4 > TCP
To configure a service group for HTTP

2. Select Service Group on the menu bar, if not already selected.
3. Click Add.
4. 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 example, select Weighted Round Robin.
7. Enter the real servers IP address in the Server field.
8. Enter the protocol port in the Port field.
172 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

9. Click Add. The server and port appear in the member list. Repeat for
each combination of server and port. In this example, add member
10.10.10.2 for port 80 and again for port 21 to service group http-grp.
10. Click OK. The new service group appears in the service group table.
FIGURE 54
Config > Service > Service Group (for HTTP)
To configure a service group for FTP

Repeat the procedure in To configure a service group for HTTP on
page 172, 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
173 of 950

174 of 950
FIGURE 55
Config > Service > Service Group (for FTP)
FIGURE 56
Config > Service > Service Group (service groups added)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

To configure the virtual server
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.
6. In the Port section, click Add. The Virtual Server Port section appears.
7. In the Type drop-down list, select the service type.
In this example, there are two services, HTTP and FTP. Select HTTP
first and go to the next step.
8. Edit the number in the Port field to match the protocol port that clients
will request at the virtual IP address.
9. Select the service group from Service Group drop-down list.
In this example, select http-grp for HTTP and ftp-grp for FTP.
10. Click OK. The port and service group appear in the virtual port list.
11. Repeat from step 6 for the FTP service.
In this example, select the TCP template you configured in To configure the TCP template for FTP on page 172.
12. Click OK. The new virtual server appears in the virtual server table.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
175 of 950

176 of 950
FIGURE 57
Config > Service > Virtual Server
FIGURE 58
(for HTTP)
Config > Service > Virtual Server - Virtual Server Port section
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 59
(for FTP)
Config > Service > Virtual Server - Virtual Server Port section
FIGURE 60
Config > Service > Virtual Server - Port section (ports added)
FIGURE 61
Config > Service > Virtual Server (virtual server added)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
177 of 950

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 command for each port number to be load balanced.
To assign the HTTP or FTP health monitor to a port, use the following
command at the configuration level for the port.
3. To configure the TCP template for FTP, use the following commands:
slb template tcp template-name
This command creates the TCP template and changes the CLI to the
configuration level for the template.
idle-timeout seconds
178 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The idle-timeout command specifies the number of seconds a TCP session can remain idle. For this example, set the idle timeout to 15000 seconds.
4. To configure a service group for HTTP, use the following commands:
This command creates the service group and changes the CLI to the configuration 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.
6. To configure the virtual server, use the following commands:
This command creates the virtual server and changes the CLI to the configuration level for it.
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
179 of 950

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
180 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

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

AX(config)#slb virtual-server ftp-vip 192.168.10.21
AX(config-slb virtual server-slb virtua...)#service-group http-grp
AX(config-slb virtual server)#port 21 ftp
AX(config-slb virtual server-slb virtua...)#service-group ftp-grp
AX(config-slb virtual server-slb virtua...)#template tcp ftp-longidletime
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
181 of 950

182 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
IP source NAT is not supported on SIP virtual ports.
Note:

AX Series devices support SIP load balancing. SIP load balancing balances
SIP registration messages from clients across a service group of SIP Registrar servers. SIP load balancing enables you to offload registration processing from other SIP servers so those servers can more efficiently process
other SIP traffic.
Figure 62 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 184.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
183 of 950

FIGURE 62
SIP Load Balancing
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.
184 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 template to the port.
The following sections provide detailed steps and examples.
USING THE GUI

1. Configure a SIP health monitor for the Registrar servers:
a. Select Config > Service > Health Monitor.
b. Select Health Monitor on the menu bar.
c. Click Add.
d. 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 number 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 Monitor 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 Monitor table.
3. Configure a real server for the SIP Registrar server:
b. Select Server on the menu bar.
c. Click Add.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
185 of 950

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.
The steps are the same as the steps for adding the Registrar servers. (See
Figure 66.)
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 > 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.
186 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
187 of 950

GUI CONFIGURATION EXAMPLE

The following GUI examples show the configuration steps.
FIGURE 63
(example for Registrar servers)
188 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 64
(example for other SIP servers)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
189 of 950

190 of 950
FIGURE 65
FIGURE 66
added
Config > Service > SLB > Server - Registrar and Proxy servers
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 67
Config > Service > Service Group (registrar group)
FIGURE 68
Config > Service > Service Group - groups added
FIGURE 69
Config > Service > Template > Application > SIP
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
191 of 950

192 of 950
FIGURE 70
added
Config > Service > Template > Application > SIP - template
FIGURE 71
Config > Service > Virtual Server - Port section
FIGURE 72
Config > Service > Virtual Server - server added
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

1. To configure a SIP health monitor using the SIP health method, use the
following commands:
Enter this command at the global Config level.
method sip [register [port port-num]]
Enter this command at the configuration level for the health method.
The SIP health monitor sends an OPTION request to port 5060 by
default.
To send a REGISTER request instead, use the register option. To send
the request to a port other than 5060, use the port option to specify the
port number.
2. To configure a real server for a SIP Registrar server, add the SIP port to
it, and apply the SIP health monitor to the port, use the following commands:
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
193 of 950

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


The commands in the following example implement the SIP load balancing
configuration shown in Figure 62 on page 184.
The following commands configure the SIP health monitors:
AX(config)#health monitor sip_monitor
AX(config-health:monitor)#method sip
AX (config-health:monitor)#exit
AX(config)#health monitor sipreg_monitor
AX(config-health:monitor)#method sip register
AX (config-health:monitor)#exit
The following commands configure the Registrar servers:

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

AX(config)#slb server Proxy3 10.10.20.11
AX (config-real server-node port)#health-check sip_monitor
AX(config)#slb server Proxy4 10.10.20.12
AX (config-real server-node port)#health-check sip_monitor
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
195 of 950

The following commands configure the service groups:
AX(config)#slb service-group Registrar_gp udp
AX(config-slb service group)#member Registrar1:5060
AX(config-slb service group)#member Registrar2:5060
AX(config)#slb service-group sip5060 udp
AX(config-slb service group)#member Proxy3:5060
AX(config-slb service group)#member Proxy4:5060
The following commands configure the SIP template:

AX(config)#slb template sip Registrar_template
AX(config-SIP LB template)#registrar service-group Registrar_gp
AX(config-SIP LB template)#header-insert Max-Forwards:22
AX(config-SIP LB template)#header-replace Max-Forwards 15
AX(config-SIP LB template)#header-erase Contact
AX(config-SIP LB template)#exit
The following commands configure the VIP for the SIP registrar:
AX(config)#slb virtual-server sip1 192.168.20.1
AX(config-slb virtual server)#port 5060 sip
AX(config-slb virtual server-slb virtua...)#service-group sip5060
AX(config-slb virtual server-slb virtua...)#template sip Registrar_template
196 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 73 shows an example of this feature.
FIGURE 73
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 appropriate 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 separate connections for each SIP client. Figure 74 shows an example.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
197 of 950

FIGURE 74
SIP Multiplexing
In this example, each SIP server can handle a maximum of 256 client connections. 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 connectionreuse 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 connection for multiple clients.
While the AX device is sending a client request on a connection, the connection 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 clients request before freeing the connection. Figure 75 shows an example.
FIGURE 75
198 of 950
SIP Connection Reuse
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
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 clients request. Instead, the AX
device frees the connection only after receiving a response to the request.
Note:
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 74, 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 connections for new clients.
Client IP insertion When this SIP template feature is enabled, the AX
device inserts an X-Forwarded-For header into the clients request

before forwarding the request to the SIP server. The header contains the
clients 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 200)
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 clients request by the AX device, in replies to the client.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
199 of 950

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 reusable 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 76 shows an example of a configuration that uses both SIP keepalive
features.
FIGURE 76
Note:
200 of 950
SIP Keepalive
If connection reuse is configured, even if client keepalive is disabled, the

AX device will respond to a client SIP ping with a pong.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 protocol 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 servers 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
201 of 950

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 template 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.
202 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

The GUI items that are new in AX Releases 2.2.2 are the additional options
for SIP templates, and the following new service types for virtual ports:
SIP-TCP
SIP-TLS
Otherwise, the GUI procedures for creating the configuration items needed
for SIP over TCP/TLS are the same as in previous releases.
The following figures show examples of the GUI configuration pages for
implementing the SIP multiplexing configuration shown in Figure 74 on
page 198.
FIGURE 77
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
203 of 950

FIGURE 78
204 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 79
FIGURE 80
Config > Service > Template > Connection Reuse
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
205 of 950

206 of 950
FIGURE 81
Config > Service > SSL Management - import certificate
FIGURE 82
Config > Service > SSL Management - import key
FIGURE 83
Config > Service > Template > SSL > Client SSL
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 84
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
207 of 950

FIGURE 85
Config > 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 configuration.
To Configure a SIP over TCP Health Monitor
Use the following commands:
[no] health monitor monitor-name
Use this command at the global configuration level of the CLI. This command changes the CLI to the configuration level for the health monitor,
where the following command is available:
[no] method sip tcp
208 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

To Configure Real Servers
Use this command at the global configuration level of the CLI. For the
ipaddr, use the SIP servers 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 listens 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
Use this command at the global configuration level of the CLI. This command 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 configuration.
To Configure a SIP Template
Use the following commands.
In the current release, the SIP template options described below are valid
only for SIP over TCP/TLS. Other SIP template options, such as headerinsert, header-erase, and so on are valid only for SIP over UDP.
Note:
slb template sip template-name

Use this command at the global configuration level of the CLI. This command changes the CLI to the configuration level for the template, where the
following commands are available.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
209 of 950

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
servers pong reply.
If the server does not reply to a SIP ping within the connection-reuse timeout, the AX device closes the connection. (The connection-reuse timeout is
configured by the timeout command at the configuration level for the connection-reuse template.)
You can specify 5-300 seconds. The default is 30 seconds.
select-client-fail {string | drop}
select-server-fail {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 select-client-fail command. To change the response when a SIP server can not be reached, use the
select-server-fail 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:
210 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 201.)
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.
To Configure a Connection-Reuse Template
slb template connection-reuse template-name
Use this command at the global configuration level of the CLI. This command changes the CLI to the configuration level for the template, where the
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. The default is 100.
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.
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
211 of 950

[no] slb ssl-load
{certificate file-name | private-key file-name}
[use-mgmt-port]
url
The use-mgmt-port option uses the AX devices 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 communicate with the remote server.
The url specifies the file transfer protocol (tftp:, ftp:, scp:, or rcp:), username (if required), and directory path. You can enter the entire URL on the
command line or press Enter to display a prompt for each part of the URL.
If you enter the entire URL and a password is required, you will still be
prompted for the password. To enter the entire URL:
tftp://host/file
ftp://[user@]host[:port]/file
scp://[user@]host/file
rcp://[user@]host/file
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 command changes the CLI to the configuration level for the template. For information 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 command changes the CLI to the configuration level for the virtual server,
where the following commands are available:
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 commands are available:
212 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 configuration shown in Figure 74 on page 198, and show SIP SLB statistics.
The following commands access the configuration level of the CLI and configure 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

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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
213 of 950

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)#select-client-fail "480 Temporarily Unavailable"
AX(config-SIP LB template)#select-server-fail "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 authenticating 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
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
214 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
CLI Example
The following command shows SIP SLB statistics:
AX#show slb sip
Total
-----------------------------------------------------------------Curr Proxy Conns
0
Total Proxy Conns
115
Client message
125
Client message (fail)
0
Server message
12
Server message (fail)
0
Client request
119
Client request (succ)
12
Client RST
0
Server RST
113
Parse message fail
0
Server selection fail
0
Server conn made
115
Source NAT failure
0
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
215 of 950

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 86
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 servers
IP address or subnet as the destination address.
216 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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] pass-real-server-ip-for-acl acl-id
The acl-id specifies an extended ACL ID (100-199).
CLI Example
The commands in this section are applicable to Figure 86.
The following command configures an extended ACL that matches on the
SIP servers subnet and on the database servers subnet:
AX(config)#access-list 101 permit ip 10.10.10.0 /24 10.20.20.0 /24
The following commands configure a SIP template that disables reverse

NAT for traffic that matches the ACL:
AX(config)#slb template sip sip1
AX(config-sip)#pass-real-server-ip-for-acl 101
AX(config-sip)#exit
The following commands bind the SIP template to the SIP virtual port:
AX(config)#slb virtual-server sip-vip 192.168.20.1
AX(config-slb vserver)#port 5060 sip
AX(config-slb vserver-vport)#template sip sip1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
217 of 950

IP NAT for SIP
IP NAT for SIP

The AX device supports IP NAT for SIP. This feature allows clients in a private 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.
Only the SIP signalling packets are NATted. The media packets are not
NATted.
Note:
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 servers.
CLI Example
The following configuration excerpt uses dynamic NAT.
access-list 1 permit any
!
ip address 171.1.1.1 255.255.255.0
ip nat inside
!
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
218 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 125.
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.
The AX device also supports STARTTLS acceleration and encryption.
See STARTTLS for Secure SMTP on page 239.
Note:
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
219 of 950

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 905.
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 dropdown 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. Otherwise, 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.
220 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 protocol 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
221 of 950


FIGURE 87
certificate)
Configure > Service > SSL Management - Import (for the
FIGURE 88
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 key file-name url
The url specifies the file transfer protocol, username (if required), directory path, and filename.
222 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
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 template.
key key-name [passphrase passphrase-string]

The following commands import certificates and keys, and configure a client-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 key sslcertkey.pem ftp:
Password []?*********
File name [/]?sslcertkey.pem
The following commands configure a client SSL template to use the certificate 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
223 of 950

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 220.)
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 125.)
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 template (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 configuration.
Beginning in AX Release 2.4.x, server-SSL without client-SSL is supported. 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.
224 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 125.
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
225 of 950


FIGURE 89
226 of 950
Configure > Service > SLB > Server
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 90
b y
Configure > Service > SLB > Service Group
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
227 of 950

FIGURE 91
228 of 950
Configure > Service > SLB > Virtual Server
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 92
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 125.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
229 of 950

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
230 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring the SSL Proxy Feature
The following commands configure the VIP to which clients will send
HTTPS traffic:
AX(config)#slb virtual-server v1 10.6.6.6
AX(config-slb virtual server)#port 443 https
AX(config-slb virtual server-slb virtua...)#service-group HTTPS_servers
AX(config-slb virtual server-slb virtua...)#template http HTTPS_1
AX(config-slb virtual server-slb virtua...)#template client-ssl sslcert-tmplt

To configure the AX device as an SSL proxy for a TCP service:
1. Configure client SSL. (See Configuring Client SSL on page 220.)
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 clientSSL template.
USING THE GUI

1. To configure real servers:
c. Click Add. The General tab appears.
d. On the General tab, enter a name for the server and enter its IP
address, in the Name and IP Address fields.
e. On the Port tab, enter the port number in the Port field.
f. In the Protocol drop-down list, select TCP, if not already selected.
g. Select the health monitor, if your configuration will use one.
h. Click Add. The port appears in the Port list.
i. Click OK. The server appears in the server table.
j. Repeat for each real server.
2. To configure a service group for the servers and add them to the group:
b. Click Add.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
231 of 950

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.
232 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010


FIGURE 93
b y
Configure > Service > SLB > Server
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
233 of 950

FIGURE 94
234 of 950
Configure > Service > SLB > Service Group
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 95
Configure > Service > SLB > Virtual Server
FIGURE 96
Configure > Service > SLB > Virtual Server - Port tab
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
235 of 950

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,
3. To configure a virtual server and port for the TCP service, use the following commands:
port port-number ssl-proxy
236 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010


The following commands configure proxy SSL for POPS. The same commands can be used to configure SSL proxy for other TCP services. In each
case, the feature is enabled by the ssl-proxy option of the port command at
the virtual server configuration level of the CLI.
AX(config)#slb server POP1 10.5.5.2
AX(config)#slb server POP2 10.5.5.3
The following commands configure a service group for the POP servers:
AX(config)#slb service-group POP_servers tcp
AX(config-slb service group)#member POP1:110
AX(config-slb service group)#member POP2:110
The following commands configure the VIP to which clients will send
POPS traffic:
AX(config-slb virtual server)#port 110 ssl-proxy
AX(config-slb virtual server-slb virtua...)#service-group SMTP_servers
AX(config-slb virtual server-slb virtua...)#template client-ssl sslcert-tmplt
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
237 of 950

238 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 extension to SMTP that enables you to secure mail traffic to and from your legacy 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 servers is clear (not encrypted).
Figure 97 shows an example of the STARTTLS feature.
FIGURE 97
b y
STARTTLS
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
239 of 950

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 command first
Disable SMTP commands By default, the VRFY, EXPN, and TURN
commands are allowed. You can disable support of any of these commands. In this case, if the client tries to issue a disabled SMTP command, 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 98
240 of 950
STARTTLS Domain Switching
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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-serverdomain.
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 clients will send SMTP traffic, and add the SMTP service group and
SMTP template to the port.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
241 of 950

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 231.)
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 STARTTLS.
c. To disable STARTTLS commands sent by the client, select the commands 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.
242 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
243 of 950


FIGURE 99
244 of 950
Config > Service > Template > Application > SMTP
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 100
Config > Service > SLB > Virtual Server - Port section
USING THE CLI

1. To import a certificate and its key, use the following commands at the
global Config level of the CLI:
slb ssl-load certificate file-name url
slb ssl-load key file-name url
The url specifies the file transfer protocol, username (if required), directory path, and filename.
tftp://host/file
2. To configure a client SSL template, use the following commands:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
245 of 950

cert cert-name
Enter this command at the configuration level for the client SSL template.
key key-name [passphrase passphrase-string]
3. To configure a real server for an SMTP server, use the following commands:
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 commands 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 support on the VIP that uses the SMTP template.
The domain-switching command is required only if you have multiple
service groups and you want to direct SMTP clients to specific service
groups based on the client's domain.
6. To configure a virtual server and port for the SMTP address to which
clients will send SMTP traffic, add the SMTP service group, and add the
246 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SMTP and client SSL templates to the port, use the following commands:
port port-num smtp
template smtp template-name
Displaying STARTTLS Statistics
To display STARTTLS statistics, use the following command at the Privileged 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 key tlscertkey.pem ftp:
Password []?*********
File name [/]?tlscertkey.pem
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
247 of 950

The following commands configure a client SSL template to use the certificate 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
248 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview

This chapter describes streaming-media load balancing and how to configure it.
Overview
AX Series devices support content-aware load balancing of the following
widely used streaming-media types:
Real Time Streaming Protocol (RTSP)
Microsoft Media Server (MMS)
The AX Series also supports load balancing of Session Initiation Protocol

(SIP) sessions. For information, see SIP Load Balancing on page 183.
Note:
Figure 101 shows an example of a streaming-media load balancing solution.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
249 of 950

Overview
FIGURE 101
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.
250 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring Streaming-Media SLB
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.
Note:
Templates
By default, the default TCP template is applied to RTSP and MMS traffic.
(For information, see TCP Template Parameters on page 854.)
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 procedures for other types of SLB.
USING THE GUI

To configure a streaming-media template:
2. Select Application > RTSP on the menu bar.
3. Click Add.
4. Enter a name for the template.
5. Configure other options, if applicable to your configuration.
6. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
251 of 950

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 configuration 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 servername 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 configuration level for it.
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 balanced. 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.
252 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010


AX(config)#slb server stream-rs1 192.168.66.21
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
253 of 950

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-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
254 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Layer 4 TCP/UDP Load Balancing

This chapter describes Layer 4 load balancing of TCP and UDP traffic and
The Layer 4 load balancing described in this chapter requires you to specify the protocol port numbers to be load balanced. To load balance traffic
based solely on transport protocol (TCP, UDP, or other), see IP Protocol
Load Balancing on page 263.
Note:
Overview
In addition to load balancing for well-known and widely used types of services 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 102 shows an example of a Layer 4 load balancing implementation.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
255 of 950

Overview
FIGURE 102
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 application.
Note:
To configure deeper packet inspection for custom applications, you can

use aFleX policies. For example, you can configure an aFleX policy to
examine the byte value at a certain position within each client request
packet and select a server based on the value of the byte. For information
about aFleX policies, see the AX Series aFleX Reference.
SERVICE GROUPS
This example uses a single service group that contains all the real servers.
The service group uses the default load balancing method (round robin).
256 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
VIRTUAL SERVER
The custom application on the real servers is accessed at TCP port 1020 by
clients through virtual IP address 192.168.55.55.
TEMPLATES
The AX device has default TCP and UDP templates. You can use the
default template or configure another TCP or UDP template and use that
one instead. If your Layer 4 load balancing configuration is for a TCP application and you do not bind a TCP template to the virtual port, the default
TCP template is used. For a UDP application, the default UDP template is
used unless you bind another UDP template to the virtual port.
One of the parameters you can configure in TCP and UDP templates is the
idle time. Depending on the requirements of your application, you can
reduce or increase the amount of time the AX device allows a session to
remain idle.
For UDP transaction-based applications, another parameter you can adjust
is how quickly connections are terminated after a server reply is received.
For example, if there are licensing costs associated with active sessions, you
can minimize unnecessary costs by quickly terminating idle sessions, and
immediately terminating connections that are no longer needed.
For more information about the parameters controlled by TCP and UDP
templates, see the following sections:
TCP Template Parameters on page 854
UDP Template Parameters on page 857
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 persistence 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 850.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
257 of 950

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

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

1. To configure the real servers:
c. Click Add.
d. In the General section, configure general settings for the server.
e. In the Port section, enter the protocol port number of the application
in the port field.
f. In the Type drop-down list, select the transport protocol for the
application, TCP or UDP.
g. Configure other port settings if needed, then click Add. The application port appears in the Port list.
h. Click OK. The real server appears in the real server table.
258 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

2. To configure the service group:
a. Select Config > Service > SLB, if not already selected.
b. Select Service Group on the menu bar.
c. Click Add.
d. In the Service Group section, enter a name for the service group.
e. In the Type drop-down list, select the transport protocol for the
f. In the Server section, select a server from the Server drop-down list.
g. Enter the protocol port number in the Port field.
h. Click Add.
i. Repeat step f through step h for each server and port.
j. Click OK. The service group appears in the Service Group table.
3. To configure a custom TCP or UDP template:
b. Select L4 > TCP or L4 > UDP on the menu bar.
c. Click Add.
e. Edit template settings as needed for your application. (See TCP
Template Parameters on page 854 or UDP Template Parameters
on page 857.)
f. Click OK.
4. To configure a source-IP persistence template:
b. Select Persistent > Source IP Persistent on the menu bar.
c. Click Add.
e. Edit template settings as needed for your application. (See SourceIP Persistence Template Parameters on page 850.)
f. Click OK.
5. To configure the virtual server:
a. Select Config > Service > SLB, if not already selected.
c. Click Add.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
259 of 950

d. Enter a name for the virtual server.
e. In the IP Address field, enter the virtual IP address to which clients
will send requests.
f. Select or enter other general settings as needed.
g. In the Port section, click Add. The Virtual Server Port section
appears.
h. In the Type drop-down list, select the transport protocol for the
i. Enter the application port number in the Port field.
j. If you configured any custom templates, select them from the dropdown lists for each template type.
k. Enter or select other values as needed.
l. Click OK. The port appears in the port section.
m. Click OK again. The virtual server appears in the virtual server list.
USING THE CLI

This command changes the CLI to the configuration level for the real
server, where you can use the following command to add the TCP or
UDP port to the server:
port port-num {tcp | udp}
The port-num specifies the protocol port number. In this example, specify 1020.
This command adds the port and changes the CLI to the configuration
level for the port, where additional commands are available. (For information, see the AX Series CLI Reference.)
2. To configure the service group, use the following commands:
slb service-group group-name {tcp | udp}
This command changes the CLI to the configuration level for the service
group, where you can use the following command to add the real servers
and service ports to the group:
The portnum is the protocol port number of the service to be load balanced. In this example, specify tcp-2:1020. Repeat the command for
tcp-3:1020 and tcp-4:1020.
260 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

3. To configure a custom TCP or UDP template, use the following commands 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 configuration level for the template, where additional commands are available.
(See TCP Template Parameters on page 854 or UDP Template
Parameters on page 857. Also see the Config Commands: SLB Templates chapter in the AX Series CLI Reference.)
4. To configure a source-IP persistence template, use the following command at the global configuration level of the CLI:
slb template persist source-ip template-name
server, where you can use the following command to add the virtual port
to the server:
port port-number {tcp | udp}
For this example, specify tcp and 1020 as the port-num.
The port command changes the CLI to the configuration level for the
virtual port, where you can use the following command to bind the virtual port to the service group:
The group-name is the name of the service group configured in step 2.
If you configured a custom template, use the following command to
bind the template to the service group:
template template-type template-name
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
261 of 950

CLI EXAMPLE
AX(config)#slb server tcp-2 10.10.10.2

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

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

AX(config)#slb virtual-server web-vip 192.168.55.55
AX(config-slb virtual server-slb virtua...)#service-group tcp-sg
AX(config-slb virtual server-slb virtua...)#template persist source-ip
app1020persist
262 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview

This chapter describes load balancing of traffic based solely on transport
protocol (TCP, UDP, or other), without the need to specify the protocol port
numbers to be load balanced.
Overview
IP protocol load balancing enables you to easily load balance traffic based
solely on whether the traffic is TCP, UDP, or other (not UDP or TCP), without the need to specify the protocol port numbers to be load balanced.
You can combine IP protocol load balancing with other load balancing configurations. For example, you can use IP protocol load balancing along with
HTTP load balancing. In this case, HTTP traffic to the VIP HTTP port number is load balanced separately from traffic to other port numbers.
Figure 103 shows an example of an IP protocol load balancing deployment.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
263 of 950

Overview
FIGURE 103
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.
264 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 traffic, you can use the same service group for multiple traffic types.
In IP protocol load-balancing configurations, port 0 (zero) is used as a wildcard port and matches on any port number. In configurations where some
protocol port numbers are explicitly specified, SLB for those ports takes
precedence over SLB for the wildcard port (0). In the example above, the
service group configured for TCP port 80 is always used for client requests
addressed to that port, instead of a service group configured for the wildcard
port.
Health checking does not apply to the wildcard port. When you configure IP
protocol load balancing, make sure to disable health checking of port 0. If
you leave health checking enabled, the port will be marked down and the
clients 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 servers 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 specified, 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
265 of 950

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 configuration. 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.
266 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
For load balancing of non-TCP/UDP traffic, you can specify TCP or UDP
as the transport protocol, in the configurations of the real server ports and
service groups. If the port number is 0 and the service type on the virtual
port is others, the AX device will load balance the traffic as non-TCP/
UDP traffic.
Note:
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 > 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 > Service > SLB > Virtual
Server), select TCP, UDP, or Others in the Type drop-down list.
USING THE CLI

The following commands configure the real servers shown in Figure 103 on
page 264.
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 specified port numbers is still supported as in previous releases.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
267 of 950

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
268 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
269 of 950

270 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring a Wildcard VIP
Wildcard VIPs
You can create SLB configurations that use wildcard VIPs and wildcard virtual ports. A wildcard VIP matches on any destination IP address. Likewise,
a wildcard virtual port matches on any port number.
Wildcard VIPs enable you to configure a feature that applies to multiple
VIPs, without the need to re-configure the feature separately for each VIP.
To specify the subset of VIP addresses and ports for which the feature
applies, you can use an ACL. If applicable, the ACL also can specify the
subset of clients allowed to access the VIPs.
You can use wildcard VIPs for all types of load balancing:
SLB
IP load balancing
Transparent Cache Switching (TCS)
Link Load Balancing (LLB)
Firewall Load Balancing (FWLB)
Use of wildcard VIPs and interface-based SYN cookies is not supported.
Note:

The procedure for configuring a wildcard VIP is the same as the procedure
for configuring a standard VIP, except you have the option to bind an ACL
to the wildcard VIP.
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 or ::. Likewise, multiple ports that have port number 0 are allowed.
In the current release, wildcard ports must have service type TCP or HTTP.
Other service types are not supported on wildcard ports in the current
release.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
271 of 950

Promiscuous VIP support must be enabled on the interface connected to clients 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 possible, to permit only the IP addresses that should be treated as VIPs and
deny all other IP addresses.
Default Wildcard VIP
The AX device can have multiple wildcard VIPs, bound to different ACLs.
However, the AX device can have only one IPv4 or IPv6 wildcard VIP that
is not bound to any ACL. This is the default wildcard VIP. The default wildcard VIP is used for traffic that does not match any of the ACLs bound to
other 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 Wildcard VIP Traffic
AX Release 2.0.2 and later supports forwarding of wildcard VIP traffic that
is not bound to a service group. The AX device creates a session for the 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.
In AX releases prior to 2.0.2, Layer 4 traffic for a wildcard VIP that is not
bound to a service group is dropped.
USING THE GUI

To configure a wildcard VIP:
3. Click Add. The General section appears.
4. In the General section, enter a name for the virtual server in the Name
field.
272 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

5. Select the Wildcard checkbox next to the Name field. Selecting this
checkbox causes the Access List drop-down list to appear in place of the
IP Address field.
6. Select the ACL from the Access List drop-down list.
7. Select the IP version, IPv4 or IPv6.
8. Configure other VIP settings, then click OK.
To enable promiscuous VIP support:
1. Select Network > Interface.
2. Click on the interface name to display the configuration sections for the
interface.
3. Click on VIP to display the configuration fields.
4. Select Enabled next to Allow Promiscuous VIP.
5. Click OK.
FIGURE 104 Config > Service > SLB > Virtual Server - wildcard VIP
configuration
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
273 of 950

FIGURE 105
Config > Network > Interface - VIP section
USING THE CLI

To configure a wildcard VIP, use the following command at the global configuration level of the CLI:
[no] slb virtual-server name {0.0.0.0 | ::}
[acl acl-id]
For an IPv4 wildcard VIP, enter IP address 0.0.0.0. For an IPv6 wildcard
VIP, enter IP address :: (double colon).
If you specify an ACL, the ACL is used to control the clients allowed to
access the VIPs and the VIP addresses managed by the wildcard VIP. The
source address in the ACL filters the clients. The destination address in the
ACL filters the VIPs.
To enable promiscuous VIP support, use the following command at the configuration level for each interface connected to clients:
[no] ip allow-promiscuous-vip
274 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

See the following:
Outbound Link Load Balancing on page 289
Transparent Cache Switching on page 295
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
275 of 950

276 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
Fast-HTTP
HTTP
HTTPS
SSL-proxy
SMTP
Figure 106 shows an example of a SLB-PT deployment that uses a mixed

server farm of IPv4 and IPv6 servers to serve IPv6 clients.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
277 of 950

FIGURE 106
In this example, a server farm consisting of IPv6 and IPv4 servers is configured 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 clients
request to the selected server. If the server is an IPv4 server, the AX device
translates the IP protocol of the clients request from IPv6 to IPv4 before
forwarding it to the IPv4 server. Likewise, when the AX device receives the
serverss reply, the AX device translates the reply from IPv4 to IPv6, then
forwards the reply to the client.
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.
278 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 clients 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. Following the example, the Examples Using Multiple Source NAT Pools on
page 282 section describes how to use multiple pools.
CLI Example
The following commands configure the SLB-PT deployment shown in
Figure 106 on page 278. 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)#ip address 192.168.217.100 255.255.255.0
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:
b y
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 different 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 282. Also see the Network
Address Translation chapter in the AX Series Configuration Guide.)
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
279 of 950

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
280 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010


AX(config)#slb service-group sgv4v6
AX(config-slb service group)#member v4server-1:80
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 certificate 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
281 of 950

The following commands configure the VIP:
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
AX(config-slb virtual server)#port 53 udp
AX(config-slb virtual server-slb virtua...)#template client-ssl cssl
AX(config-slb virtual server)#port 25 smtp
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:

282 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 sourcenat-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 clients request from an IPv6 packet into an
IPv4 packet. The AX device replaces the clients IPv6 address with an IPv4
address from the selected pool. The IPv6 VIP address is replaced with the
servers IPv4 address.
If the clients address does not match the source address in any of the ACLs,
the request is dropped.
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 clients
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 clients original IP address.
Note:
Multiple IPv4 and IPv6 Pools

It is not required to use pools of the same IP type as the IP type used by clients. 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 control access to the real servers. When multiple pools are bound to a virtual
port, the clients IP address must match the source address in at least one of
the ACLs associated with the pools. Otherwise, the clients traffic is
dropped.
Note:
b y
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 Configuration Guide.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
283 of 950

This example builds on the example in Multiple IPv4 Pools on page 282.
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 clients 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 netmask 64
AX(config)#ipv6 nat pool v6natpool-2 2001:32::2020:2020 2001:32::2020:2020 netmask 64
The following commands bind the IPv6 NAT pools to the virtual port:
284 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 information 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 286.)

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

The following stateless SLB 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+Port Hash Balances server load
based on a hash value calculated using both the source and destination
IP addresses and 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.

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
285 of 950

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
IPv6
A given real server can be used in only one stateless SLB service group. A
real server that is in a stateless SLB service group can not be used in any
other service groups.
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 stateless-per-pkt-round-robin method.
Note:
The stateless-per-pkt-round-robin method is valid only for DNS traffic.
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+Port Hash
Stateless Source IP Only Hash
Stateless Per-Packet Round Robin
286 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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:
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
287 of 950

288 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The AX Series supports outbound Link Load Balancing (LLB). Outbound
LLB enables you to balance client-server traffic across a set of WAN links.
In outbound LLB, the clients are located on the internal side of the network.
The servers are located on the external side of the network.
Figure 107 shows an example of outbound LLB.
FIGURE 107
b y
Link Load Balancing
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
289 of 950

In this example, the AX device is configured to balance client traffic across
a set of two WAN links, through next-hop routers 192.168.10.1 and
192.168.20.1.
When the AX device receives a request from a client, the AX device uses
SLB load balancing to select one of the WAN links. The AX device then
uses source IP NAT to translate the clients private IP address into a public
IP address, then sends the clients request to the next-hop router for the
selected WAN link.
When the AX device receives the servers reply to the clients request, the
AX device translates the destination IP address from the NAT address back
into the clients private IP address, then forwards the reply to the client.
Load Balancing Methods
You can use either of the following load balancing methods to load balance
traffic across the WAN links:
Round-robin Selects the links in simple rotation. This results in each
link being selected an equal number of times.

Least-connections Selects the link that has the least current client con-
nections on it. The connection count is based on client connections initiated on the link by the AX device.
The default is round-robin.
Network Address Translation Requirements
In an outbound LLB topology, the next-hop routers for the WAN links must
be able to send the server reply traffic back to the AX device. To ensure that
the server reply traffic passes back through the AX device, use an IP source
NAT pool for each WAN link.
The pools do not need to contain more than a few addresses. The AX device
internally uses a separate protocol port number for each client session on a
pool address.
SLB destination NAT, which is enabled by default, must be disabled. In a
standard SLB configuration, destination NAT is used to translate the server
address (destination IP address) requested by clients from the VIP address
into the servers real address. However, this NAT operation is not applicable
to outbound LLB.
290 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Configuring Link Load Balancing

To configure LLB:
1. Configure an IP source NAT pool for each link to be load balanced. The
address range in a pool must be in the same subnet as the next-hop
routers interface with the AX device.
Configure a pool group and add the pools to it.
2. Configure the AX interfaces connected to the clients. Enable promiscuous VIP support on the interfaces.
3. Configure the AX interfaces connected to the next-hop routers for the
links to be load balanced. (Do not enable promiscuous VIP on these
interfaces.)
4. Configure a real server for each link to be load balanced. Add wildcard
ports (TCP 0, UDP 0, or both) to the server.
You can use Layer 3 health checking (ICMP ping) to check the health of
the routers IP interface. However, the configuration requires health
checking to be disabled on the wildcard ports added for a router. The
router will not respond to these health checks. If you leave health checking enabled on the wildcard ports, the AX device will mark the ports
down and LLB will not work.
Note:
5. Configure a service group for the links (real servers). If the real server
configurations for the links have both TCP and UDP ports, configure a
service group for TCP and another service group for UDP.
6. Configure a virtual server with virtual IP address 0.0.0.0 (the wildcard
VIP address). Using the wildcard VIP address enables the configuration
to work for any destination IP address requested by clients.
Add the wildcard TCP port (TCP 0) and bind it to the TCP service
group. Likewise, add the wildcard UDP port and bind it to the the UDP
service group.
Bind the ports to service group(s). On each port, bind the port to the IP
Source NAT pool group and disable destination NAT.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
291 of 950

CLI Example
The commands in this example implement the LLB configuration shown in
Figure 107 on page 289.
The following commands configure the IP source NAT pools and pool
group:
AX(config)#ip nat pool nat10 192.168.10.3 192.168.10.4 netmask /24
AX(config)#ip nat pool nat20 192.168.20.3 192.168.20.4 netmask /24
AX(config)#ip nat pool-group outbound-nat-group nat10 nat20
The following commands enable promiscuous VIP support on the AX interfaces connected to clients.
Note:
For simplicity, this example uses a single Ethernet port for each interface
to the clients and the next-hop routers. You also can use trunk interfaces,
virtual Ethernet (VE) interfaces, or both.
AX(config-if: ethernet3)#ip address 10.10.10.1 255.255.255.0
AX(config-if: ethernet3)#ip allow-promiscuous-vip
AX(config-if: ethernet3)#exit
AX(config-if: ethernet4)#ip allow-promiscuous-vip
The following commands configure the AX interfaces to the next-hop routers for the load-balanced links:
292 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following commands configure a real server for each link to be load
balanced:
AX(config)#slb server link-101 192.168.10.1
AX(config-real server-node port)#no health-check
AX(config)#slb server link-201 192.168.20.1
The following commands configure service groups for the links:

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

AX(config)#slb virtual-server wildcard-vip 0.0.0.0
AX(config-slb vserver)#port 0 tcp
AX(config-slb vserver-vport)#service-group outbound-tcp-links
AX(config-slb vserver-vport)#source-nat pool outbound-nat-group
AX(config-slb vserver-vport)#no-dest-nat
AX(config-slb vserver-vport)#exit
AX(config-slb vserver)#port 0 udp
AX(config-slb vserver-vport)#service-group outbound-udp-links
AX(config-slb vserver-vport)#source-nat pool outbound-nat-group
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
293 of 950
294 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview

Overview
The AX Series supports Transparent Cache Switching (TCS). TCS enables
you to improve server response times by redirecting client requests for content to cache servers containing the content.
FIGURE 108
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
295 of 950

Overview
In this example, a client sends a request for content that is hosted by the
content server. The AX device redirects the clients 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 destinationIP 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 features, 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
296 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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 routers 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 routers service group instead of the cache servers 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 clients session ends, the TCP connection is not terminated. Instead, the connection is reused for a new client
session.
Support for Spoofing Caches
Some cache servers can use the clients IP address instead of the cache
servers 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 additional steps. (See Enabling Support for Cache Spoofing on page 308.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
297 of 950

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

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 content from content servers, enable cache spoofing support.
4. Configure a service group for the cache server and add the cache server
to it.
VIP address) and bind it to the ACL.
Add virtual port 80 and bind it to the service group containing the cache
server. Disable destination NAT on the virtual port.
6. If the cache server will spoof client IP addresses when requesting content from content servers, enable cache spoofing support on the AX
interface connected to the cache server, and on the real server (cache
server).
298 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

CLI Example
The commands in this section implement the TCS configuration shown in
Figure 109.
FIGURE 109
b y
Layer 4 TCS
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
299 of 950

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

AX(config)#trunk 2
AX(config-trunk:2)#ethernet 1 to 2
AX(config-trunk:2)#exit
AX(config)#vlan 2
AX(config-vlan:2)#tagged ethernet 1 to 2
AX(config-vlan:2)#router-interface ve 2
AX(config-if:ve2)#ip address 10.10.10.1 255.255.0.0
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
300 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

The following command configures a service group for the cache server:
AX(config)#slb service-group sg-tcs tcp
AX(config-slb svc group)#member cache-rs:80
The following commands configure a wildcard VIP and bind it to the ACL:
AX(config)#slb virtual-server wildcard 0.0.0.0 acl 198
AX(config-slb vserver)#port 80 tcp
AX(config-slb vserver-vport)#service-group sg-tcs

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 110 on page 302 shows an example of the first method, which does
not use URL switching rules. Figure 111 on page 303 shows an example of
the second method, which does use URL switching rules.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
301 of 950

FIGURE 110
302 of 950
Layer 7 TCS Without URL Switching Rules
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

FIGURE 111
b y
Layer 7 TCS Using URL Switching Rules
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
303 of 950

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 110 on page 302. The commands for configuring the interfaces and
ACL, and the real server and service group for the cache server, are the
same as those used in the Layer 4 TCS example, and are therefore not
shown.
AX(config-slb vserver)#port 80 http
AX(config-slb vserver-vport)#service-group sg-tcs
304 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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.
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.
Note:
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 service group.
group containing the cache server. Bind the virtual port to the HTTP
template. Enable disable destination NAT.
group containing the router. Enable disable destination NAT.
CLI Example
Figure 111 on page 303. The commands for configuring the interfaces and
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
305 of 950

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
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 112. Only the commands specific to destination-IP persistence are
306 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

shown. The other commands are the same as those shown in the previous
sections.
FIGURE 112
TCS with Multiple Cache Servers
The following commands configure the destination-IP persistence template:

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

URL switching and persistence in the same configuration.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
307 of 950

The following commands configure the VIP. The commands are the same as
those used for Layer 7 TCS, with the addition of a command to bind the
destination-IP persistence template to the virtual port.
AX(config-slb vserver-vport)#template http http1
AX(config-slb vserver-vport)#service-group sg-router
AX(config-slb vserver-vport)#template persist destination-ip d-sticky
AX(config-slb vserver)#exit
Enabling Support for Cache Spoofing

If the cache server spoofs client IP addresses when requesting content from
servers, the following additional configuration is required:
1. Enable cache spoofing support on the AX interface connected to the
spoofing cache server. In the CLI, enter the following command at the
configuration level for the AX interface:
cache-spoofing-port
2. In the real server configuration for the cache server, enable spoof caching support. In the CLI, enter the following command at the configuration 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 112.
AX(config-if:ethernet5)#ip cache-spoofing-port
AX(config)#slb server cache-rs 110.110.110.10
AX(config-real server)#spoofing-cache
308 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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 113
b y
TCS in HA Layer 3 Inline Mode
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
309 of 950

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 a VLAN containing Ethernet data ports 3-11

AX-2 Connected on IP interface 10.10.10.2, which is assigned to VE 1
on a VLAN 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. Interface 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.
310 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

Restart port list Interfaces 1 to 5 and interface 9 are designated as
inline-mode restart ports. This includes the AX interfaces with the client, 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 301.) The example in Figure 113 on page 309 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:
b y
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 synchronized.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
311 of 950

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.
Note:
Templates
For simplicity, the sample configuration in this section does not use any custom templates. For information about the templates that can be used with
TCS, see Application Templates on page 296.
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
312 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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)#ha group 1 priority 200
AX-1(config)#ha interface ethernet 1
AX-1(config)#ha conn-mirror ip 10.10.10.2
AX-1(config)#ha preemption-enable
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
313 of 950

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
314 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

AX-2(config)#access-list 198 permit ip any host 20.20.20.11 log
AX-2(config)#ha id 2
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
315 of 950

Configuring IPv6 TCS in High Availability Layer 3 Inline

Mode
Figure 114 shows an example of a TCS deployment in HA Layer 3 Inline
mode.
FIGURE 114
316 of 950
TCS HA Layer 3 Inline Mode
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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:
b y
The cpu-process command is applicable only to models AX 2200,

AX 3100, AX 3200, AX 5100, and AX 5200. 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.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
317 of 950

On models AX 5100 and AX 5200, when configured 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 following 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 Tip for Ensuring Fast HA Failover on page 604.) The custom ICMP
health monitor configured above is also used.
318 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
319 of 950

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
320 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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 1 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
321 of 950

Configuring TCS for FTP

You can configure the AX device to use cache servers for FTP traffic.
FIGURE 115
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.
322 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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 content 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.
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 examine the traffic that is transferred to or from the FTP server by the client.
Note:
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 1000, 2000, 2100, or 3000, you also
must enable CPU processing on each interface. On these AX models,
CPU processing is automatically 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 content 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 checking on the port.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
323 of 950

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 destination 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
AX(config-if:ethernet2)#ip allow-promiscuous-vip
324 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
325 of 950

326 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

Overview

This chapter describes how to configure Firewall Load Balancing (FWLB).
Overview
AX Series devices support Firewall Load Balancing (FWLB). FWLB load
balances server-client sessions across firewalls. Figure 116 shows an example FWLB topology.
FIGURE 116
b y
Example FWLB Topology
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
327 of 950

Overview
This example shows two pairs of AX devices. One pair is located on the
public (unprotected) side of the network. The other pair is located on the
secured side of the network. Each pair is configured for High Availability
(HA). One member of the pair is the Active AX device and the other is a hot
Standby.
SLB for the real servers is configured on one of the AX pairs. You can configure SLB for the servers on either AX pair. However, do not add the SLB
configuration to both AX pairs.
The upstream/downstream routers and the firewalls need to be configured to
use the AX device as the next hop. If HA pairs are being used, the next hop
IP configured on the upstream/downstream routers and firewalls must be an
HA-capable IP address. The following types of IP addresses are HA-capable:
Floating IP addresses (shown in Figure 116)
Virtual IP addresses
IP addresses allocated from IP source NAT pools
In HA deployments, each AX device needs an HA-capable IP interface in

the subnets connected to the firewalls and those connected to real servers
and upstream/downstream routers.
Firewall Groups
This example uses a single firewall group for both firewall nodes. When
you configure FWLB, make sure to configure a firewall group for the firewalls rather than an SLB service group.
Templates
Although this example does not use one, you can use a source-IP persistence template in an FWLB configuration. You can bind a source-IP persistence template to the virtual firewall or to individual service ports on the
virtual firewall.
If you apply a source-IP persistence template to the virtual firewall, the
AX device sends all traffic from a given source address through the
same firewall.
If you apply a source-IP persistence template to an individual service
port on the virtual firewall, the AX device sends all traffic from a given
client for that service port through the same firewall.
328 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Health Monitors
To monitor the health of a firewall, use a Layer 3 monitor with the ICMP
method, and with transparent mode enabled. This type of health monitor
verifies a firewalls health by verifying the path through the firewall to the
AX device or HA pair on the other side of the firewall.
FWLB HA with Direct Connection of AX Devices to Firewalls

Layer 2 switches are not required between the A device and the firewalls.
You can connect the AX device directly to the firewalls, as shown in
Figure 117.
FIGURE 117
b y
FWLB HA with Direct Connection of AX Devices to Firewalls
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
329 of 950

Overview
In this topology, each AX device is directly connected to only two of the
four firewalls, but can reach the other two firewalls at Layer 2 through the
other AX device. In this topology, one AX device is active for SLB and
FWLB and the other AX device is a hot standby for these services. The
standby AX device allows Layer 2 client-server traffic to pass through but
blocks other traffic. The active AX device load balances client-server traffic
across all four firewalls.
For example, assume that External AX1 is the active member of the HA pair
(is the one actively performing SLB and FWLB). External AX1 is directly
connected to the firewalls with interfaces 20.1.1.1 and 20.1.1.2, but can also
reach the other two firewalls by sending the traffic at Layer 2 through External AX2. External AX2, the standby for SLB and FWLB, allows clientserver traffic to pass through at Layer 2.
Interfaces to Clients and Servers
This topology is supported on AX devices that are deployed in route mode
(also called gateway mode). Virtual Ethernet (VE) interfaces are used to
connect the AX device to clients, servers, and the other AX device. Each
VE is configured with an IP address. In this example, External AX1 is configured with the following VE interfaces:
VE1 Connects the AX device to clients (through the gateway routers).
VE2 Directly connects the AX device to some of the firewalls, and
indirectly connects to the other firewalls through the other AX device.

VE50 Provides the HA management and session synchronization con-
nection to the other AX device.

Static IP Routes
Each of the AX devices requires static IP routes to the following:
Firewall VE subnet of the other AX pair
Client or server VE subnet of the other AX pair:
On the external AX devices, the destination address of this route is
the VE subnet connected to the real servers.

On the internal AX devices, the destination address of this route is
the virtual IP address of a pair of external access routers running a
router redundancy protocol such as VRRP.
330 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
In the example above, External AX1 has the following static routes:
Destination: 30.1.1.0 Next hop: 20.1.1.1 This route reaches the fire-
wall VE subnet of the internal AX devices, through one of the firewalls.

Destination: 40.1.1.0 Next hop: 20.1.1.1 This route reaches the VE
subnet of the real servers, through one of the firewalls.

Internal AX1 has the following static routes:
Destination: 10.1.1.0 Next hop: 30.1.1.1 This route reaches the client
VE subnet of the external AX devices, through one of the firewalls.

Destination: 20.1.1.0 Next hop: 30.1.1.1 This route reaches the fire-
wall VE subnet of the external AX devices, through one of the firewalls.

Notice that on each AX device, both static routes use the same next hop.
This is not required but it is recommended. Using the same hop does not
present a single point of failure. If the route to the specified next hop goes
down, the AX device automatically looks for another path to the route's destination through another firewall.
If the management interface is on a separate subnet, a static IP route for
this interface might also be required. This is network-dependent and is not
covered in this example.
Note:
FWLB, SLB, and HA Configuration

The FWLB and HA configuration is the same as in previous releases. There
are no new commands or options required to configure this HA solution.
To simplify configuration, A10 Networks recommends that you configure
SLB on only one of the AX pairs, either the external pair or the internal pair.
SLB does not need to be configured on both pairs.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
331 of 950

FWLB Parameters
FWLB Parameters
Table 6 lists the FWLB parameters.
TABLE 6
FWLB Parameters
Parameter
Description and Syntax
Supported Values
Firewall
Configures the firewall.
(Required)
[no] fwlb node fwall-name ipaddr

Config > Service > Firewall > Firewall Node
Applies a configured health check to the firewall.
Name of a configured health monitor
Firewall Node Parameters
Health check
(Optional)
The only type of health monitor supported for

FWLB is Layer 3 ICMP with the transparent option
enabled. The transparent option sends health check
packets to the AX device or HA pair on the other
side of the firewall.
Statistics
collection
Enables or disables collection of statistical data for
the firewall node.
(Optional)
stats-data-enable
Default: The AX device attempts to

use the default Layer 3 method (ping).
However, this default method does not
use the transparent option.
Enabled or disabled
Default: enabled
stats-data-disable
Note: Statistical data collection for load-balancing
resources requires collection for system resources to
also be enabled (stats-data-enable).
Note: This feature is not configurable using the
GUI.
Firewall Group Parameters

Firewall service
group
Configures the firewall group.
Member
fwlb service-group group-name

Config > Service > Firewall > Firewall Group
Adds a firewall to the firewall group.
Default: None
(Required)
member fwall-name [priority num]
(Required)
[stats-data-disable | statsdata-enable]
When you configure one, the default

priority is 1. Statistical data collection
is enabled by default.
The priority option enables you to designate some

firewalls as backups (the lower priority firewalls) to
be used only if the higher priority firewalls all are
unavailable.
332 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FWLB Parameters
TABLE 6
FWLB Parameters (Continued)
Parameter
Load balancing
method
(Optional)

Changes the algorithm used to select a firewall for a
client request, from round-robin to least-connection.
Least connection selects the firewall that has the
fewest connections.
Supported Values
Default: round robin
[no] least-connection
Firewall Virtual Server Parameters

Virtual firewall
state
State of the firewall virtual server
Enabled or disabled
Default: Enabled
Service ports
[no] disable
Config > Service > Firewall > Firewall Virtual
server
Specifies the service ports to load balance.
(Optional)

server - Port
Default: No service ports are specified,

which means all traffic is load balanced.
(See the Firewall Virtual Service Port Parameters

below for additional port settings)
Specifies the firewall group to use.
Name of a configured firewall group
(Optional)
Firewall group
(Required)
You also can specify a firewall group on individual

service ports. If you specify a firewall group at each
level, the firewall group specified for the individual
service port takes precedence.
Protocol port number, 1-65535
Default: not set
[no] service-group group-name
High Availability (HA) group

server
Specifies the HA group to use for the virtual firewalls traffic.
(Optional)
[no] ha-group group-id
Session synchronization
(Optional)

server
Synchronizes active sessions onto the standby AX
in the HA pair, to prevent the sessions from being
interrupted if an HA failover occurs.
1-31
Default: not set
Enabled or disabled
Default: Disabled
[no] ha-conn-mirror
server
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
333 of 950

FWLB Parameters
TABLE 6
Parameter
Source-IP persistence template

Sends all traffic from a given source address to the
same firewall.
Supported Values
Name of a configured source-IP persistence template
(Optional)
You also can specify a source-IP persistence template on individual service ports. If you specify a
template at each level, the template specified for the
individual service port takes precedence.
Default: not set
Note: The match-type option is not applicable to

FWLB. The match type for FWLB is always server,
which sets the granularity of source-IP persistence
to individual firewalls, not firewall groups or individual service ports.
TCP idle timeout

(Optional)
[no] template persist source-ip

template-name
This parameter cannot be configured using the GUI.
Specifies the number of seconds a TCP session
through a firewall can remain idle before the AX
device terminates the session.
60-15000 seconds
Default: 300 seconds
[no] tcp-idle-timeout seconds

server
UDP idle timeout

(Optional)
Note: The idle timeout applied to a session can

come from the idle timeout configured here, the idle
timeout configured on the virtual firewall port, or
the idle time configured in SLB. See TCP and
UDP Session Aging on page 335.
Specifies the number of seconds a UDP session
through a firewall can remain idle before the AX
device terminates the session.
60-15000 seconds
[no] udp-idle-timeout seconds

server
Statistics
collection

timeout configured on the virtual firewall port, or
the idle time configured in SLB. See TCP and
UDP Session Aging on page 335.
the virtual firewall.
(Optional)
stats-data-enable
Enabled or disabled
Default: enabled
stats-data-disable
Note: This feature is not configurable using the
GUI.
334 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FWLB Parameters
TABLE 6
Parameter
Supported Values
Firewall Virtual Service Port Parameters

Firewall group
Specifies the firewall group to use.
Name of a configured firewall group
(Optional)
If you specify a firewall group at this level, the firewall group specified here takes precedence over the
firewall group specified at the firewall level.
Default: not set
Source-IP persistence template

(Optional)
TCP/UDP idle
timeout
(Optional)

server - Port
Sends all traffic from a given source address to the
same firewall.
If you specify a source-IP persistence template at
this level, the template specified here takes precedence over the template specified at the firewall
level.
[no] template persist source-ip
template-name
Specifies the number of seconds a session through a
firewall on this service port can remain idle before
the AX device terminates the session.
Name of a configured source-IP persistence template

Default: not set
60-15000 seconds
[no] idle-timeout seconds

server - Port
timeout configured on the virtual firewall, or the
idle time configured in SLB. See TCP and UDP
Session Aging on page 335.
TCP and UDP Session Aging

By default, the AX device allows TCP or UDP connections through a firewall to be idle for 300 seconds (5 minutes). The idle timeout for a TCP or
UDP session through a firewall is determined as follows:
For service-type UDP (Layer 4), if the idle-timeout is set on the virtual
firewall or the UDP virtual firewall port, that idle-timeout is used. Otherwise, if the UDP idle-timeout is not set in FWLB, the idle-timeout in
the default SLB UDP template is used. Unless the default template has
been changed, the idle-timeout is 120 seconds.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
335 of 950

Configuring FWLB
For service-type TCP (Layer 4), the idle-timeout in the default SLB
TCP template is used. Unless the default template has been changed, the
idle-timeout is 120 seconds.
For service-type HTTP (Layer 7), the idle-timeout in the default SLB
TCP-proxy template is used. Unless the default template has been

changed, the idle-timeout is 600 seconds.
Note:
In the current release, the TCP idle-timeout settings in FWLB are never
used. The AX device allows you to configure them but they are not used.
Configuring FWLB
To configure FWLB:
1. Configure High Availability (HA) parameters: HA ID, HA group, session synchronization, and floating IP address.
2. Configure a health check for each firewall.
3. Configure the firewalls.
4. Configure a firewall group and add the firewalls to the group.
5. Configure a virtual firewall.
To apply FWLB only to traffic for specific services, create a virtual port for
each service, and bind the firewall group to each virtual port. If FWLB will
apply to all traffic types, do not configure any virtual ports on the virtual
firewall.
If the AX device is configured for HA, specify the HA group ID to use for
the virtual port.
Note:
336 of 950
The essential steps are described in this section. For the complete list of
FWLB settings you can configure, see Table 6 on page 332.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
USING THE GUI

To configure a health check for a firewall path
3. Click Add.
4. In the Health Monitor section, enter a name for the health monitor.
5. In the Method section, select ICMP from the Type drop-down list.
6. Select Transparent. The Alias Address field appears.
7. Enter the AX IP address at the other end of the path to check:
If there is a single AX device on the other side of the firewall, enter
the IP address of the AX.

If there is an HA pair of AX device on the other side of the firewall,
enter the floating IP address of the HA pair.
8. Click OK. The new health monitor appears in the Health Monitor table.
FIGURE 118
b y
Config > Service > Health Monitor
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
337 of 950

Configuring FWLB
To configure a firewall node
1. Select Config > Service > Firewall.
2. Select Firewall Node on the menu bar.
3. Click Add. The Firewall Node section appears.
4. Enter the firewall name and IP address.
5. Select the health method to use for checking the path through the firewall to the other AX device.
If an HA pair is configured on the other side of the firewall, enter the
floating IP address of the HA pair.
6. Click OK. The firewall appears in the Firewall Node table.
FIGURE 119
To configure a firewall group

1. Select Firewall Group on the menu bar.
2. Click Add. The Firewall Group section appears.
3. In the Firewall Group section, enter a name for the service group.
4. In the Member section, enter the IP address of a firewall in the Firewall
field.
5. Click Add.
6. Repeat step 4 and step 5 for each firewall.
7. Click OK. The firewall group appears in the Firewall Group table.
338 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
FIGURE 120
To configure the virtual firewall

1. Select Virtual Firewall Server on the menu bar.
2. Click Add.
3. In the Default section, select the HA group, if HA is configured.
4. Select the firewall group.
5. If you want to load balance all types of traffic through the firewalls,
click OK to complete the configuration. Otherwise, to load balance only
specific services, go to step 6.
6. To specify services to load balance:
a. In the Port section, click Add.
c. Select the transport protocol (TCP or UDP) from the Type dropdown list.
d. Select the firewall group from the Firewall Group drop-down list.
e. If HA is configured and you plan to use connection mirroring (session synchronization), select Enabled next to HA Connection Mirror.
f. Click OK.
g. Repeat for each protocol port.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
339 of 950

Configuring FWLB
h. Click OK to complete the firewall virtual server configuration.
340 of 950
FIGURE 121
Config > Service > Firewall > Firewall Virtual Server
FIGURE 122
section
Config > Service > Firewall > Firewall Virtual Server - Port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
USING THE CLI

1. To configure HA parameters, use the following commands at the global
ha id {1 | 2}
ha group group-id priority number
ha conn-mirror ip ipaddr
ha interface ethernet port-num
[router-interface | server-interface | both]
[no-heartbeat | vlan vlan-id]
floating-ip ipaddr ha-group group-id
2. To configure a health check for a firewall path, use the following commands:
[interval seconds | retry number |
timeout seconds]
method icmp transparent ipaddr
Enter this command at the configuration level for the health monitor.
The transparent option is required and configures the health method to
check the full path through the firewall to the other AX. The ipaddr
specifies the IP address of the AX on the other side of the firewall. In an
HA configuration, the ipaddr is the floating IP address of the HA group
on the other side of the firewall.
3. To configure a firewall and assign a health monitor to it, use the following commands:
fwlb node fwall-name ipaddr
Enter this command at the configuration level for the firewall.
4. To configure a firewall group and add the firewalls to it, use the following commands:
fwlb service-group group-name
member fwall-name [priority num]
method least-connection
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
341 of 950

Configuring FWLB
The priority option enables you to designate some firewalls as backups
(the lower priority firewalls) to be used only if the higher priority firewalls all are unavailable.
The method command is optional and changes the load-balancing
method from round-robin (the default) to least-connections.
Enter these commands at the configuration level for the firewall group.
5. To configure the virtual firewall, use the following commands:
fwlb virtual-firewall default
firewall named "default". The "default" virtual firewall is the only one
supported in the current release.
ha-group {1 | 2}
Enter these commands at the configuration level for the virtual firewall.
The port command specifies the service port that is being protected by
the firewall. This is the virtual port configured on the VIP in the SLB
configuration. The ha-group command specifies the HA group the virtual port is in.
service-group fwall-name
ha-conn-mirror
Enter these commands at the configuration level for the virtual port. The
service-group command binds the firewall group to the virtual port. The
ha-conn-mirror command enables session synchronization (connection
mirroring) between the Active and Standby AX devices in the HA configuration.
Displaying FWLB Information
To display FWLB configuration information and statistics, use the following commands:
show fwlb node [fwall-name] [config]
show fwlb service-group [group-name] [config]
show fwlb virtual-firewall [config]
In each command, the config option displays configuration information. If
you omit the config option, statistics are displayed instead.
342 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
CLI CONFIGURATION EXAMPLETOPOLOGY USING LAYER 2 SWITCHES

The commands in the following example implement the FWLB configuration for the External AX (Active) shown in Figure 116 on page 327. The
same commands can be used on the other AX devices, with the following
exceptions:
The ha id command on each AX in an HA pair must use a different HA
ID. For example, since External AX A uses HA ID 1, External AX B

must use HA ID 2.
The ha group command on each AX in an HA pair should use a differ-
ent HA priority. For example, since External AX A uses priority 100 for
the HA group, External AX B uses priority 1.
The floating-ip commands on the each AX device must use addresses
within the subnets connected to the firewalls and upstream/downstream

routers or servers. In Figure 116 on page 327, the external AX devices
need floating IP addresses 10.1.1.100 and 192.168.1.100. The internal
AX devices need floating IP addresses 10.5.1.100 and 10.20.1.100.
The method icmp transparent commands on the External AX devices
must use the floating IP address of the subnet on which the Internal AX
pair is connected to the firewalls.
Likewise, the method icmp transparent commands on the Internal AX
devices must use the floating IP address of the subnet on which the
External AX pair is connected to the firewalls.
CLI Commands on External AX (Active)
The following commands configure global HA parameters:
AX-Ext-A(config)#ha id 1
AX-Ext-A(config)#ha group 1 priority 100
AX-Ext-A(config)#ha interface ethernet 1
AX-Ext-A(config)#ha interface ethernet 2
AX-Ext-A(config)#ha conn-mirror ip 10.1.1.6
AX-Ext-A(config)#floating-ip 192.168.1.100 ha-group 1
AX-Ext-A(config)#floating-ip 10.1.1.100 ha-group 1
The following commands configure the health monitors:

AX-Ext-A(config)#health monitor fwpathcheck
AX-Ext-A(config-health:monitor)#method icmp transparent 10.5.1.100
AX-Ext-A(config-health:monitor)#exit
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
343 of 950

Configuring FWLB
The following commands configure the firewalls:
AX-Ext-A(config)#fwlb node fw1 10.1.1.1
AX-Ext-A(config-firewall node)#health-check fwpathcheck
AX-Ext-A(config-firewall node)#exit
AX-Ext-A(config)#fwlb node fw2 10.1.1.2
AX-Ext-A(config-firewall node)#health-check fwpathcheck
AX-Ext-A(config-firewall node)#exit
The following commands configure the firewall groups:

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

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

AX-Ext-S(config)#ha id 2
AX-Ext-S(config)#ha group 1 priority 1
AX-Ext-S(config)#ha interface ethernet 1
AX-Ext-S(config)#ha interface ethernet 2
AX-Ext-S(config)#ha conn-mirror ip 10.1.1.6
AX-Ext-S(config)#floating-ip 192.168.1.100 ha-group 1
AX-Ext-S(config)#floating-ip 10.1.1.100 ha-group 1
AX-Ext-S(config)#health monitor fwpathcheck
AX-Ext-S(config-health:monitor)#method icmp transparent 10.5.1.100
AX-Ext-S(config-health:monitor)#exit
AX-Ext-S(config)#fwlb node fw1 10.1.1.1
AX-Ext-S(config-firewall node)#health-check fwpathcheck
AX-Ext-S(config-firewall node)#exit
AX-Ext-S(config)#fwlb node fw2 10.1.1.2
AX-Ext-S(config-firewall node)#health-check fwpathcheck
AX-Ext-S(config-firewall node)#exit
AX-Ext-S(config)#fwlb service-group fwsg
AX-Ext-S(config-fwlb service group)#member fw1
AX-Ext-S(config-fwlb service group)#member fw2
344 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
AX-Ext-S(config-fwlb service group)#exit
AX-Ext-S(config)#fwlb virtual-firewall default
AX-Ext-S(config-fwlb virtual firewall default)#ha-group 1
AX-Ext-S(config-fwlb virtual firewall default)#port 80 tcp
AX-Ext-S(config-fwlb virtual firewall default...)#service-group fwsg
AX-Ext-S(config-fwlb virtual firewall default...)#ha-conn-mirror
CLI Commands on Internal AX (Active)

AX-Int-A(config)#ha id 1
AX-Int-A(config)#ha group 1 priority 100
AX-Int-A(config)#ha interface ethernet 1
AX-Int-A(config)#ha interface ethernet 2
AX-Int-A(config)#ha conn-mirror ip 10.5.1.6
AX-Int-A(config)#floating-ip 10.5.1.100 ha-group 1
AX-Int-A(config)#floating-ip 10.20.1.100 ha-group 1
AX-Int-A(config)#health monitor fwpathcheck
AX-Int-A(config-health:monitor)#method icmp transparent 10.1.1.100
AX-Int-A(config-health:monitor)#exit
AX-Int-A(config)#fwlb node fw1 10.5.1.1
AX-Int-A(config-firewall node)#health-check fwpathcheck
AX-Int-A(config-firewall node)#exit
AX-Int-A(config)#fwlb node fw2 10.5.1.2
AX-Int-A(config-firewall node)#health-check fwpathcheck
AX-Int-A(config-firewall node)#exit
AX-Int-A(config)#fwlb service-group fwsg
AX-Int-A(config-fwlb service group)#member fw1
AX-Int-A(config-fwlb service group)#member fw2
AX-Int-A(config-fwlb service group)#exit
AX-Int-A(config)#fwlb virtual-firewall default
AX-Int-A(config-fwlb virtual firewall default)#ha-group 1
AX-Int-A(config-fwlb virtual firewall default)#port 80 tcp
AX-Int-A(config-fwlb virtual firewall default...)#service-group fwsg
AX-Int-A(config-fwlb virtual firewall default...)#ha-conn-mirror
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
345 of 950

Configuring FWLB
CLI Commands on Internal AX (Standby)
AX-Int-S(config)#ha id 2
AX-Int-S(config)#ha group 1 priority 1
AX-Int-S(config)#ha interface ethernet 1
AX-Int-S(config)#ha interface ethernet 2
AX-Int-S(config)#ha conn-mirror ip 10.5.1.5
AX-Int-S(config)#floating-ip 10.5.1.100 ha-group 1
AX-Int-S(config)#floating-ip 10.20.1.100 ha-group 1
AX-Int-S(config)#health monitor fwpathcheck
AX-Int-S(config-health:monitor)#method icmp transparent 10.1.1.100
AX-Int-S(config-health:monitor)#exit
AX-Int-S(config)#fwlb node fw1 10.5.1.1
AX-Int-S(config-firewall node)#health-check fwpathcheck
AX-Int-S(config-firewall node)#exit
AX-Int-S(config)#fwlb node fw2 10.5.1.2
AX-Int-S(config-firewall node)#health-check fwpathcheck
AX-Int-S(config-firewall node)#exit
AX-Int-S(config)#fwlb service-group fwsg
AX-Int-S(config-fwlb service group)#member fw1
AX-Int-S(config-fwlb service group)#member fw2
AX-Int-S(config-fwlb service group)#exit
AX-Int-S(config)#fwlb virtual-firewall default
AX-Int-S(config-fwlb virtual firewall default)#ha-group 1
AX-Int-S(config-fwlb virtual firewall default)#port 80 tcp
AX-Int-S(config-fwlb virtual firewall default...)#service-group fwsg
AX-Int-S(config-fwlb virtual firewall default...)#ha-conn-mirror
346 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
CLI CONFIGURATION EXAMPLETOPOLOGY WITHOUT LAYER 2 SWITCHES

The following sections show the CLI commands for configuring interfaces,
FWLB, and HA on each of the AX devices shown in Figure 117 on
page 329. For simplicity, the SLB configuration is not shown.
Configuration of External AX1
The following commands configure the HA management and session synchronization interface to the other AX device.
Ext-AX1(config)#trunk 1
Ext-AX1(config-trunk:1)#ethernet 9 to 10
Ext-AX1(config-trunk:1)#exit
Ext-AX1(config)#vlan 50
Ext-AX1(config-vlan:50)#untagged ethernet 9 to 10
Ext-AX1(config-vlan:50)#router-interface ve 5
Ext-AX1(config-vlan:50)#exit
Ext-AX1(config)#interface ve 5
Ext-AX1(config-if:ve5)#ip address 50.1.1.1 255.255.255.0
Ext-AX1(config-if:ve5)#exit
The following commands configure the VE interface to clients:

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

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

Ext-AX1(config)#ip route 40.1.1.0 /24 20.1.1.1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
347 of 950

Configuring FWLB
Ext-AX1(config)#ha id 1
Ext-AX1(config)#ha group 1 priority 200
Ext-AX1(config)#ha interface ethernet 1
Ext-AX1(config)#ha conn-mirror ip 50.1.1.2
Ext-AX1(config)#ha preemption-enable
Ext-AX1(config)#floating-ip 20.1.1.254 ha-group 1
The following commands configure a Layer 2 health monitor to check the

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

Ext-AX1(config)#fwlb node fw1 20.1.1.1
Ext-AX1(config-firewall node)#health-check tsping
Ext-AX1(config-firewall node)#exit
Ext-AX1(config)#fwlb service-group fwsg
Ext-AX1(config-fwlb service group)#member fw1
Ext-AX1(config-fwlb service group)#exit
Ext-AX1(config)#fwlb virtual-firewall default
Ext-AX1(config-fwlb virtual firewall default)#ha-group 1
Ext-AX1(config-fwlb virtual firewall default)#service-group fwsg
Ext-AX1(config-fwlb virtual firewall default)#ha-conn-mirror
Ext-AX1(config-fwlb virtual firewall default)#port 80 tcp
348 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
Ext-AX1(config-slb virtual firewall default...)#service-group fwsg
Ext-AX1(config-slb virtual firewall default...)#ha-conn-mirror
Configuration of External AX2

This configuration is like the configuration for External AX1, with the following exceptions:
The VE IP addresses are different (although they are in the same subnets
as those on the other AX device).

The HA ID, priority, and connection mirroring IP address are different
from the other AX device.

The FWLB configuration is the same. For brevity, it is not shown.
Ext-AX2(config)#trunk 1
Ext-AX2(config-trunk:1)#ethernet 9 to 10
Ext-AX2(config-trunk:1)#exit
Ext-AX2(config-vlan:50)#untagged ethernet 9 to 10
Ext-AX2(config-vlan:10)#untagged ethernet 1
Ext-AX2(config-vlan:20)#untagged ethernet 2 ethernet 4 ethernet 13
Ext-AX2(config)#ha id 2
Ext-AX2(config)#ha group 1 priority 100
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
349 of 950

Configuring FWLB
Ext-AX2(config)#ha conn-mirror ip 50.1.1.1
Ext-AX2(config)#ha preemption-enable
Ext-AX2(config)#floating-ip 20.1.1.254 ha-group 1
Configuration of Internal AX1

This configuration is like the configuration for External AX1, with the following exceptions:
The VE IP addresses and subnets are different. (The VLAN numbers
and some of the VE numbers also are different, but this is not required.
For simplicity, the VLAN numbers were selected to match the subnet
numbers.)
The static routes are different.
The floating IP address and connection mirroring IP address are differ-
ent.
The target IP address of the transparent Layer 3 health check is the float-
ing IP address of the external AX pair.

The IP addresses of the firewall nodes are different.
The following commands configure the HA management and session synchronization interface to the other AX device.
Int-AX1(config)#trunk 1
Int-AX1(config-trunk:1)#ethernet 9 to 10
Int-AX1(config-trunk:1)#exit
Int-AX1(config)#vlan 60
Int-AX1(config-vlan:60)#untagged ethernet 9 to 10
Int-AX1(config-vlan:60)#router-interface ve 60
Int-AX1(config-vlan:60)#exit
Int-AX1(config)#interface ve 60
Int-AX1(config-if:ve60)#ip address 60.1.1.1 255.255.255.0
Int-AX1(config-if:ve60)#exit
350 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring FWLB
The following commands configure the VE interface to the servers:
Int-AX1(config-vlan:40)#untagged ethernet 2
The following commands configure the VE interface to the firewalls:

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

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

Int-AX1(config)#ha id 1
Int-AX1(config)#ha group 1 priority 200
Int-AX1(config)#ha interface ethernet 1
Int-AX1(config)#ha conn-mirror ip 60.1.1.2
Int-AX1(config)#ha preemption-enable
Int-AX1(config)#floating-ip 40.1.1.254 ha-group 1
Configuration of Internal AX2

This configuration is like the configuration for Internal AX1, with the following exceptions:
The VE IP addresses are different (although they are in the same subnets
as those on the other AX device).

The HA ID, priority, and connection mirroring IP address are different
from the other AX device.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
351 of 950

Configuring FWLB
The health monitor and FWLB configuration is the same. For brevity, it is
not shown.
Int-AX2(config)#trunk 1
Int-AX2(config-trunk:1)#ethernet 9 to 10
Int-AX2(config-trunk:1)#exit
Int-AX2(config-vlan:60)#untagged ethernet 9 to 10
Int-AX2(config-vlan:40)#untagged ethernet 2
Int-AX2(config-vlan:30)#untagged ethernet 1 ethernet 3 ethernet 13
Int-AX2(config)#ha id 2
Int-AX2(config)#ha group 1 priority 100
Int-AX2(config)#ha conn-mirror ip 60.1.1.1
Int-AX2(config)#ha preemption-enable
Int-AX2(config)#floating-ip 40.1.1.254 ha-group 1
352 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview

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 setting in the template takes precedence.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
353 of 950

Overview
Parameters That Can Be Configured Using Server and Port

Templates
Table 7 describes the server and port parameters you can configure using
templates.
TABLE 7
SLB Port and Server Template Parameters
Template Type
Real Server
Parameter
Health monitor
Description
Assigns a configured Layer 3 health monitor to all servers
that use the template. (See Configuring and Applying a
Health Method on page 382.)
Connection limit
Specifies the maximum number of connections allowed on
any server that uses the template. (See Connection Limiting on page 362.)
Connection rate limitLimits the rate of new connections the AX is allowed to
ing
send to any server that uses the template. (See Connection
Rate Limiting on page 364.)
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 SlowStart on page 366.)
Dynamic server creation using DNS
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 885.)
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 created 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.
354 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
TABLE 7
SLB Port and Server Template Parameters (Continued)
Template Type
Real Server Port
Parameter
Health monitor
In-band health monitor
Connection limit
Connection rate limiting

Destination NAT
Description
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 382.)
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 mechanism. See In-Band Health Monitoring on page 402.
any real port that uses the template. (See Connection Limiting on page 362.)
Limits the rate of new connections the AX is allowed to
send to any real port that uses the template. (See Connection Rate Limiting on page 364.)
Enables destination Network Address Translation (NAT).
Destination NAT is enabled by default, but is disabled in
Direct Server Return (DSR) configurations.
DSCP
Member priority for

dynamically created
servers
Slow start
Source NAT
Weight
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 99.
Sets the differentiated services code point (DSCP) value in
the IP header of a client request before sending the request
to a server.
Sets the initial TTL for dynamically created service-group
members. (See Dynamic Real Server Creation Using
DNS on page 885.)
Provides time for real ports that use the template to ramp-up
after TCP/UDP service is enabled, by temporarily limiting
the number of new connections on the ports. (See SlowStart on page 366.)
Specifies the IP NAT pool to use for assigning a source IP
address to client traffic addressed to the port. For information about NAT, see Network Address Translation on
page 607
Biases load-balancing selection of this port. A higher weight
gives more favor to the server and port relative to the other
servers and ports.
For an example of weighted SLB, see FTP Load Balancing on page 163. (The example configures weights directly
on the real service ports rather than using templates, but still
illustrates how the weight option works.)
Note: The weight option applies only to the weighted-leastconnection, service-weighted-least-connection, and
weighted-round-robin load-balancing methods.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
355 of 950

Overview
TABLE 7
SLB Port and Server Template Parameters (Continued)
Template Type
Virtual Server
Parameter
Connection limit

ICMP rate limiting
Virtual Server Port
Gratuitous ARPs for

subnet VIPs
Connection limit

Reset unknown connections
Description
any VIP that uses the template. (See Connection Limiting
on page 362.)
send to any VIP that uses the template. (See Connection
Rate Limiting on page 364.)
Limits the rate at which ICMP packets can be sent to the
VIP. (See ICMP Rate Limiting on page 724.)
Enables gratuitous ARPs for all VIPs in a subnet VIP. (See
Gratuitous ARPs for Subnet VIPs on page 369.)
any virtual service port that uses the template. (See Connection Limiting on page 362.)
send to any virtual service port that uses the template. (See
Connection Rate Limiting on page 364.)
Enables sending of a TCP Reset (RST) in response to a session mismatch. (See TCP Reset Option for Session Mismatch on page 370.)
Default Server and Service Port Templates

The AX device has a default template for each of these template types. If
you do not explicitly bind a server or service port template to a server or service port, the default template is automatically applied. For example, when
you create a real server, the parameter settings in the default real server template 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 parameters 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 servers and ports.
356 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring Server and Service Port Templates
Configuring Server and Service Port Templates

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

2. On the menu bar, select one of the following:
Template > Server
Template > Server Port
Template > Virtual Server
Template > Virtual Server Port
The list of configured templates of the selected type appears.

3. Click Add to create a new one or click on the name of a configured template to edit it. The configuration section for the template appears.
4. Enter a name for the template (if the template is new).
5. Enter or edit other settings. (See the descriptions in the sections below
for information.)
6. Click OK.
USING THE CLI

To configure server and service-port templates, use the following commands 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 template, 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
357 of 950

Applying a Server or Service Port Template
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 Service Port Template on page 358.

If you modify a default server or port template, the changes are automatically 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 8 lists the types of bindings that are supported for server and port templates.
358 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 8
Server and Port Template Bindings
Template
Type
Server
Port
Can Be Bound To...

Real servers
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.
Virtual Server
Virtual Server
Port
The settings do not apply to the same port if used in other service groups.
Virtual servers
Virtual server ports
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 7 on page 354.
Binding a Server Template to a Real Server

USING THE GUI
2. Click Server on the menu bar.
3. Click on the server name.
4. Select the template from the Server Template drop-down list. To create
one, click create.
5. When finished, click OK.
USING THE CLI

Enter the following command at the configuration level for the real server:
[no] template server template-name
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
359 of 950

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 create.
5. Click Update.
USING THE CLI

Enter the following command at the configuration level for the real port:
[no] template port template-name
Binding a Virtual Server Template to a Virtual Server

USING THE GUI
2. Click Virtual Server on the menu bar.
3. Click on the virtual server name.
4. Select the template from the Virtual Server Template drop-down list. To
create one, click create.
USING THE CLI

Enter the following command at the configuration level for the virtual
server:
[no] template virtual-server template-name
360 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Binding a Virtual Server Port Template to a Virtual Service Port

USING THE GUI
2. Click Virtual Server on the menu bar.
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 service port:
[no] template virtual-port template-name
Binding a Server Port Template to a Service Group

USING THE GUI
2. Click Service Group on the menu bar.
3. In the Server section, select the server port template from the Server
Port Template drop-down list.
4. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
361 of 950

Connection Limiting
USING THE CLI

At the configuration level for the service group, use the template template-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 connections on a server or service port. If certain servers or services are becoming
oversaturated, you can set a connection limit. The AX device stops sending
new connection requests to a server or port when that server or port reaches
its maximum allowed number of concurrent connections.
Connection Limit Parameters
To configure connection limits, you can set the following parameters :
Connection limit Specifies the maximum number of concurrent con-
nections allowed on a server or port. You can specify 0-1048575. By

default, the connection limit is 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
(1 million) connections.
Reset or Drop (virtual servers or virtual server ports only) Specifies
the action to take for connections after the connection limit is reached on
the virtual server or virtual server port. By default, excess connections
are dropped. If you change the action to reset, the connections are reset
instead. Excess connections are dropped by default.
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.
Note:
362 of 950
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Connection Limiting
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 following methods.
USING THE GUI

In the configuration section for the template:
1. Select the Connection Limit Status checkbox to display the configuration fields.
2. In the Connection Limit field, enter the maximum number of concurrent
connections to allow on the server or port.
3. (Server or Server Port Templates only) In the Connection Resume, enter
the maximum number of connections the server or port can have before
the AX device resumes use of the server or port.
4. (Virtual Server or Virtual Server Port Templates only) Select the action
to take for connections that occur after the limit is reached: Drop or
Reset.
5. Click OK.
USING THE CLI

To set a connection limit using a server or server port template, use the following command at the configuration level for the template:
[no] conn-limit max-connections
[resume connections] [no-logging]
To set a connection limit using a virtual server or virtual server port template, use the following command at the configuration level for the template:
[no] conn-limit max-connections [reset]
[no-logging]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
363 of 950

Connection Rate Limiting
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 connections 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 366.
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 onesecond intervals.

Action for excess connections (virtual servers or virtual server ports
only) The action specifies how the AX device responds to connection

requests after the connection rate has been exceeded. The action can be
to silently drop excess connections or to send a reset (RST) to client
requesting the connection. The default action is to silently drop the
excess connection requests.
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.
364 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

In the configuration section for the template:
1. Select the Connection Rate Limit checkbox to activate the configuration
fields.
2. Enter the connection rate limit in the field next to the checkbox.
3. Select the sampling interval: 100ms or 1 second.
4. Select the action to take for connections that exceed the limit: Drop or
Reset.
5. (Virtual Server or Virtual Server Port Templates only) Select the action
to take for connections that occur after the limit is reached: Drop or
Reset.
6. Click OK.
USING THE CLI

To configure connection rate limiting for a real server or service port, use
the following command at the configuration level for a server or server port
template, and apply the template to the server or port:
[no] conn-rate-limit connections
[per {100ms | 1sec}] [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
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 virtual server port template, and apply the template to the virtual server or virtual server port:
[no] conn-rate-limit connections
[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 commands:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
365 of 950

Slow-Start
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:
Alternatively, you can enable slow-start on individual real servers. However, the ramp-up settings on individual servers are not configurable. The
settings are the same as the default ramp-up settings in server and port
templates.
Ramp-Up Parameters
By default, slow-start allows a maximum of 128 new connections during the
first 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 connections. Table 8 shows the default
ramp-up.
366 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Slow-Start
TABLE 9
Default Slow-Start Ramp-Up
Number of Seconds After

Server Restart
0-9
10-19
20-29
30-39
40-49
50-59
60+
Total Maximum Concurrent

Connections Allowed After
Server Restart
128
256
512
1024
2048
4096
Slow-start ends No limit
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 connections. 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 increment:
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.
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
367 of 950

Slow-Start
Note:
For the connection increment, you can specify a scale factor or a connection 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 362), and the normal 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.
USING THE GUI

In the configuration section for the real server template or real port template:
1. Select the Slow Start checkbox to activate the configuration fields.
2. Enter the starting connection limit in the field to the right of From.
3. Enter the connection increment method: Multiplying or Adding.
4. Enter the connection increment in the field next to the increment method
you selected.
5. Enter the ramp-up interval in the Every field.
6. Enter the ending connection limit in the Till field.
7. Click OK.
368 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Gratuitous ARPs for Subnet VIPs
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
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.)
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:
b y
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.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
369 of 950

TCP Reset Option for Session Mismatch
USING THE GUI

2. On the menu bar, select Template > Virtual Server.
3. Select the Subnet Gratuitous ARP checkbox.
4. 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

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.
370 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

When this option is enabled, TCP RSTs are sent in the cases listed in
Table 10.
TABLE 10 Processing When Session Is To Be Deleted
Session Termination
Method
Session is terminated by
FINs from client and
server
Session ages out
Packet Type Sent by Client or

Server After Session Termination
Any packet type other than SYN
Any packet type other than SYN
AX Response
Maintain connection as long as there is
traffic. When there is no traffic, remove
the connection one second later.
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 individual virtual port templates.
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.
Note:
USING THE GUI

To enable sending of TCP RSTs in response to a session mismatch, select
the following option on the configuration page for the virtual port template:
Reset Unknown Connection
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
371 of 950

372 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Default Health Checks
Health Monitoring
AX Series devices can regularly check the health of real servers and service
ports. Health checks ensure that client requests go only to available servers.
Servers or ports that respond appropriately to health checks remain eligible
to serve client requests. A server or port that does not respond appropriately
to a health check is temporarily removed from service, until the server or
port is healthy again.
You can configure health methods on the AX device by configuring settings
for the type of service you are monitoring. You also can configure health
monitors externally using scripts and import the monitors for use by the AX
device.
Default Health Checks

The AX device performs the following types of health checks by default:
Layer 3 ping Every 5 seconds, the AX device sends an ICMP echo
request (ping) addressed to the real servers 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.
Note:
b y
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. (See Globally Disabling Layer 3 Health
Checks on page 412.)
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
373 of 950

Health Method Timers

Health methods operate based on the following timers:
Interval Number of seconds between health check attempts.
Determination of the server or ports health is not made within the interval. 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
again (if there are retries left) or marks the server or service down. You
can specify 1-12 seconds. The default is 5 seconds.
The type of reply expected by the AX device depends on the monitor
type. (See Health Method Types on page 377.)
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 406.)
Note:
374 of 950
The timeout does not apply to externally configured health monitors.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Health Check Operation

The figures in this section show how health checking operates.
Example When Server or Port Is Unresponsive
Figure 123 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 123 Health Checks Using Default Settings Server or Port Is
Unresponsive
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
375 of 950

Example When Server or Port Is Responsive
Figure 124 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 124
Responds
376 of 950
Health Checks Using Default Settings Server or Port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Health Method Types
Health Method Types

Table 11 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:
b y
To configure a health monitor for Direct Server Return (DSR), see Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments on page 386.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
377 of 950

Health Method Types
TABLE 11 Internal Health Method Types
Type
DNS
Description
AX Series sends a lookup
request for the specified domain
name or server IP address.
By default, recursion is allowed.
The tested DNS server is
allowed to send the health
checks request to another DNS
server if the tested server can not
fulfill the request using its own
database. Optionally, you can
disable recursion.
Successful If...
Server sends a reply with the
expected status code (0 by
default) and record type (A by
default).
Configuration Required
on Target Server
Domain name in the lookup
request must be in the servers
database.
You can configure the response

code(s) and record type required
for a successful health check.
You can require the server to
reply with specific status codes
within the range 0-15.
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
FTP
AX Series sends an FTP login

request to the specified port.
If anonymous login is not used,
the username also must be specified in the health check configuration.
378 of 950
(For more information, see

Customizing DNS Health Monitors on page 391.)
Server replies with FTP OK
message or Password message.
If the server sends the Password
message, the AX Series sends
the password specified in the
health check configuration. In
this case, the AX Series expects
the server to reply with another
OK message.
Requested user name and

password must be valid on the
server.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Health Method Types
TABLE 11 Internal Health Method Types (Continued)
Type
HTTP /
HTTPS
Description
AX Series sends an HTTP GET,
HEAD, or POST request to the
specified TCP port and URL.
GET requests the entire page.
HEAD requests only the
meta-information in the
header.
POST attempts to write information to the server. For
POST requests, you must
specify the target field names
and the values to post. (For
more information, see Configuring POST Requests in
HTTP/HTTPS Health Monitors on page 388.)
If a user name and password are
required to access the page, they
also must be specified in the
health check configuration.
Successful If...
Server replies with OK message
(200), by default. You can configure the response code(s) and
record type required for a successful health check.
For GET requests, the server
also must reply with the
requested content or meta-information in the page header. The
response must include the string
specified in the Expect field on
the AX Series.
For HEAD requests, the
AX Series ignores the Expect
field and only checks for the
server reply message.
For POST operations, the data
must be posted without error.
on Target Server
Requested page (URL) must
be present on the server.
For GET requests, the string
specified as the expected
reply must be present.
For POST operations, the
field names specified in the
health check must be present
on the requested page.
For HTTPS health checks,
SSL support must be enabled
on the server.
A certificate does not need to
be installed on the AX device.
The AX device always
accepts the server certificate
presented by the server.
By default, the real servers IP

address is placed in the request
headers Host: field. You can
configure a different value if
needed.
ICMP
The following types of authentication are supported: basic,

digest and NT LAN Manager
(NTLM) authentication. If you
specify a username and password, the health monitor will try
to use basic authentication first.
If this try succeeds, the authentication process is complete. Otherwise, the health monitor will
negotiate with the server to
select another authentication
method, and retry the health
check using that authentication
method.
AX Series sends an ICMP echo
request (ping) to the server.
Server replies with an ICMP

echo reply message.
Server must be configured to

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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
379 of 950

Health Method Types
Type
LDAP
Description
AX Series sends an LDAP
request to the LDAP port.
Successful If...
Server sends a reply containing
result code 0.
Optionally, the request can be

directed to a specific Distinguished Name.
A certificate does not need to

be installed on the AX Series.
The AX Series always accepts
the server certificate presented by the server.
Optionally, SSL can be enabled

for the health check.
NTP
POP3
RADIUS
RTSP
SIP
SMTP
SNMP
The AX Series also must send a

valid password, if one is required
by the server.
AX Series sends an NTP client
Server sends a standard NTP
message to UDP port 123.
48-byte reply packet.
AX Series sends a POP3 user

login request with the specified
user parameter.
Server replies with an OK message.
AX Series sends a Password

Authentication Protocol (PAP)
request to authenticate the user
name and password specified in
the health check configuration.
on Target Server
If a Distinguished Name and
password are sent in the
health check, they must match
these values on the LDAP
server.
The AX Series then sends the

password specified in the health
check configuration. The
AX Series expects the server to
reply with another OK message.
Server sends Access Accepted
message (reply code 2).
NTP service must be running.

password must be valid on the
server.

password must be configured
in the servers user database.
AX Series sends a request for

information about the file specified in the health check configuration.
AX Series sends a SIP OPTION
request or REGISTER request.
AX Series sends an SMTP Hello
message.
Server replies with information

about the specified file.
Likewise, the shared secret

sent in the health check must
be valid on the server.
The file must be present on
the RTSP server.
Server replies with 200 - OK.
None.
Server sends an OK message

(reply code 250).
AX Series sends an SNMP Get

or Get Next request to the specified OID, from the specified
community.
Server replies with the value of

the OID.
Server recognizes and accepts

the domain of sender. If
SMTP service is running and
can reply to Hello messages,
the server can pass the health
check.
Requested OID and the
SNMP community must both
be valid on the server.
380 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Health Method Types
Type
TCP
Description
AX Series sends a connection
request (TCP SYN) to the specified TCP port on the server.
Successful If...
Server replies with a TCP SYN
ACK.
By default, the AX device completes the TCP handshake with
the server:
on Target Server
Destination TCP port of the
health check must be valid on
the server.
AX -> Server
SYN ->
<- SYN-ACK
ACK ->
FIN-ACK ->
<- FIN-ACK
ACK ->
To configure the AX device to
send a RST (Reset) instead of
sending the first ACK, enable
the Halfopen option. In this case,
the health check is performed as
follows:
SYN ->
<- SYN-ACK
UDP
AX Series sends a packet with a

valid UDP header and a garbage
payload to the specified UDP
port on the server.
RST ->
Server does either of the following:
Replies from the specified
UDP port with any type of
packet.
Destination UDP port of the

health check must be valid on
the server.
Does not reply at all.

The server fails the health check
only if the server replies with an
ICMP Error message.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
381 of 950

Configuring and Applying a Health Method
Protocol Port Numbers Tested by Health Checks

If you specify the protocol port number to test in a health monitor, the protocol port number configured in the health monitor is used if you send an ondemand health check to a server without specifying the protocol port. (See
On-Demand Health Checks on page 408.)
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 monitors 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 394.

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 following 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
3. Click Add.
4. In the Health Monitor section, enter a name for the monitor.
5. In the Method section, select the monitor type from the Type drop-down
list. The rest of the configuration fields change depending on the monitor type. (See Health Method Types on page 377.)
6. Enter or select settings for the monitor.
7. Click OK. The new monitor appears in the Health Monitor table.
382 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

To import an externally configured monitor
1. Create a script for the monitor. (For an example, see Using External
Health Methods on page 420.)
2. In the AX management GUI, select Config > Service > Health Monitor.
3. Select External Program on the menu bar.
4. Click Add.
5. Enter a name and description for the external health method.
6. Copy and paste the script into the Definition field.
7. Click OK. The method appears in the External Program table.
To apply a Layer 3 health monitor to a real server template
2. On the menu bar, select Template > Server.
3. To edit an existing template, click on the template name. To create a new
template, click Add.
The Server Template 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 353.)
6. Click OK.
To apply a health monitor to a real service port template
The Server Port Template section appears.
4. Select the health monitor from the Health Monitor drop-down list.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
383 of 950

5. Configure other settings if needed. (See Server and Port Templates on
page 353.)
6. Click OK.
To apply the monitor to an individual real server or service port
2. On the menu bar, select Server.
3. Select the server or click Add to create a new one.
4. To apply a Layer 3 health monitor to the server, select the health monitor
from the Health Monitor drop-down list 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 398.)
384 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 377. 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 External Health Methods on page 420.)
2. At the global configuration level of the AX CLI, use the following command to import the monitor script:
health external import [description] url
The url specifies the file transfer protocol, username (if required), and
directory path.
tftp://host/program-name
ftp://[user@]host[:port]/program-name
scp://[user@]host/program-name
rcp://[user@]host/program-name
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
385 of 950

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 programname [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 service port template
Use the following command at the configuration level for the server template (if applying a monitor that uses the ping method) or at the configuration 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
Layer 3 and Layer 4-7 health checks are supported in DSR configurations.
The target of the Layer 3 health checks can be the real IP addresses of the
servers, or the virtual IP address, depending on your preference.
To send the Layer 3 health checks to the real server IP addresses, you
can use the default Layer 3 health method (ICMP).

To send the Layer 3 health checks to the virtual IP address instead:
Configure an ICMP health method with the transparent option
enabled, and with the alias address set to the virtual IP address.
Globally enable DSR health checking.
386 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Layer 4-7 health checks are sent to the same IP address as the Layer 3 health
checks, and then addressed to the specific protocol port. You can use the
default TCP and UDP health monitors or configure new health monitors.
This example uses the default TCP health monitor.
The following sections show how to configure Layer 3 health checking of
virtual IP addresses and how to globally enable DSR health checking of
virtual IP addresses. A complete DSR deployment requires additional
configuration. See the examples in Network Setup on page 71.
Note:
USING THE GUI

To configure a Layer 3 health method targeted to a virtual IP
address:
3. Click New. The Health Monitor section appears.
4. Enter a name for the monitor.
5. Click Method.
6. In the Type drop-down list, select ICMP.
7. In the Mode drop-down list, select Transparent.
8. In the Alias Address field, enter the loopback address.
9. Click Apply or OK.
To globally enable DSR health checking of virtual IP addresses:
1. Select Config > Service > Server > Global > Settings.
2. Select Enabled next to DSR Health Check.
3. Click Apply.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
387 of 950

USING THE CLI

To configure a Layer 3 health method targeted to a virtual IP
address:
[interval seconds | retry number | timeout seconds]
Enter this command at the global Config level of the CLI. The CLI changes
to the configuration level for the health method.
method icmp transparent ipaddr
For ipaddr, enter the virtual IP address.
To globally enable DSR health checking of virtual IP addresses:
Use the following command at the global Config level of the CLI:
slb dsr-health-check-enable
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 dropdown 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.
388 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

c. In the Post Data field, enter the field names and values to be posted.
In the postdata string, use = between a field name and the value
you are posting to it. If you post to multiple fields, use & between
the fields. For example: fieldname1=value&fieldname1=value. The
string can be up to 255 bytes long.
6. Configure other settings as needed.
7. Click OK.
FIGURE 125
HTTP Health Monitor with POST Operation
USING THE CLI

To configure an HTTP or HTTPS health monitor, use the following commands:
[interval seconds]
[retry number]
[timeout seconds]
[up-retry num]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
389 of 950

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 monitor. 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:
[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]
In the postdata string, use = between a field name and the value you are
posting to it. If you post to multiple fields, use & between the fields. For
example: postdata fieldname1=value&fieldname1=value. 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
390 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 firstname=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:
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 checks 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
391 of 950

By default, the AX device expects the DNS server to respond to the
health check with an A record.
USING THE GUI

2. Click Add.
3. 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. Configuration 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 Recursion.
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. Separate the codes (and code ranges) with commas.
10. Click OK.
392 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 126
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 monitor. 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 command:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
393 of 950

[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 responsecode 0-3,5
Overriding the Target IP Address or Protocol Port Number

The AX device provides options to override the real server IP address or
protocol port number to which health checks are addressed.
By default, the AX device sends a Layer 3 health check to the IP address
used in the real server configuration. Likewise, the AX device sends Layer
4-7 health checks to the real port number in the real servers configuration.
For GSLB service IPs, the AX device sends the health check to the service
IP address. For example, if the configuration has a Layer 3 health monitor
used by service IPs 192.168.100.100-102, the AX device addresses the
health checks those IP addresses.
You can specify an override IP address or protocol port number in the health
monitor. In this case, the AX device always addresses the health check to
the override address or port. This option is particularly useful for testing the
health of a remote link, as in the following example.
394 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 127
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 metric is enabled in the GSLB policy, so health checks are needed to verify that
the service IPs are healthy. One way to do so is to check the health of the
ISP link connected to the site AX device.
Because the GSLB AX device is deployed in route mode instead of transparent 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,
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
395 of 950

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 override port number is still used instead.
USING THE GUI

2. Click on the health monitor name or click Add to create a new one.
3. For an ICMP health monitor:
a. Leave ICMP selected in the Type drop-down list.
b. Enter the target IP address of the health monitor, in the Override
IPv4 or Override IPv6 field.
4. For other health methods, select the type, then enter the target protocol
port number in the Override Port field.
5. Click OK. The health monitor list re-appears.
USING THE CLI

Use one of the following commands at the configuration level for the health
monitor:
[no] override-ipv4 ipaddr
[no] override-ipv6 ipv6addr
[no] override-port portnum
396 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following commands configure a health monitor for the service IPs
shown in Figure 127 on page 395, 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 Ports Health Status on Another Ports Health Status

You can configure the AX device to base a real ports health status on the
health status of another port number.
Both the real port and the port to use for the real ports 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.
USING THE CLI

Use the following command at the configuration level for the real port:
[no] health-check follow-port port-num
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
397 of 950

Service Group Health Checks

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 128
In this example, a single server provides content for the following sites:
www.media-rts.com
www.media-tuv.com
www.media-wxyz.com
All sites can be reached on HTTP port 80 on the server. The health check
configured on the port in the real server configuration results in the same
health status for all three sites. All of them either are up or are down.
398 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

In this case, if one of the sites is taken down for maintenance, the health status 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
servers 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 servers port
3. Health check on service group
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 service group member in that service group is marked Down.
To assign a health monitor to a service group, use either of the following
methods.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
399 of 950

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 128.
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
400 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 groups 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
401 of 950

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

2. On the menu bar, select Health Monitor, if not already selected.
4. Select the Disable After Down checkbox.
5. When finished configuring the health monitor, click OK.
USING THE CLI

Use the following command at the configuration level for the health monitor:
[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 client-server traffic, and can very quickly send a clients 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 following service types:
TCP
HTTP
HTTPS
402 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Relationship To Standard Layer 4 Health Monitoring
The in-band health check works independently of and supplements the standard 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.
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.
Note:
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 sessions 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 increments 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 successfully 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
403 of 950

Logging and Traps
When the AX device marks a server port down, the device generates a log
message and an SNMP trap, if logging or SNMP traps are enabled. The
message and trap are the same as those generated when a server port fails a
standard health check. However, you can discern whether the port was
marked down due to a failed in-band health check or standard health check,
based on the module name listed in the message.
A10LB The port was marked down by an in-band health check.
A10HM The port was marked down by a standard health check.
Here is an example of a log message generated from each module:

Sep 08 2008 17:15:04 Info
Sep 08 2008 17:15:04 Info
A10LB SLB server s-3-2-1 (10.3.2.1) port 80 is down.

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 module.
Configuring In-Band Health Monitoring

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

To configure in-band health monitoring in server port template:
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.
404 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 360.
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
405 of 950

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 monitor.
USING THE GUI

3. Click on the monitor name or click Add to add a new one.
4. In the Health Monitor section, enter a name for the monitor (if new).
5. In the Consec Pass Reqd field, enter the number of consecutive times
the target must pass the same periodic health check.
6. If new, in the Method section, select the monitor type from the Type
drop-down list, and enter or select settings for the monitor.
7. Click OK.
USING THE CLI

Use the up-retry number option with the health-monitor command.
406 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Maintenance Health Status for Servers in Persistence Configurations
Maintenance Health Status for Servers in Persistence

Configurations
You can use the response to an HTTP or HTTPS health check to set a
servers health status to Maintenance. When a servers health status is
Maintenance, the server will accept new requests on existing cookie-persistent or source-IP persistent connections, but will not accept any other
requests.
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 servers 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 servers health status changes to Up.
Fail a health check. In this case, the servers status changes to Down.
The Maintenance health status applies to server ports and service-group

members. When a ports status changes to Maintenance, this change applies
to all service-group members that use the port.
This feature applies only to servers in cookie-persistence or source-IP
persistence configurations, and can be used only for HTTP and HTTPS
ports.
Note:
USING THE GUI

2. On the menu bar, select Health Monitor, if not already selected.
4. In the Maintenance Code field, enter the response code to use to trigger
the AX device to change the servers status to Maintenance.
5. When finished configuring the health monitor, click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
407 of 950

On-Demand Health Checks
USING THE CLI

Use the maintenance-code code-list option with one of the following commands 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
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).

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:
408 of 950
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
The port portnum option specifies the protocol port to test, 1-65535. By
default, the protocol port number specified in the health monitor configuration is used.
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.
Note:
CLI Example
The following command tests port 80 on server 192.168.1.66, using configured health monitor hm80:
AX#health-test 192.168.1.66 monitorname hm80
node status UP.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
409 of 950

Enabling Strict Retries
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 servers 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 monitor:
[no] strictly-retry-on-server-error-response
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
410 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Globally Changing Health Monitor Parameters

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.
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:
To globally change health monitor parameters, use the following command

at the global configuration level of the CLI:
[no] health global
{
interval seconds |
retry number |
timeout seconds |
up-retry number
}
You can change one or more parameters on the same command line.
CLI Example
The following command globally changes the default number of retries to 5:
AX(config)#health global retry 5
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
411 of 950

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.
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
412 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Compound Health Monitors
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

Compound health monitors enable you to combine multiple health monitors
into a compound health monitor. The AX device uses the combined results
of the individual health monitors in the compound health monitor to determine the health of the real server, port, or service group to which the compound health monitor is applied.
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 following 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 status 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 status 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
413 of 950

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:
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 monitor 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 modules is unable to complete its health check,
the compound monitors result will always be Down.
414 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
Compound health monitoring increases the workload of the health mon-
itoring subsystem. For example, using a compound monitor with many

submonitors against a service group with many members can affect system performance.
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 operators, select the operator, then click Add.
Make sure to use Reverse Polish Notation. (See Compound Health Monitor Syntax on page 413.) Otherwise, the GUI will display an error message when you click OK to complete the health monitor configuration.
Note:
5. Click OK to complete the configuration of the compound monitor.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
415 of 950

FIGURE 129
Compound Health Monitor Configuration
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 Monitor Syntax on page 413.)
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
416 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Displaying Health Status
The following commands apply the health monitor to a service group:
AX(config)#slb service-group sg1 tcp
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 service-group sg2 tcp
AX(config-slb svc group)#health-check hm-compoundOR

The AX device begins sending health checks to a real servers IP address
and service ports as soon as you finish configuring the server. You can display health status for virtual servers and service ports, and for the real servers 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 servers service
ports, click on the virtual server name.
Virtual server health status is also displayed in the virtual server list displayed by Config > Service > SLB > Virtual Server.
For information about the virtual server health state icons, see the
Monitor > Overview > Status section in the Monitor Mode chapter of
the AX Series GUI Reference.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
417 of 950

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 servers service
ports, click on the server name.
Real server health status is also displayed in the real server list displayed by
Config > Service > SLB > Server.
For information about the real server health state icons, see the
Monitor > Service > Server section in the Monitor Mode chapter of the
AX Series GUI Reference.
USING THE CLI

To display the health of virtual servers and service ports:
Use the following command. The health is shown in the State field. For
descriptions of each health state, see the AX Series CLI Reference.
show slb virtual-server virtual-server-name
[virtual-port-num service-type [group-name]]
Here is an example:
AX#show slb virtual-server "vs 1"
Virtual server: vs 1
State: Down
IP: 1.1.1.201
Pri
Port/State
Curr-conn Total-conn Rev-Pkt
Fwd-Pkt
-----------------------------------------------------------------------Virtual Port:80 / service:svcgrp 1 / state:Down
port 80 tcp
1
server 1:80/Down
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
418 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
State
-----------------------------------------------------------------------------s1:80/tcp
Down
s1:53/udp
Down
s1:85/udp
Down
s1: Total
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:
Number of burst:
Number of timer adjustment:
Timer offset:
Opened socket:
Open socket failed:
Close socket:
Send packet:
Send packet failed:
Receive packet:
Receive packet failed
b y
:
:
:
:
:
:
:
:
:
:
:
2 hours 1345 seconds

0
0
0
1140
0
1136
0
259379
0
0
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
419 of 950

Using External Health Methods
Retry times:
Timeout:
Unexpected error:
: 4270
: 0
: 0
IP address
Port Health monitor Status Cause(Up/Down/Retry) PIN
-------------------------------------------------------------------------------10.10.10.99
default
Down
0 /48 /854
2 /0
4.4.4.4
default
Down
0 /48 /854
2 /0
8.4.3.2
default
Down
0 /48 /854
2 /0
99.99.99.99
default
Down
0 /48 /854
2 /0
10.10.10.88
default
Down
0 /48 /854
2 /0
10.10.10.88
80
qrs
Down
0 /34 /0
2 /0
For more information, see the AX Series CLI Reference.

Besides internal health checks, which use a predefined health check
method, you can use external health checks with scripts. The following
types of scripts are supported:
Perl
Shell
Tcl
Utility commands such as ping, ping6, wget, dig, and so on are supported.
Configuration
To use an external health method:
1. Configure a health monitor script.
2. Import the script onto the AX device.
3. Configure a health monitor that uses external as the method.
4. In the server configuration, set the health check to use the method.
420 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
421 of 950

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:
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.
422 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
}
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
423 of 950

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
424 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Shell Script Example

For Shell scripts, use #! /bin/bash at the beginning of the script.
Here is an example using the Shell scripting language:
#! /bin/bash
if test "$HM_SRV_IPADDR" == "" ; then
echo "Please check ENV Var 'HM_SRV_IPADDR'"
exit 1
fi
echo -n "Test $HM_SRV_IPADDR ...."
wget $HM_SRV_IPADDR --delete-after --timeout=2 --tries=1
> /dev/null 2>&1
ret=$?
if test $ret == 0 ; then
echo "OK"
exit 0
else
echo "Fail"
exit 1
fi
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
425 of 950

426 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview

This chapter describes Global Server Load Balancing (GSLB).
Overview
Global Server Load Balancing (GSLB) extends load balancing to global
geographic scale. AX Series adds intelligence to DNS. GSLB evaluates the
server IP addresses in DNS replies and changes the order of the addresses in
the replies so that the best available host IP address is the preferred choice.
AX Series GSLB provides the following key advantages:
Protects businesses from down time due to site failures
Ensures business continuity and applications availability
Provides faster performance and improved user experience by directing
users to the nearest site

Increases data center efficiency and better return on investment by dis-
tributing load to multiple sites

Provides flexible policies for selecting fairness and distribution to multi-
ple sites
You can deploy GSLB in proxy mode or server mode.
Proxy mode The AX device acts as a proxy for an external DNS
server.
Server mode The AX device directly responds to queries for specific
service IP addresses in the GSLB zone. (The AX device still forwards

other types of queries to the DNS server.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
427 of 950

Overview
Figure 130 shows an example of a GSLB configuration.
FIGURE 130
GSLB Example (proxy mode)
In this example, the GSLB AX device (the GSLB controller) globally load
balances client requests for www.a10.com.
The a10.com services reside on real servers at two sites. At each site, an AX
device provides SLB for the real servers. On the GSLB AX device, the sites
are grouped into a zone for the service.
When a client sends a DNS lookup request for the IP address of
www.a10.com, the GSLB AX device intercepts the request and sends the
same request to the DNS server on behalf of the client.
When the GSLB AX device receives the DNS reply, the device re-orders the
IP addresses in the reply based on the results of site evaluation using the
configured GSLB metrics. The GSLB AX device also makes other changes
428 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
to the DNS reply, such as shortening the TTL of the IP Address records, if
specified by the GSLB configuration. The GSLB AX device then sends the
modified DNS reply to the client.
When the client receives the DNS reply, the client then sends the HTTP
request to the IP address that the GSLB AX device placed at the top of the
IP address list in the DNS reply.
Note:
Here and elsewhere in A10 Networks user documentation, the IP

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

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

Overview
Zones, Services, and Sites

GSLB operates on zones, services, and sites.
Zones A zone is a DNS domain for GSLB and is called as GSLB zone.
An AX device can be configured with one or more GSLB zones. Each

zone can contain one or more GSLB sites. For example, mydomain.com
is a domain.
Services A service is an application; for example, HTTP or FTP. Each
zone can be configured with one or more services. For example:

www.mydomain.com is a service where www is the http service or an
application.
Sites A site is a server farm that is locally managed by an AX device
that performs Server Load Balancing (SLB) for the site.
GSLB Policy
GSLB evaluates the service IP addresses listed in replies from DNS servers
to clients, re-orders the addresses based on that evaluation, and sends the
DNS replies to clients with the re-ordered IP address lists. As a result of this
process, each client receives a DNS reply that has the best service IP
address listed first.
GSLB selects the best site IP address using a GSLB policy. A GSLB policy
consists of one or more of the following metrics:
1. health-check Services that pass health checks are preferred.
2. weighted-ip Service IP addresses with higher administratively
assigned weights are used more often than service IP addresses with
lower weights. (See Weighted-IP and Weighted-Site on page 432.)
3. weighted-site Sites with higher administratively assigned weights are
preferred. Sites with higher administratively assigned weights are used
more often than sites with lower weights. (See Weighted-IP and
Weighted-Site on page 432.)
4. session capacity Sites with more available sessions based on respective maximum session capacity are preferred.
5. active-servers Sites with the most currently active servers are preferred.
6. active-rtt Sites with faster round-trip-times for DNS queries and
replies between a site AX device and the GSLB local DNS are preferred.
7. passive-rtt Services with faster response times to clients are preferred.
430 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
8. geographic Services located within the clients geographic region are
preferred.
9. connection-load Sites that are not exceeding their thresholds for new
connections are preferred.
10. num-session Sites that are not exceeding available session capacity
threshold compared to other sites are treated as having the same preference.
11. admin-preference The site with the highest administratively set preference is selected.
12. bw-cost Selects sites based on bandwidth utilization on the site AX
links.
13. least-response Service IP addresses with the fewest hits are preferred.
14. ordered-ip Service IP addresses are administratively prioritized. The
prioritized list is sent to the next metric for further evaluation. If
ordered-ip is the last metric, the prioritized list is sent to the client. (See
Ordered-IP on page 432.)
15. round-robin Sites are selected in sequential order. (See Tie-Breaker
on page 432.)
16. alias-admin-preference Selects the DNS CNAME record with the
highest administratively set preference. This metric is similar to the
Admin Preference metric, but applies only to DNS CNAME records.
17. weighted-alias Prefers CNAME records with higher weight values
over CNAME records with lower weight values. This metric is similar
to Weighted-IP, but applies only to DNS CNAME records.
The health-check, geographic, and round-robin metrics are enabled by
default. All other metrics are disabled by default.
The GSLB AX device uses each enabled GSLB metric to select or eliminate
service IP addresses, then passes the subset of addresses that pass the metrics criteria to the next metric, and so on, to sort (re-order) the list of
addresses. The GSLB AX device then replaces the IP address list in the
DNS reply with the re-ordered list before sending the reply to the client.
The metric order and the configuration of each metric are specified in a
GSLB policy. Policies can be applied to GSLB zones and to individual services. The GSLB AX device has a default GSLB policy, named default,
that is automatically applied to a zone or service, unless you configure and
assign a different policy to the zone or service.
Note:
b y
Metric order does not apply to the alias-admin-preference and weightedalias metrics. When enabled, alias-admin-preference always has high priority.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
431 of 950

Overview
Weighted-IP and Weighted-Site
The weighted-ip and weighted-site metrics allow you to bias selection
toward specific sites or IP addresses. GSLB selects higher-weighted sites or
IP addresses more often than lower-weighted sites or IP addresses.
For example, if there are two sites (A and B), and A has weight 2 whereas B
has weight 4, GSLB will select site B twice as often as site A. Specifically,
GSLB will select site B the first 4 times, and will then select site A the next
2 times. This cycle then repeats: B is chosen 4 times, then A is chosen the
next 2 times, then B is chosen the next 4 times, and so on.
Note:
If DNS caching is used, the cycle starts over if the cache aging timer
expires.
Ordered-IP
Most metrics select a site or IP address as the best address. However, the
ordered-ip metric does not select or eliminate sites or IP addresses. Instead,
the ordered-ip metric re-orders the IP addresses based on the metrics configuration in the GSLB policy.
If there are any more metrics after ordered-ip, the re-ordered list is sent to
the next metric.
If you plan to use the ordered-ip metric, you need to disable the round-robin
metric. Otherwise, round-robin will be used as the tie-breaker and the
ordered IP list will be ignored.
Tie-Breaker
If all the enabled metrics in the policy result in a tie (do not definitively
select a single site as the best site), the AX device uses round-robin to select
a site. This is true even if the round-robin metric is disabled in the GSLB
policy.
Note:
If the last metric is ordered-ip, and round-robin is disabled, the prioritized

list of IP addresses is sent to the client. Round-robin is not used.
Health Checks
The health-check metric checks the availability (health) of the real servers
and service ports. Sites whose real servers and service ports respond to the
health checks are preferred over sites in which servers or service ports are
unresponsive to the health checks.
432 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
GSLB supports health check methods for the following services:
ICMP (Layer 3 health check), TCP, UDP, HTTP, HTTPS, FTP, SMTP,
POP3, SNMP, DNS, RADIUS, LDAP, RTSP, SIP
You can use the default health methods or configure new methods for any of
these services.
By default, the GSLB protocol is used for health checking a service, if the
protocol can reach the service. Otherwise, health checking is performed
using standard network traffic instead.
Note:
Health Check Precedence

Health monitoring for a GSLB service can be performed at the following
levels.
1. Gateway health check
2. Port health check
3. IP health check (Layer 3 health check of service IP)
If the gateway health check is unsuccessful, the service IP is marked Down.
If the gateway health check is successful, the port health check is used if
ports are configured on the service IP. Otherwise, if no service ports are
configured on the service IP, the Layer 3 health check is used.
(For more information about health monitoring, see Health Monitoring on
page 373.)
Geo-Location
You can configure GSLB to prefer site VIPs for DNS replies that are geographically closer to the clients. For example, if a domain is served by sites
in both the USA and Asia, you can configure GSLB to favor the USA site
for USA clients while preferring the Asian site for Asian clients.
To configure geo-location:
Leave the geographic GSLB metric enabled.
Load geo-location data. You can load geo-location data from a file or
manually configure individual geo-location mappings.

Loading geo-location data from a file is simpler than manually configuring
geo-location mappings, especially if you have more than a few GSLB sites.
For more information, see Loading or Configuring Geo-Location Mappings on page 459.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
433 of 950

Overview
The AX software includes an Internet Assigned Numbers Authority (IANA)
database. The IANA database contains the geographic locations of the IP
address ranges and subnets assigned by the IANA. The IANA database is
loaded (enabled) by default.
CNAME Support
As an extension to geo-location support, you can configure GSLB to send a
Canonical Name (CNAME) record instead of an Address record in DNS
replies to clients. A CNAME record maps a domain name to an alias for that
domain. For example, you can configure aliases such as the following for
domain a10.com, and associate the aliases with different geo-locations:
www.a10.co.cn
www.1.a10.com
ftp.a10.com
If a clients IP address is within a geo-location associated with

www.1.a10.com, GSLB places a CNAME record for www.1.a10.com in the
DNS reply to the client.
To configure CNAME support:
Configure geo-location as described above.
In the GSLB policy, enable the following DNS options:
dns cname-detect (enabled by default)
dns geoloc-alias
For individual services in the zone, configure the aliases and associate
them with geo-locations.

Alias-Admin-preference and Weighted-alias
The Alias Admin Preference and Weighted Alias metrics can be used in
DNS Proxy or DNS Server mode. Some additional policy options are
required in either mode.
DNS proxy Enable the geoloc-alias option. After GSLB retrieves the
DNS response from the DNS answer, GSLB selects a DNS A record
using IP metrics, then tries to insert the DNS CNAME record into the
answer based on geo-location settings. While inserting the CNAME
record, if the Alias metrics are enabled, GSLB may remove some
CNAME records and related service IPs.
DNS server Enable the geoloc-alias option. After receiving a DNS
query, GSLB tries to insert a DNS CNAME record into the answer
based on the geo-location settings. During insertion, if the Alias metrics
are enabled, GSLB may remove some CNAME records. After finishing
434 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
the CNAME records, GSLB tries to insert DNS A records by CNAME
record.
DNS server If applicable, enable the backup-alias option. If there is no
DNS A record to return, GSLB tries to insert all backup DNS CNAME
records. During insertion, if Alias metrics are enabled, GSLB may
remove some CNAME records. No DNS A records are returned.
This option also requires the dns-cname-record as-backup option on the
service.
DNS Options
DNS options provide additional control over the IP addresses listed in DNS
replies to clients. After the GSLB AX device uses the metrics to select and
prioritize the IP addresses for the DNS reply, the AX device applies the
enabled DNS options to the list.
The following DNS options can be set in GSLB policies:
dns action Enable GSLB to perform DNS actions specified in the serv-
ice configurations.
dns active-only Removes IP addresses for services that did not pass
their health checks.

dns addition-mx Appends MX records in the Additional section in
replies for A records, when the device is configured for DNS proxy or
cache mode.
dns best-only Removes all IP addresses from DNS replies except for
the address selected as the best address by the GSLB policy metrics.
dns cache Caches DNS replies and uses them when replying to clients,
instead of sending a new DNS request for every client query.

dns cname-detect For IP addresses that have Canonical Name
(CNAME) records, applies the GSLB policy to the CNAME record

instead of the Address record. (This applies only if the CNAME records
are for the zone and application requested by the DNS proxy on the
GSLB AX device.)
dns external-ip Returns the external IP address configured for a ser-
vice IP. If this option is disabled, the internal address is returned instead.
dns geoloc-action Performs the DNS traffic handling action specified
for the clients geo-location. The action is specified as part of service

configuration in a zone.
dns geoloc-alias Replaces the IP address with its alias configured on
the GSLB AX Series.

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
435 of 950

Overview
dns geoloc-policy Returns the alias name configured for the clients
geo-location.
dns ip-replace Replaces the IP addresses with the set of addresses
administratively assigned to the service in the zone configuration.

dns ipv6 Enables support for IPv6 AAAA records.
dns logging Configures DNS logging.
dns server Enables the GSLB AX device to act as a DNS server, for
specific service IPs in the GSLB zone.

dns sticky Sends the same service IP address to a client for all requests
from that client for the service address.

dns ttl Overrides the TTL set in the DNS reply. (For more information
about this option, see TTL Override on page 436.)

The cname-detect and external-ip options are enabled by default. All the
other DNS options are disabled by default.
Order in Which Sticky, Server, Cache, and Proxy Options Are
Used
If more than one of the following options are enabled, GSLB uses them in
the order listed, beginning with sticky:
1.
2.
3.
4.
Note:
sticky
server
cache
proxy
GSLB does not have a separately configurable proxy option. The proxy
option is automatically enabled when you configure the DNS proxy as
part of GSLB configuration.
The site address selected by the first option that is applicable to the client
and requested service is used.
TTL Override
GSLB ensures that DNS replies to clients contain the optimal set of IP
addresses based on current network conditions. However, if the DNS TTL
value assigned to the Address records is long, the local DNS servers used by
clients might cache the replies for a long time, and send those stale replies to
clients. Thus, even though the GSLB AX device has current information,
clients might receive outdated information.
436 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
To ensure that the clients local DNS servers do not cache the DNS replies
for too long, you can configure the GSLB AX device to override the TTL
values of the Address records in the DNS replies before sending the replies
to clients.
The TTL of the DNS reply can be overridden in two different places in the
GSLB configuration:
1. If a GSLB policy is assigned to the individual service, the TTL set in
that policy is used.
2. If no policy is assigned to the individual service, but the TTL is set in
the zone, then the zones TTL setting is used.
By default, the TTL override is not set in either of these places.
Metrics That Require the GSLB Protocol on Site AX Devices

AX devices use the GSLB protocol for GSLB management traffic. The protocol is required to be enabled on the GSLB controller. The protocol is recommended on site AX devices but is not required. However, some GSLB
policy metrics require the protocol to be enabled on the site AX devices as
well as the GSLB controller:
session-capacity
active-rtt
passive-rtt
connection-load
num-session
least-response
The GSLB protocol is required in order to collect the site information provided for these metrics.
Note:
b y
The GSLB protocol is also required for the health-check metric, if the
default health checks are used. If you modify the health checks, the GSLB
protocol is not required. (See Health Checks on page 432.)
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
437 of 950

Configuration Overview
Configuration is required on the GSLB AX device (GSLB controller) and
the site AX devices.
Configuration on GSLB Controller
To configure GSLB on the GSLB AX device:
1. Configure health monitors for the DNS server to be proxied and for the
GSLB services to be load balanced.
2. Configure a DNS proxy.
3. Configure a GSLB policy (unless you plan to use the default policy settings, described in GSLB Policy on page 430).
4. Configure services.
5. Configure sites.
6. Configure a zone.
7. Enable the GSLB protocol for the GSLB controller function.
Note:
If you plan to run GSLB in server mode, the proxy DNS server does not
require configuration of a real server or service group. Only the VIP is
required. However, if you plan to run GSLB in proxy mode, the real
server and service group are required along with the VIP. (Server and
proxy mode are configured as DNS options. See DNS Options on
page 435.)
Configuration on Site AX Device
To configure GSLB on the site AX devices:
1. Configure SLB, if not already configured.
2. Enable the GSLB protocol for the GSLB site device function.
438 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuration takes place at the following levels:
Global (system-wide on the GSLB AX device)
Zone
Service IP
Site
SLB device
The parameters you can configure at each level are described in GSLB
Parameters on page 479.
The following sections describe the GSLB configuration steps in the GUI
and in the CLI. Required commands and commonly used options are listed.
For advanced commands and options, see GSLB Parameters on page 479.
Each of the following configuration sections shows the CLI and GUI
methods for configuration. For complete configuration examples, see
Configuration Examples on page 506.
Note:
Configure Health Monitors

A10 Networks recommends that you configure health monitors for the local
DNS server to be proxied, and also for the GSLB services to be load balanced.
Use a DNS health monitor for the local DNS server. You also can use a
Layer 3 health monitor to check the IP reachability of the server.
For the GSLB service, use health monitors for the application types of the
services. For example, for an HTTP service, use an HTTP health monitor. If
the health-check metric is enabled in the GSLB policy, the metric will use
the results of service health checks to select sites.
To monitor the health of the real servers providing the services, configure
health monitors on the site SLB devices.
Configure the health monitors for the proxied DNS server and the GSLB
services on the GSLB AX device. Configure the health monitors for real
servers and their services on the site AX devices.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
439 of 950

Configuration of health monitors is the same as for standard SLB. There are
no special health monitoring options or requirements for GSLB. For configuration information, see Health Monitoring on page 373.
Configure the DNS Proxy

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

1. Select Config > Service > GSLB.
2. Click DNS Proxy, then click Add.
3. Enter a name for the DNS proxy.
4. Enter the IP address that will be advertised as the authoritative DNS
server for the GSLB zone.
Note:
The GUI will not accept the configuration if the IP address you enter here
is the same as the real DNS server IP address you enter when configuring
the service group for this proxy (below).
5. (Optional) To add this proxy configuration of the DNS server to a High
Availability (HA) group, select the group.
6. In the GSLB Port section, click Add.
7. In the Port field, enter the DNS port number, if not already filled in.
8. In the Service Group field, select create. The Service Group and
Server sections appear.
9. In the Name field, enter a name for the service group.
10. In the Type drop-down list, select UDP.
11. In the Server section, in the Server drop-down list, enter the IP address
of the DNS server. Enter the real IP address of the DNS server, not the
IP address you are assigning to the DNS proxy.
12. Enter the DNS port number in the Port field and click Add. The server
information appears.
13. Click OK. The GSLB Port section re-appears.
440 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

14. Click OK. The Proxy section re-appears.
15. Click OK. The DNS proxy appears in the DNS proxy table.
USING THE CLI

1. To configure a real server for the DNS server to be proxied, use the following commands:
Use this command at the global configuration level of the CLI. The
command creates the proxy and changes the CLI to the configuration
level for it.
To configure the DNS port on the server, use the following command to
change the CLI to the configuration level for the port:
port port-num udp
To enable health monitoring of the DNS service, use the following command:
(Layer 3 health monitoring using the default Layer 3 health monitor is
already enabled by default.)
2. To configure a service group and add the DNS proxy (real server) to it,
slb service-group group-name udp
command creates the service group and changes the CLI to the configuration level for it. To add the DNS server to the service group, use the
following command:
member server-name:port-num
3. To configure a virtual server for the DNS proxy and bind it to the real
server and service group, use the following commands:
command creates the virtual server changes the CLI to the configuration
level for it. To add the DNS port, use the following command:
port port-number udp
This command changes the CLI to the configuration level for the DNS
port. To bind the DNS port to the DNS proxy service group and enable
GSLB on the port, use the following commands:
gslb-enable
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
441 of 950

Configure a GSLB Policy

The GSLB policy contains the metrics used to evaluate each site and select
the best site for a client request.
Configuring a GSLB policy is optional. By default, the default policy is
used unless you configure and apply a different policy.
In the default GSLB policy, the following metrics are enabled by default:
health-check
geographic
round-robin
The other metrics are disabled. (For detailed information about policy
parameters and their defaults, see GSLB Parameters on page 479.)
Note:
Although the geographic metric is enabled by default, there are no default

geo-location mappings. To use the geographic metric, you must load or
manually configure geo-location mappings. (See Loading or Configuring Geo-Location Mappings on page 459 later in this section.)
Enabling / Disabling Metrics

To enable or disable a metric, use either of the following methods.
Using the GUI
2. On the menu bar, select Policy.
3. Click on the policy name or click Add to create a new policy.
4. If you are configuring a new policy, enter a name in the Name field in
the General section.
5. In the Metrics section, drag-and-drop the metric from one column to the
other. For example, to disable the health-check metric, drag-and-drop it
from the In Use column to the Not In Use column.
If you are enabling a metric, drag it to the position you want it to be used
in the processing order. For example, if you are enabling the Admin
Preference metric and you want this metric to be used first, drag-anddrop the metric to the top of the In Use column.
442 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

6. In the DNS Options section, configure the DNS options, if applicable to
your deployment. (For descriptions, see DNS Options on page 435
and Table 13, GSLB Policy Parameters, on page 494.)
7. Click OK.
Using the CLI
To enable a metric, enter the metric name at the configuration level for the
policy. For example, to enable the admin-preference metric, enter the following command:
AX(config gslb-policy)#admin-preference
To disable a GSLB metric, use the no form of the command for the metric, at the configuration level for the policy. For example, to disable the
health-check metric, enter the following command at the configuration level
for the policy:
AX(config gslb-policy)#no health-check
To set DNS options, use the following command at the configuration level
for the policy. (For descriptions, see DNS Options on page 435 and
Table 13, GSLB Policy Parameters, on page 494.)
[no] dns
{
action |
active-only |
addition-mx |
backup-alias |
best-only [max-answers] |
cache [aging-time {seconds | ttl}] |
cname-detect |
external-ip |
geoloc-action |
geoloc-alias |
geoloc-policy |
ip-replace |
ipv6 options |
logging {both | query | response}
[geo-location name | ip ipaddr] |
server [addition-mx] [authoritative [full-list]]
[mx] [ns [auto-ns]] [ptr [auto-ptr]] [srv] |
sticky
[/prefix-length]
[aging-time
minutes]
[ipv6-mask mask-length] |
ttl num
}
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
443 of 950

Changing the Metric Order

To change the metric order, use either of the following methods.
Using the GUI
3. Click on the policy name or click Add to create a new policy.
4. If you are configuring a new policy, enter a name in the Name field in
the General section.
5. In the Parameters section, drag-and-drop the metric to the position in
which you want it to be used in the processing order. For example, if
you want the admin-preference metric to be used first, drop the metric to
the top of the In Use column.
6. Click OK.
Using the CLI
To change the positions of metrics in a GSLB policy, use the following
command at the configuration level for the policy:
[no] metric-order metric [metric ...]
The metric option specifies a metric and can be one of the following:
active-rtt
active-servers
admin-preference
bw-cost
capacity
connection-load
geographic
health-check
least-response
num-session
ordered-ip
444 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

passive-rtt
weighted-ip
weighted-site
Metric order does not apply to the alias-admin-preference or weightedalias metrics.
Note:
Configuring RTT Settings

If you are planning to use the active-RTT or passive-RTT metric, read this
section. Otherwise, you can skip the section. Both these metrics are disabled
by default.
Active RTT
Active RTT measures the round-trip-time for a DNS query and reply
between a site AX device and the GSLB local DNS.
The active RTT metric is disabled by default. You can enable it to take
either a single sample (single shot) or multiple samples at regular intervals.
You can configure active RTT to take a single sample or periodic samples.
Global Active RTT Parameters
The Active RTT metric uses the following options, which are configurable
on a global basis:
Domain Specifies the query domain. To measure the active round-trip
time (RTT) for a client, the site AX device sends queries for the domain
name to a clients local DNS. An RTT sample consists of the time
between when the site AX device sends a query and when it receives the
response.
Only one active-RTT domain can be configured. It is recommended to
use a domain name that is likely to be in the cache of each clients local
DNS. The default domain name is google.com.
The AX device averages multiple active-RTT samples together to calculate the active-RTT measurement for a client. (See the description of
Track below.)
Interval Specifies the number of seconds between queries. You can
specify 1-120 seconds. The default is 1.

Retry Specifies the number of times GSLB will resend a query if there
is no response. You can specify 0-16. The default is 3.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
445 of 950

Sleep Specifies the number of seconds GSLB stops tracking active-
RTT data for a client after a query fails. You can specify 1-300 seconds.
The default is 3.
Timeout Specifies the number of milliseconds GSLB will wait for a
reply before resending a query. You can specify 1-1023 milliseconds

(ms). The default is 1000 ms.
Track Specifies the number of seconds during which the AX device
collects samples for a client. The samples collected during the track time
are averaged together, and the averaged value is used as the active RTT
measurement for the client. You can specify 15-3600 seconds. The
default is 60 seconds.
The averaged RTT measurement is used until it ages out. The aging time
for averaged RTT measurements is 10 minutes by default and is configurable on individual sites, using the active-rtt aging-time command.
To configure global active-RTT options, use the following command at the
[no] gslb active-rtt
{
domain domain-name |
interval seconds |
retry num |
sleep seconds |
timeout ms |
track seconds
}
Default Settings
When you enable Active RTT, a site AX device sends 5 DNS requests to the
GSLB domains local DNS. The GSLB AX device averages the RTT times
of the 5 samples.
Single Sample (Single Shot)
To take a single sample and use that sample indefinitely, use the single-shot
option. This option instructs each site AX device to send a single DNS
query to the GSLB local DNS.
The single-shot option is useful if you do not want to frequently update the
active RTT measurements. For example, if the GSLB domain's clients tend
to remain logged on for long periods of time, using the single-shot option
ensures that clients are not frequently sent to differing sites based on active
RTT measurements.
446 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The single-shot has the following additional options:
timeout Specifies the number of seconds each site AX device should
wait for the DNS reply. If the reply does not arrive within the specified
timeout, the site becomes ineligible for selection, in cases where selection is based on the active RTT metric. You can specify 1-255 seconds.
The default is 3 seconds.
skip Specifies the number of site AX devices that can exceed their sin-
gle-shot timeouts, without the active RTT metric itself being skipped by
the GSLB AX device during site selection. You can skip from 1-31 sites.
The default is 3.
Multiple Samples
To periodically retake active RTT samples, do not use the single-shot
option. In this case, the AX device uses the averaged RTT based on the
number of samples measured for the intervals.
For example, if you set active RTT to use 3 samples with an interval of 5
seconds, the RTT is the average RTT for the last 3 samples, collected in 5second intervals. If you configure single-shot instead, a single sample is
taken.
The number of samples can be 1-8. The default is 5 samples.
Store-By
By default, the GSLB AX device stores one active RTT measurement per
site SLB device. Optionally, you can configure the GSLB AX device to
store one measurement per geo-location instead. This option is configurable
on individual GSLB sites. (See Changing Active RTT Settings for a Site
on page 449.)
Tolerance
The default measurement tolerance is 10 percent. If the RTT measurements
for more than one site are within 10 percent, the GSLB AX device considers
the sites to be equal in terms of active RTT. You can adjust the tolerance to
any value from 0-100 percent.
Enabling Active RTT
To enable active RTT, use either of the following methods.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
447 of 950

USING THE GUI

3. Click on the policy name or click Add to create a new one.
4. Drag-and-drop Active RTT from the Not In Use column to the In Use
column.
5. Click the plus sign to display the Active RTT configuration fields.
6. To use single-shot RTT, select the Single-shot checkbox. To collect multiple samples, do not select the Single-shot checkbox.
7. To change settings for single-shot, edit the values in the Timeout and
Skip fields.
8. To change settings for multiple samples, edit the values in the Samples
and Tolerance fields.
9. Click OK.
USING THE CLI

Enter the following command at the configuration level for the GSLB policy:
[no] active-rtt
[difference num]
[fail-break]
[ignore-id group-id]
[keep-tracking]
[limit ms]
[samples num-samples]
[single-shot] [skip count] [timeout seconds]
[tolerance num-percentage]
If you omit all the options, the site AX device send 5 DNS requests to the
GSLB domains local DNS. The GSLB AX device averages the RTT times
of the 5 samples. The active RTT measurements are regularly updated. You
can use the samples option to change the number of samples to 1-8.
To enable single-shot RTT instead, use the single-shot option. For singeshot, you also can use the skip and timeout options. (See the descriptions
above, in Single Sample (Single Shot) on page 446)
448 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

CLI Examples
The following commands access the configuration level for GSLB policy
gslbp2 and enable the active RTT metric, using all the default settings:
AX(config)#gslb policy gslbp2
AX(config gslb-policy)#active-rtt
The following commands access the configuration level for GSLB policy
gslbp3 and enable the active RTT metric, using single-shot settings:
AX(config)#gslb policy gslbp3
AX(config gslb-policy)#active-rtt single-shot
AX(config gslb-policy)#active-rtt skip 3
In this example, each site AX device will send a single DNS query to the
GSLB domains local DNS, and wait 3 seconds (the default) for a reply. The
site AX devices will then send their RTT measurements to the GSLB AX
device. However, if more than 3 site AX devices fail to send their RTT measurements to the GSLB AX device, the AX device will not use the active
RTT metric.
Changing Active RTT Settings for a Site
You can adjust the following Active RTT settings on individual sites:
aging-time Specifies the maximum amount of time a stored active-
RTT result can be used. You can specify 1-60 minutes. The default is 10
minutes.
bind-geoloc Stores the active-RTT measurements on a per geo-loca-
tion basis. Without this option, the measurements are stored on a per
site-SLB device basis.
ignore-count Specifies the ignore count if RTT is out of range. You
can specify 1-15. The default is 5.

ipv6-mask Specifies the client IPv6 mask length, 1-128. The default is
128.
limit Specifies the limit. You can specify 1-1023. The default is 1023.
mask Specifies the maximum RTT allowed for the site. If the RTT
measurement for a site exceeds the configured limit, GSLB does not
eliminate the site. Instead, GSLB moves to the next metric in the policy.
You can specify 0-16383 milliseconds (ms). The default is 16383.
range-factor Specifies the maximum percentage a new active-RTT
measurement can differ from the previous measurement. If the new

measurement differs from the previous measurement by more than the
allowed percentage, the new measurement is discarded and the previous
measurement is used again.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
449 of 950

For example, if the range-factor is set to 25 (the default), a new measurement that has a value from 75% to 125% of the previous value can
be used. A measurement that is less than 75% or more than 125% of the
previous measurement can not be used.
You can specify 1-1000. The default is 25.
smooth-factor Blends the new measurement with the previous one, to
smoothen the measurements.

For example, if the smooth-factor is set to 10 (the default), 10% of the
new measurement is used, along with 90% of the previous measurement. Similarly, if the smooth-factor is set to 50, 50% of the new measurement is used, along with 50% of the previous measurement.
You can specify 1-100. The default is 10.
USING THE GUI

Use the Options section of the GUI page for the site.
USING THE CLI

Use the following command at the configuration level for the site:
[no] active-rtt
aging-time minutes |
bind-geoloc |
limit num |
mask {/mask-length | mask-ipaddr} |
range-factor num |
smooth-factor num
Excluding a Set of IP Addresses from Active-RTT Polling
You can use an IP list to exclude a set of IP addresses from active-RTT polling. You can configure an IP list in either of the following ways:
Use a text editor on a PC or use the AX GUI to configure a black/white
list, then load the entries from the black/white list into an IP list.
Use this command to configure individual IP list entries.
USING THE CLI

To configure an IP list using the CLI, use the following command at the
[no] gslb ip-list list-name
450 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The command changes the CLI to the configuration level for the list, where
the following IP-list-related commands are available:
[no] ip ipaddr {subnet-mask | /mask-length}
id group-id
This command creates an IP entry in the list. Based on the subnet mask or
mask length, the entry can be a host address or a subnet address. The id
option adds the entry to a group. The group-id can be 0-31.
[no] load bwlist-name
This command loads the entries from a black/white list into the IP list. For
information on configuring a black/white list, see Configuring a Black/
White List on page 751.
To use the IP list to specify the IP addresses to exclude from active-RTT
data collection, use the following command at the configuration level for
the GSLB policy:
[no] active-rtt ignore-id group-id
USING THE GUI

In the current release, IP lists can not be configured using the GUI.
Note:
Passive RTT
Passive RTT measures the round-trip-time between when the site AX
device receives a clients TCP connection (SYN) and the time when the site
AX device receives acknowledgement (ACK) back from the client for the
connection.
Enabling Passive RTT
To enable passive RTT, use either of the following methods.
USING THE GUI

3. Click on the policy name or click Add to create a new one.
4. Drag-and-drop Passive RTT from the Not In Use column to the In Use
column.
5. Click the plus sign to display the Passive RTT configuration fields.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
451 of 950

6. To change sample settings, edit the values in the Samples and Tolerance
fields. (These parameters work the same as they do for active RTT. See
Multiple Samples on page 447 and Tolerance on page 447.)
7. Click OK.
USING THE CLI

Enter the following command at the configuration level for the GSLB policy:
[no] passive-rtt
[difference num]
[fail-break]
Changing Passive RTT Settings for a Site
You can adjust Passive RTT settings on individual sites. The types of settings used by Passive RTT settings are the same as those used for Active
RTT. See Changing Active RTT Settings for a Site on page 449.
USING THE GUI

Note:
In the current release, passive RTT settings for a site cannot be changed
using the GUI.
USING THE CLI

[no] passive-rtt
bind-geoloc |
limit num |
range-factor num |
smooth-factor num
Configuring BW-Cost Settings

If you are planning to use the bw-cost metric, read this section. Otherwise,
you can skip the section. The bw-cost metric is disabled by default.
The bw-cost metric selects sites based on bandwidth utilization on the site
AX links.
452 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

How Bandwidth Cost Is Measured
To compare sites based on bandwidth utilization, the GSLB AX device
sends SNMP GET requests for a specified MIB interface object, such as
ifInOctets, to each site.
If the SNMP object value has incremented less than or equal to the
bandwidth limit configured for the site, the site is eligible to be selected
as the best site.
If the SNMP object value has incremented more than the bandwidth
limit configured for the site, the site is ineligible.

The GSLB AX device sends the SNMP requests at regular intervals. Once a
site is ineligible, the site can become eligible again at the next interval if the
utilization incrementation is below the configured limit minus the threshold
percentage. (See below.)
Configuration Requirements
To use the bw-cost metric, an SNMP template must be configured and
bound to each site. The GSLB SNMP template specifies the SNMP version
and other information necessary to access the SNMP agent on the site AX
device, and the Object Identifier (OID) of the MIB object to request.
In addition, the following bw-cost parameters must be configured on each
site:
Bandwidth limit The bandwidth limit specifies the maximum value by
which the requested MIB object can increment, for the site to be eligible
for selection as the best site.
Bandwidth threshold For a site to regain eligibility when bw-cost is
being compared, the SNMP objects incremental value must be below

the threshold-percentage of the limit value.
For example, if the limit value is 80000 and the threshold is 90, the limit
value must increment by 72000 or less, in order for the site to become
eligible again based on bandwidth cost. Once a site again becomes eligible, the SNMP objects value is again allowed to increment by as much
as the bandwidth limit value (80000, in this example).
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
453 of 950

Configuring Bandwidth Cost
To use the bw-cost metric:
1. On the site AX devices, configure and enable SNMP.
2. On the GSLB AX device:
a. Configure a GSLB SNMP template.
b. Add the template to the GSLB site configuration.
c. Optionally, set the bandwidth limit and threshold on the site. By
default, the bandwidth limit is not set (unlimited).
d. Enable the bw-cost metric in the GSLB policy. By default, the bwcost metric is disabled.
USING THE GUI

Note:
SNMP template configuration is not supported in the GUI. Use the CLI to
configure the template, then use the following GUI procedures.
USING THE CLI

To Configure a GSLB SNMP Template
[no] gslb template snmp template-name
This command adds the template and changes the CLI to the configuration
level for the template, where the following template-related commands are
available:
[no] version {v1 | v2c | v3}
The version command specifies the SNMP version running on the site AX
device.
[no] host ipaddr
[no] oid oid-value
The host command specifies the IP address of the site AX device.
The oid command specifies the interface MIB object to query on the site
AX device.
Note:
454 of 950
If the object is part of a table, make sure to append the table index to the
end of the OID. Otherwise, the AX device will return an error.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SNMPv1 / v2c Commands:
[no] community community-string
The community command specifies the community string required for
authentication.
SNMPv3 Commands:
[no] username name
This command specifies the SNMPv3 username required for access to the
SNMP agent on the site AX device.
[no] security-level
{no-auth | auth-no-priv | auth-priv}
This command specifies the SNMPv3 security level:
no-auth Authentication is not used and encryption (privacy) is not
used. This is the default.

auth-no-priv Authentication is used but encryption is not used.
auth-priv Both authentication and encryption are used.
[no] auth-proto {sha | md5}

[no] auth-key string
These commands are applicable if the security level is auth-no-priv or
auth-priv. The auth-proto command specifies the authentication protocol.
The auth-key command specifies the authentication key. The key string can
be 1-127 characters long.
[no] priv-proto {aes | des}
[no] priv-key string
These commands are applicable only if the security level is auth-priv. The
priv-proto command specifies the privacy protocol used for encryption.
The priv-key command specifies the encryption key. The key string can be
1-127 characters long.
[no] context-engine-id id
[no] context-name id
[no] security-engine-id id
The context-engine-id command specifies the ID of the SNMPv3 protocol
engine running on the site AX device. The context-name command specifies an SNMPv3 collection of management information objects accessible
by an SNMP entity. The security-engine-id command specifies the ID of
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
455 of 950

the SNMPv3 security engine running on the site AX device. For each command, the ID is a string 1-127 characters long.
[no] interface id
The interface command specifies the SNMP interface ID.
Additional Commands:
[no] interval seconds
[no] port port-num
The interval command specifies the amount of time between each SNMP
GET to the site AX devices. You can specify 1-999 seconds. The default
is 3.
The port command specifies the protocol port on which the site AX devices
listen for the SNMP requests from the GSLB AX device. You can specify 165535. The default is 161.
To Apply a GSLB SNMP Template to a GSLB Site
[no] template template-name
To Configure the Bandwidth Limit and Threshold on a Site
[no] bw-cost limit limit threshold percentage
The limit specifies the maximum amount the SNMP object queried by the
GSLB AX device can increment since the previous query, in order for the
site to remain eligible for selection as the best site. You can specify 02147483647. There is no default.
If a site becomes ineligible due to being over the limit, the percentage
parameter is used. In order to become eligible for selection again, the sites
limit value must not increment more than
limit*threshold-percentage.
You can specify 0-100. There is no default.
To Enable the Bandwidth Cost Metric in a GSLB Policy
Use the following command at the configuration level for the policy:
[no] bw-cost
456 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

AX-1(config)#show gslb site usa bw-cost
U = Usable, TI = Time Interval
USGN = Unsigned, SN64 = Unsigned 64
CNTR = Counter, CT64 = Counter 64
Site
Template
Current
Highest
Limit
U Type Len
Value
TI
-------------------------------------------------------------------------------usa
snmp-1
31091
142596
100000
Y CNTR
4
3355957308 3
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
457 of 950

CLI Example SNMPv3
The following commands configure a GSLB SNMP template for SNMPv3.
In this example, authentication and encryption are both used.
AX(config)#gslb template snmp snmp-2
AX(config-gslb template snmp)#security-level auth-priv
AX(config-gslb template snmp)#host 192.168.214.124
AX(config-gslb template snmp)#username read
AX(config-gslb template snmp)#oid .1.3.6.1.2.1.2.2.1.16.12
AX(config-gslb template snmp)#priv-proto des
AX(config-gslb template snmp)#auth-key 12345678
AX(config-gslb template snmp)#priv-key 12345678
The other commands are the same as those shown in CLI Example
SNMPv2c on page 457.
Configuring Alias Admin Preference

To configure the Alias Admin Preference metric:
1. At the configuration level for the GSLB service, assign an administrative preference to the DNS CNAME record for the service.
2. At the configuration level for the GSLB policy:
Enable the Alias Admin Preference metric.
Enable one or both of the following DNS options, as applicable to
your deployment:
DNS backup-alias
DNS geoloc-alias
3. If using the backup-alias option, use the dns-cname-record as-backup
option on the service.
USING THE GUI

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

1. To assign an administrative preference to the DNS CNAME record for a
service, use the following command at the configuration level for the
service:
[no] admin-preference preference
The preference can be 0-255. A higher value is preferred over a lower
value. The default is 0 (not set).
458 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

2. To enable the Alias Admin Preference metric, use the following command at the configuration level for the policy:
[no] alias-admin-preference
Configuring Weighted Alias

To configure the Weighted Alias metric:
1. At the configuration level for the GSLB service, assign a weight to the
DNS CNAME record for the service.
2. At the configuration level for the GSLB policy:
Enable the Weighted Alias metric.
Enable one or both of the following DNS options, as applicable to
your deployment:
DNS backup-alias
DNS geoloc-alias
3. If using the backup-alias option, use the dns-cname-record as-backup
option on the service.
USING THE GUI

USING THE CLI

1. To assign a weight to the DNS CNAME record for a service, use the following command at the configuration level for the service:
[no] weight num
The num can be 1-255. A higher value is preferred over a lower value.
The default is 1.
2. To enable the Weighted Alias metric, use the following command at the
configuration level for the policy:
[no] weighted-alias
Loading or Configuring Geo-Location Mappings

You can configure geo-location mappings manually or by loading the mappings from a file. Unless you have only a few sites, configuring the geolocation mappings manually might not be practical. A10 Networks recommends that you load the mappings from a file.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
459 of 950

The geo-location configuration options are described in detail below. To
skip the descriptions and go directly to configuration instructions, see one of
the following sections. Each section provides the procedure for one of the
methods to configure geo-location mappings.
Creating and Loading a Custom Geo-Location Database on page 462
Manually Configuring Geo-Location Mappings on page 465
Geo-Location Database Files

You can load the geo-location database from one of the following types of
files:
Internet Assigned Numbers Authority (IANA) database The IANA
database contains the geographic locations of the IP address ranges and

subnets assigned by the IANA. The IANA database is loaded by default.
Custom database in CSV format You can load a custom geo-location
database from a file in comma-separated-values (CSV) format. This

option requires configuration of a CSV template on the AX device.
When you load the CSV file, the data is formatted based on the template.
Note:
You can load more than one geo-location database. When you load a new
database, if the same IP address or IP address range already exists in a
previously loaded database, the address or range is overwritten by the new
database.
Geo-Location Mappings
A geo-location mapping consists of a geo-location name and an IP address
or IP range.
If you manually map a geo-location to an GSLB site, GSLB uses the
mapping.
If no geo-location is configured for a GSLB site, GSLB automatically
maps the service-ip to a geo-location in the loaded geo-location database.

If a service-ip cannot be mapped to a geo-location, GSLB maps the site
AX device to a geo-location.
If more than one geo-location matches a clients IP address, the most specific match is used. For example, if a client is in the same city as a site AX,
that site will be preferred. If the client and site are in the same state but in
different cities, the site in that state will be preferred.
460 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Only one database can be active. If you load more than one database, the
most-recently loaded one becomes the active one. The older database is no
longer used. Data from the older database is not merged into the new database.
Example Database File
An example of a database file is shown below. Each paragraph is actually a
single line in the file, but they are displayed here in multiple lines due to the
limited width of the page.
"1159363840","1159364095","US","UNITED STATES","NA","NORTH AMERICA","EST","MA","MASSACHUSETTS", "COMMRAIL INC","MARLBOROUGH","MIDDLESEX","42.3495","-71.5482"
"1159364096","1159364351","US","UNITED STATES","NA","NORTH AMERICA","","","","ENVIRONMENTAL COMPLIANCE SERVICE","SILVER","","32.0708","-100.682"
"1159364352","1159364607","US","UNITED STATES","NA","NORTH AMERICA","EST","MA","MASSACHUSETTS", "MLS PROPERTY INFORMATION NETWORK","SHREWSBURY","WORCESTER","42.2959","71.7134"
...
The example above shows the file displayed in a text editor. The same file
looks like the example in Figure 131 if displayed in a spreadsheet application. However, when the file is saved to CSV format, the file is essentially
as shown above.
FIGURE 131
CSV File in Spreadsheet Application
The database file can contain more types of information (fields) than are
required for the GSLB database. When you load the file into the geo-location database, the CSV template on the AX device is used to filter the file to
extract the required data. In this example, only the fields shown in bold type
will be extracted and placed into the geo-location database:
"1159363840","1159364095","US","UNITED STATES","NA","NORTH AMERICA","EST","MA","MASSACHUSETTS","COMMRAIL INC","MARLBOROUGH","MIDDLESEX","42.3495","-71.5482"
These fields contain the following information:

From IP address (starting IP address in range), To IP address (ending IP address in
range, or subnet mask), Continent, Country
The IP addresses in this example are in bin4 format. Dotted decimal format
(for example: 69.26.125.0) is also supported. If you use bin4 format, the AX
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
461 of 950

device automatically converts the addresses into dotted decimal format
when you load the database into GSLB.
Converting IP Addresses into bin4 Format
If you want to use bin4 format in the CSV file, here is how to convert an IP
address from dotted-decimal format to bin4 format:
1. Convert each node into Hex.
2. Convert the resulting Hex number into decimal.
3. Enter the decimal number into the database file.
Here is an example for IP address 69.26.125.0, the first IP address in the
example CSV file:
Dotted Decimal
Hex of Each Node
Combined
Hex Number
Decimal
69.26.125.0
45.1a.7d.00
451a7d00
1159363840
CSV File Field Delimiters

The fields in the CSV file must be separated by a delimiter. By default, the
AX device interprets commas as delimiters. When you configure the CSV
template on the AX device, you can set the delimiter to any valid ASCII
character.
Creating and Loading a Custom Geo-Location Database
To create and load a custom geo-location database:
1. Prepare the database file. (This step requires an application that can
save to text for CSV format, and can not be performed on the AX
device.)
2. Configure a CSV template for the file. The CSV template specifies the
field positions for IP address and location information.
3. Import the CSV file onto the AX device.
4. Load the CSV file.
5. Display the geo-location database.
462 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

Configuring the CSV Template
2. On the menu bar, select Geo-location > Import.
3. In the Template section, enter name for the template.
4. If the CSV file uses a character other than a comma to delimit fields,
enter the delimiter character in the Delimiter field.
5. In each data field, indicate the fields position in the CSV file. For example, if the destination IP address or subnet is listed in the CSV file in
data field 4, enter 4 in the IP-To field.
6. Click Add.
Importing the CSV File
1. Select Config > Service > GSLB, if not already selected.
2. On the menu bar, select Geo-location > Import, if not already selected..
3. In the File section, select the file transfer protocol.
4. Enter the filename and the access parameters required to copy the file
from the remote server.
5. Click Add.
Loading the CSV File Data into the Geo-Location Database
1. Select Config > Service > GSLB, if not already selected.
2. On the menu bar, select Geo-location > Import, if not already selected..
3. In the Load/Unload section, enter the name of the geo-location database
in the file field.
4. In the Template field, enter the name of the template to use for formatting the data.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
463 of 950

USING THE CLI

Configuring the CSV Template
On the AX device, you must configure a CSV template for the database file.
When you load the file into GSLB, the AX device uses the template to
extract the data and load it into the GSLB database.
1. Use the following command at the global configuration level of the
CLI:
[no] gslb template csv template-name
This command creates the template and changes the CLI to the configuration level for it.
2. Use the following command to identify the field positions for the geolocation data:
[no] field num {ip-from | ip-to-mask |
continent | country | state | city}
The num option specifies the field position within the CSV file. You can
specify 1-64. The following options specify the type of geo-location
data that is located in the field position:
ip-from Specifies the beginning IP address in the range or subnet.
ip-to-mask Specifies the ending IP address in the range, or the
subnet mask.
continent Specifies the continent where the IP address range or
subnet is located.
country Specifies the country where the IP address range or subnet
is located.
state Specifies the state where the IP address range or subnet is
located.
city Specifies the city where the IP address range or subnet is
located.
3. If the CSV file uses a character other than a comma to delimit fields, use
the following command to specify the character used in the file:
[no] delimiter {character | ASCII-code}
You can type the character or enter its decimal ASCII code (0-255).
Importing the CSV File
To import the CSV file onto the AX device, use the following command at
the Privileged EXEC or global configuration level of the CLI:
import geo-location file-name [use-mgmt-port] url
464 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
(For information about the use-mgmt-port option, see Using the Management Interface as the Source for Management Traffic on page 929.)
Loading the CSV File Data into the Geo-Location Database
To load the CSV file, use the following command at the global configuration level of the CLI:
[no] gslb geo-location load file-name
csv-template-name
Use the file name you specified when you imported the CSV file, and the
name of the CSV template to be used for extracting data from the file.
The file-name option is available only if you have already imported a geolocation database file.
Note:
To display information about CSV files that have been loaded are currently
being loaded, use the following command:
show gslb geo-location file [file-name]
Manually Configuring Geo-Location Mappings
USING THE GUI

In the GUI, this is part of site configuration. See Configure Sites on
page 475.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
465 of 950

USING THE CLI

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

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

2. On the menu bar, select Geo-location > Find.
The geo-location database appears. You can use the find options to display
database entries or statistics for specific geo-locations or IP addresses.
USING THE CLI

To display the geo-location database, use the following command:
show gslb geo-location db [geo-location-name]
[[statistics] ip-range range-start range-end]
[[statistics] depth num]
[statistics]]
The geo-location-name option displays the database entry for the specified
location.
466 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The ip-range option displays entries for the specified IP address range.
The depth num option filters the display to show only the location entries at
the specified depth or higher. For example, to display only continent and
country entries and hide individual state and city entries, specify depth 2.
To search for an entry in the geo-location database based on client IP
address, use the following command:
show gslb geo-location ip ipaddr
CLI Example
The commands in this example load a custom geo-location database from a
CSV file called test.csv, and display the database. The test.csv file is
shown in Example Database File on page 461.
First, the following commands configure the CSV template:
AX(config)#gslb template csv test1-tmplte
AX(config-gslb template csv)#field 1 ip-from
AX(config-gslb template csv)#field 2 ip-to-mask
AX(config-gslb template csv)#field 5 continent
AX(config-gslb template csv)#field 3 country
AX(config-gslb template csv)#exit
The following command imports the file onto the AX device:

AX(config)#import geo-location test1.csv ftp:
User name []?admin2
Password []?*********
File name [/]?test1.csv
The following commands initiate loading the data from the CSV file into
the geo-location database, and display the status of the load operation:
AX(config)#gslb geo-location load test1.csv test1-tmplte
AX(config)#show gslb geo-location file
T = T(Template)/B(Built-in), Per = Percentage of loading
Filename
T Template
Per Lines
Success Error
-----------------------------------------------------------------------------test1
T t1
98% 11
10
0
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
467 of 950

The following command displays the geo-location database. The data that
was extracted from the CSV file is shown here in bold type.
AX(config)#show gslb geo-location db
Last = Last Matched Client, Hits = Count of Client matched
T = Type, Sub = Count of Sub Geo-location
G(global)/P(policy), S(sub)/R(sub range)
M(manually config)
Global
Name
From
To
Last
Hits
Sub T
-----------------------------------------------------------------------------NA
(empty)
(empty)
(empty)
0
1
G
Geo-location: NA, Global
Name
From
To
Last
Hits
Sub T
-----------------------------------------------------------------------------US
(empty)
(empty)
(empty)
0
10
GS
Geo-location: NA.US, Global
Name
From
To
Last
Hits
Sub T
-----------------------------------------------------------------------------69.26.125.0
69.26.125.255
(empty)
0
0
GR
69.26.126.0
69.26.126.255
(empty)
0
0
GR
69.26.127.0
69.26.127.255
(empty)
0
0
GR
69.26.128.0
69.26.136.135
(empty)
0
0
GR
69.26.136.136
69.26.136.143
(empty)
0
0
GR
69.26.136.144
69.26.140.255
(empty)
0
0
GR
69.26.141.0
69.26.141.255
(empty)
0
0
GR
69.26.142.0
69.26.159.255
(empty)
0
0
GR
69.26.160.0
69.26.160.255
(empty)
0
0
GR
69.26.161.0
69.26.161.7
(empty)
0
0
GR
Configure Services
To configure GSLB services, use either of the following methods.
USING THE GUI

2. On the menu bar, select Service IP.
3. Click Add.
4. Enter the service name and IP address.
468 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

5. If needed, assign an external IP address to the service IP. The external IP
address allows a service IP that has an internal IP address to be reached
from outside the internal network.
6. Add the service port(s):
a. Enter the port number and select the protocol (TCP or UDP).
b. Optionally, select a health monitor.
c. Click Add. The service port appears in the service port list.
7. Click OK.
8. Repeat for each service IP.
USING THE CLI

To configure service VIPs, use the following command at the global configuration level of the CLI:
gslb vip-name ipaddr
This command changes the CLI to the configuration level for the service.
To assign an external IP address to the service, use the following command.
An external IP address is needed if the service IP address is an internal IP
address that can not be reached from outside the internal network.
external-ip ipaddr
To configure a service port on the service, use the following command to
change the CLI to the configuration level for the port:
To enable health monitoring of the service, use the following command:
Gateway Health Monitoring

To simplify health monitoring of a GSLB site, you can use a gateway health
check. A gateway health check is a Layer 3 health check (ping) sent to the
gateway router for an SLB site. If a sites gateway router fails a health
check, it is likely that none of the services at the site can be reached. GSLB
stops using the site until it begins to pass gateway health checks again.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
469 of 950

In most cases, an ICMP health check is sufficient. You can use the default
ICMP health check or configure a custom one. For more detailed health
analysis, you can use an external health check. For example, you can use a
script to get SNMP information from the gateway, and base the gateways
health status on the retrieved information.
Health Check Precedence
Health checking for a GSLB service can be performed at the following levels.
1. Gateway health check
2. Port health check
3. IP health check (Layer 3 health check of service IP)
If the gateway health check is unsuccessful, the service IP is marked Down.
If the gateway health check is successful, the port health check is used if
ports are configured on the service IP. Otherwise, if no service ports are
configured on the service IP, the Layer 3 health check is used.
Configuring Gateway Health Checking for GSLB Sites
To configure gateway health checking for a GSLB site:
1. Configure the health monitor, unless you plan to use the default ICMP
health monitor.
2. On the SLB device at the site, create an SLB real server configuration
with the gateway routers IP address. If you configured a custom health
check, make sure to apply it to the real server.
3. On the GSLB controller, specify the sites gateway IP address in the
SLB-device configuration for the site.
Sites with Multiple Gateway Links
If a site has multiple gateways, create a separate real server for each gateway on the site AX device. On the GSLB controller, create a separate SLBdevice configuration for each gateway (real server). In each SLB-device
configuration, specify only the service IPs that can be reached by the gateway specified in that SLB-device configuration.
For a service IP that can be reached on any of multiple links, create a separate SLB-device configuration, without using the gateway option. The gateway health status for this SLB-device will be Down only if all the gateway
health checks performed for the other SLB-device configurations for the
site fail.
470 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

Configuration of this feature does not use any new GUI pages or fields not
present in earlier releases.
1. On the site AX deviceTo create the gateway router, navigate to the
real server configuration page. Enter a name and the gateway IP
address. Do not add any ports.
If you plan to use the default Layer 3 health monitor, no further configuration is needed on the site AX device. If you plan to use a custom
ICMP monitor, configure the monitor, select create from the Health
Monitor drop-down list.
2. On the GSLB controllerTo specify the sites gateway IP address, navigate to the site configuration page. From this page, navigate to the
SLB-Device configuration page and enter the gateway IP address in the
Gateway field.
USING THE CLI

Configuration of this feature does not use any new CLI commands or
options not present in earlier releases.
1. On the site AX deviceTo create the gateway router, use the following
command at the global configuration level of the CLI on the site AX
device:
[no] slb server gateway-name gateway-ipaddr
If you plan to use the default Layer 3 health monitor, no further configuration is needed on the site AX device. If you plan to use a custom
ICMP monitor, configure the monitor, then use the following command
at the configuration level for the real server (gateway):
[no] health-check icmp-monitor-name
2. On the GSLB controllerTo specify the sites gateway IP address, use
the following command at the configuration level for the SLB device,
within the site configuration:
[no] gateway gateway-ipaddr
Disabling a Gateway Health Check
On the GSLB controller, you can disable gateway health checking at the
SLB-device configuration level or the service configuration level.
To disable gateway health checking at the SLB-device configuration level,
use the following command:
no gateway health-check
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
471 of 950

After you enter this command, the SLB device will stop accepting gateway
status information.
To disable gateway health checking at the service configuration level, use
no health-check gateway
After you enter this command, the service will stop using gateway health
checks.
Displaying the Health Status of a Site Gateway
To display the health status for a site gateway, use the following command:
show gslb slb-device
Note:
The health status of the individual virtual servers and service ports at the
site is not marked Down.
CLI ExampleSite with Single Gateway Link

On the site AX device, the following command configures a real server for
the gateway. The default ICMP health method is used.
Site-AX(config)#slb server 1.1.1.1
On the GSLB controller, the following commands enable gateway health

checking for site device site-ax:
GSLB-AX(config)#gslb site remote
GSLB-AX(config-gslb site)#slb-dev site-ax 10.1.1.1
GSLB-AX(config-slb dev)#gateway 1.1.1.1
The following command displays the gateway health status for GSLB sites:
GSLB-AX(config)#show gslb slb-device
Attrs = Attributes, APF = Administrative Preference
Sesn-Num/Uzn = Number/Utilization of Available Sessions
GW = Gateway Status, IPCnt = Count of Service-IPs
P = GSLB Protocol, L = Local Protocol
Device
IP
Attrs APF Sesn-Num
Uzn GW
IPCnt
-------------------------------------------------------------------------------local:self
127.0.0.1
100 0
0%
0
local:self2
127.0.0.1
100 0
0%
0
local:self3
127.0.0.1
100 0
0%
2
remote:site-ax
10.1.1.1
100 0
0% UP 0
In this example, the gateway health status for SLB-device configuration

site-ax on the remote site is Up.
472 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

CLI ExampleSite with Multiple Gateway Links

On the site AX device, the following commands configure real servers for
each of two gateway links. The default ICMP health method is used for each
link.
Site-AX(config-real server)#exit
On the GSLB controller, the following commands enable gateway health

checking for each of the sites links. A unique SLB-device name is used for
each link, even though both links are for the same SLB device (20.1.1.1).
GSLB-AX(config)#gslb site remote-link1
GSLB-AX(config-gslb site)#slb-dev site-ax-lnk1 20.1.1.1
GSLB-AX(config-slb dev)#exit
GSLB-AX(config-gslb site)#exit
GSLB-AX(config)#gslb site remote-link2
GSLB-AX(config-gslb site)#slb-dev site-ax-lnk2 20.1.1.1
If the same services can be reached through either link, an additional SLBdevice configuration is required:
GSLB-AX(config)#gslb site remote-link-both
GSLB-AX(config-gslb site)#slb-dev site-ax-lnkboth 20.1.1.1
No gateway is specified in the SLB-device configuration. The gateway

health status will be Up unless the health checks for 2.2.2.1 and 3.3.3.1 both
fail.
Multiple-Port Health Monitoring

GSLB supports multiple-port health checking for service IPs. When you use
a multiple-port health check for a service IP, the service IP is marked Up if
any of the ports passes the health check. It is not required for all ports to
pass the health check.
Default Health Monitors
The default health monitor for a service is the default Layer 3 health monitor (ICMP ping). The default health monitor for a service port is the default
TCP or UDP monitor, depending on the transport protocol.
By default, if the GSLB protocol is enabled and can reach the service,
health checking is performed over the GSLB protocol. Otherwise, health
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
473 of 950

checking is performed using standard network traffic instead. Optionally,
you can disable use of the GSLB protocol for health checking, on individual
service-IPs.
USING THE GUI

USING THE CLI

To configure a multiple-port health check, use the following command at
the configuration level for the service IP:
[no] health-check port port-num port-num [...]
You can specify up to 64 ports.
CLI Example
The following commands apply a custom HTTP health monitor to service
IP gslb-srvc2:
AX(config-gslb service-ip)#port 80
AX(config-gslb service-port)#health-check http
Note:
Applying a health monitor is required only if you do not plan to use the
default health monitors. (See Default Health Monitors on page 473.)
The following commands enable a multi-port health check for the HTTP
service www on service IP gslb-srvc2 in GSLB zone abc.com:
AX(config)#gslb zone abc.com

AX(config-gslb zone)#service http www
AX(config-gslb service)#health-check port 80 8080 8081
474 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configure Sites
To configure GSLB sites, use either of the following methods.
USING THE GUI

2. On the menu bar, select Site.
3. Click Add.
4. Enter the site name.
5. In the SLB-Device section, enter information about the AX devices that
provide SLB for the site:
a. Click Add.
b. Enter a name for the device.
c. Enter the IP address at which the GSLB AX device will be able to
reach the site AX device.
d. To add a service to this SLB device, select it from the drop-down list
in the VIP server section and click Add. Repeat for each service.
6. In the IP-Server section, add services to the site. Select a service from
the drop-down list and click Add. Repeat for each service.
7. To manually map a geo-location name to the site, enter the geo-location
name in the Geo-location section and click Add.
8. Click OK. The site appears in the Site table.
USING THE CLI

To configure the GSLB sites, use the following commands:
gslb site site-name
This command changes the CLI to the configuration level for the site. To
associate an IP service with this site, use the following command:
ip-server service-ip
The ipaddr is the IP address of a real server load balanced by the site.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
475 of 950

To specify the AX device that provides SLB at the site, use the following
command:
slb-dev device-name ip-addr
To add the GSLB VIP server to the SLB device, use the following command:
vip-server gslb service-name
The service-name is the GSLB service specified by the gslb vip-name
ipaddr command in Configure Services on page 468.
Configure a Zone
To configure a GSLB zone, use either of the following methods.
USING THE GUI

2. On the menu bar, select Zone.
3. Click Add.
4. Enter the zone name in the Name field.
5. In the Service section, click Add. (See Figure 140 on page 516.)
The service configuration sections appear.
6. In the Service field, enter the service name.
7. Select the service type from the Port drop-down list.
8. Add the services:
a.
b.
c.
d.
In the Service section, click Add.

Enter name for the service (for example, www).
Select the service type from the Port drop-down list.
Configure additional options, if applicable to your deployment. (See
Table 12, GSLB Parameters, on page 479.)
e. Click OK.
f. Repeat for each service.
9. Click OK. The zone appears in the GSLB zone list.
476 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

To configure the GSLB zone, use the following commands:
gslb zone zone-url
The zone-url is the URL that clients will send in DNS queries.
This command changes the CLI to the configuration level for the zone. To
add a service to the zone, use the following command:
service port service-name
The port is the application port for the server and must be the same port
name or number specified on the service VIP.
Enable the GSLB Protocol

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

2. On the menu bar, select Global.
The Global section appears.
3. Select Enabled next to one of the following options, depending on the
AX devices function in the GSLB configuration:
Run GSLB as Controller
Run GSLB as Site SLB Device
If you are planning to use the Passive RTT metric, select the Passive
RTT checkbox to enable collection of passive RTT data on this site
AX device.
4. Click OK.
USING THE CLI

To enable the GSLB protocol on the GSLB AX device, use the following
command at the global configuration level of the CLI:
gslb protocol enable controller
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
477 of 950

To enable the GSLB protocol on a site AX device, use the following command at the global configuration level of the CLI:
gslb protocol enable device [no-passive-rtt]
The no-passive-rtt option disables collection of passive RTT data on this
site AX device. If you are planning to use the Passive RTT metric, do not
use this option.
478 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
GSLB Parameters
health-checkTable 12 lists the GSLB parameters.
TABLE 12 GSLB Parameters

Parameter
protocol enable
Enables the GSLB protocol. The protocol must be

enabled on the GSLB AX device and on the site AX
devices.
Supported Values
Global GSLB Parameters

(Required)
[no] gslb protocol

{enable {controller |
device [no-passive-rtt]} |
status-interval seconds}
Controller or device.
Default: Disabled
When you enable the GSLB protocol,
the default status interval is 30 seconds.
On the GSLB AX device, use the controller option.

On the site AX devices, use the device option.
The status-interval option sets the number of seconds between GSLB status messages.
geo-location
(Optional)
Config > Service > GSLB > Global

Maps geographic locations to IP address ranges.
GSLB forwards client requests from addresses
within the range to the GSLB site that serves the
location.
To load the IANA database:
For geo-location mappings loaded

from a database, the mappings must be
in the AX devices IANA database or
in a comma-separated values (CSV)
file.
[no] gslb template csv templatename
For individual mappings, the locationname can be up to 127 alphanumeric

characters. Specify either the beginning and ending addresses of the
range, or the beginning address and the
network mask.
[no] gslb geo-location load

file-name csv-template-name
Default: The IANA database is loaded

by default.
[no] gslb geo-location load iana

Config > Service > GSLB > Geo-location > Import
To load a custom database:
Config > Service > GSLB > Geo-location > Import

To configure individual mappings:
[no] gslb geo-location
location-name
start-ip-addr [mask ip-mask]
[end-ip-addr]
Config > Service > GSLB > Site - Geo-location
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
479 of 950

GSLB Parameters
TABLE 12 GSLB Parameters (Continued)
Parameter
policy
(Optional)

Configures a GSLB policy. GSLB policies configure the GSLB metrics used to select the best sites
and site IP addresses to return in DNS replies to clients.
Supported Values
Default: The default GSLB policy is
used, unless you configure another
policy and apply it to the zone.
[no] gslb policy

{default | policy-name}
service-ip
(Required)
Config > Service > GSLB > Policy

Configures a virtual IP address (VIP) for a service.
In GSLB, service IP addresses are VIPs that represent services that are provided by servers connected
to the site AX devices.
The vip-name can be up to 31 alphanumeric characters.

The ipaddr can be an IPv4 or IPv6
address.
[no] gslb service-ip vip-name

[ipaddr]
site
(Required)
Config > Service > GSLB > Service IP

Configures a site. A GSLB zone can contain one or
more sites. Each site has at least one AX device providing load balancing for the sites services.
The site-name can be up to 31 alphanumeric characters.

Default: None
[no] gslb site site-name

Config > Service > GSLB > Site
zone
(Required)
480 of 950
See Site Parameters below.

Configures a zone. The zone identifies the top-level
URL for the services load balanced by GSLB.
[no] gslb zone zone-url
The zone-url is the URL of the zone

and can be up to 127 alphanumeric
characters.
Config > Service > GSLB > Zone
Default: None
See Zone Parameters below.
Note: You can use lower case characters and upper case characters. However, since Internet domain names are
case-insensitive, the AX device internally converts all upper case characters
in GSLB zone names to lower case.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
Active-RTT settings
(Optional)

Configures the following Active RTT options:
Supported Values
The following values are supported:
Domain Specifies the query domain. To measure the active round-trip time (RTT) for a client,
the site AX device sends queries for the domain
name to a clients local DNS. An RTT sample
consists of the time between when the site AX
device sends a query and when it receives the
response.
Domain Valid domain name (such

as example.com)
Only one active-RTT domain can be configured.

It is recommended to use a domain name that is
likely to be in the cache of each clients local
DNS.
The AX device averages multiple active-RTT
samples together to calculate the active-RTT
measurement for a client. (See the description of
Track below.)
Interval Specifies the number of seconds
between queries.
Interval 1-120 seconds

Retry 0-16
Sleep 1-300 seconds
Timeout 1-1023 milliseconds (ms)
Track 15-3600 seconds
Defaults:
Domain google.com
Interval 1
Retry 3
Sleep 3
Timeout 1000
Track 60
Retry Specifies the number of times GSLB will

resend a query if there is no response.
Sleep Specifies the number of seconds GSLB
stops tracking active-RTT data for a client after a
query fails.
Timeout Specifies the number of milliseconds
GSLB will wait for a reply before resending a
query.
Track Specifies the number of seconds during
which the AX device collects samples for a client. The samples collected during the track time
are averaged together, and the averaged value is
used as the active RTT measurement for the client.
The averaged RTT measurement is used until it
ages out. The aging time for averaged RTT measurements is 10 minutes by default and is configurable on individual sites, using the active-rtt
aging-time option.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
481 of 950

GSLB Parameters
Parameter
Handling of
DNS queries
from the local
DNS

Action to take in response to queries from the local
DNS.
(Optional)
Reject Rejects DNS queries from the local DNS

server that do not match any zone service, and
returns the Refused message in replies.
Supported Values
Default: Not set
Drop Drops DNS queries from the local DNS

server that do not match any zone service.
[no] gslb dns action {drop |

reject}
DNS logging
(Optional)
ip-list
(Optional)
Note: The current release does not support configuration of this option using the GUI.
Logging of DNS messages.
Default: Not set
[no] gslb dns logging

{both | query | response}
List of IP addresses and group IDs to use as input to
other GLSB commands.
Default: None
[no] gslb ip-list list-name
Startup delay
(Optional)
Delays startup of GSLB following startup of the AX
device.
0-16384 seconds
Default: 0 (no delay)
[no] gslb system wait seconds
GSLB protocol
timers
(Optional)
Changes timers used by the SLB protocol.
See the online help.
[no] gslb protocol limit

{
artt-query num-msgs |
artt-response num-msgs |
artt-session num-sessions |
prtt-response num-msgs |
conn-response num-msgs |
response num-msgs |
message num-msgs
}
482 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
Supported Values
Service-IP Parameters
service-ip status
Enables or disables the service-ip.
(Required)
disable | enable
Config > Service > GSLB > Service-IP
Assigns an external IP address to the service IP. The
external IP address allows a service IP that has an
internal IP address to be reached from outside the
internal network.
[no] external-ip ipaddr
Enables or disables monitoring for the service IP
address. You can specify any health monitor (Layer
3, 4 or 7).
Alternatively, you can use the follow-port option to
base the health of the service port on the health of
another port. Specify the other port number.
The protocol option enables or disables use of the
GSLB protocol for health checking of the service.
By default, the protocol option is enabled. If the
GSLB protocol is enabled and can reach the service,
health checking is performed over the GSLB protocol. Otherwise, health checking is performed using
standard network traffic instead.
[no] health-check [monitor-name] |
[follow-port portnum] [protocol]
Adds a service port to the service IP address. The
command also changes the CLI to the configuration
level for the specified service port, where the following service port-related commands are available:
port num {tcp | udp}
Maps an IPv6 address to an IPv4 service IP.
external IP
address
health check
service port
IPv6 mapping
This option also requires IPv6 DNS AAAA support

to be enabled in the GSLB policy.
Default: Enabled
Default: None
Default: The default Layer 3 health

monitor (ICMP ping) is used. The protocol option is enabled by default.
Valid protocol port number and service

type
Default: None
Valid IPv6 address

Default: None
[no] ipv6 ipv6-addr

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
483 of 950

GSLB Parameters
Parameter
Supported Values
Site Parameters
active-rtt
Configures options for the Active RTT metric.
(Optional)
[no] active-rtt
bind-geoloc |
ignore-count num |
limit num |
range-factor num |
smooth-factor num
Config > Service > GSLB > Site - Options
aging-time Specifies the maximum

amount of time a stored active-RTT
result can be used. You can specify 160 minutes. The default is 10 minutes.
bind-geoloc Stores the active-RTT
measurements on a per geo-location
basis. Without this option, the measurements are stored on a per site-SLB
device basis.
ignore-count Specifies the ignore
count if RTT is out of range. You can
specify 1-15. The default is 5.
limit Specifies the maximum RTT
allowed for the site. If the RTT measurement for a site exceeds the configured limit, GSLB does not eliminate
the site. Instead, GSLB moves to the
next metric in the policy. You can
specify 0-16383 milliseconds (ms).
The default is 16383.
mask Specifies the client IPv4 subnet
mask length, 1-32. The default is 32.
mask Specifies the client IPv4 subnet
mask length, 1-32. The default is 32.
range-factor Specifies the maximum
percentage a new active-RTT measurement can differ from the previous measurement. If the new measurement
differs from the previous measurement
by more than the allowed percentage,
the new measurement is discarded and
the previous measurement is used
again.
For example, if the range-factor is set
to 25 (the default), a new measurement
that has a value from 75% to 125% of
the previous value can be used. A measurement that is less than 75% or more
than 125% of the previous measurement can not be used.
(cont.)
484 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
active-rtt
(Optional)
(cont.)
bw-cost
Configures options for the bw-cost metric:
(Optional)
[no] bw-cost limit limit

threshold percentage
Supported Values
You can specify 1-1000. The default is
25.
smooth-factor Blends the new measurement with the previous one, to
smoothen the measurements. You can
limit Specifies the maximum amount
the SNMP object queried by the GSLB
AX device can increment since the
previous query, in order for the site to
remain eligible for selection as the best
site. You can specify 0-2147483647.
There is no default.
If a site becomes ineligible due to
being over the limit, the percentage
parameter is used. In order to become
eligible for selection again, the sites
limit value must not increment more
than limit*threshold-percentage. You can specify 0-100.
threshold percentage For a site to
regain eligibility when bw-cost is
being compared, the SNMP objects
incremental value must be below the
threshold-percentage of the limit
value.
geo-location
(Optional)
Associates the site with a specific geographic location.
For example, if the limit value is

80000 and the threshold is 90, the limit
value must increment by 72000 or less,
in order for the site to become eligible
again based on bandwidth cost. Once a
site again becomes eligible, the SNMP
objects value is again allowed to
increment by as much as the bandwidth limit value (80000, in this example).
The location-name can be up to 127
alphanumeric characters.
Default: None
Config > Service > GSLB > Site - Geo-location

Note: This option is applicable only for manually
configuring geo-location mappings. If you plan to
load geo-location mappings from a file instead, you
do not need to use this option.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
485 of 950

GSLB Parameters
Parameter
ip-server

Associates a real server with this site.
(Optional)
[no] ip-server service-name
Supported Values
Default: None
Config > Service > GSLB > Site - IP Server
passive-rtt
(Optional)
Note: Generally, virtual servers rather than real

servers are associated with a site. To associate a virtual server with a site, use the vip-server option at
the SLB device configuration level. (See SLB
device parameters.)
Configures options for the passive RTT metric. The
options are the same as those for active-rtt. (See
above.)
See the description for active-rtt,

above.
[no] passive-rtt
bind-geoloc |
limit num |
range-factor num |
smooth-factor num
slb-device
(Required)

Specifies the AX device that provides SLB for the
site.
[no] slb-dev device-name ipaddr
Config > Service > GSLB > Site - SLB Device
template
(Optional)
Binds a template to the site. To use the bw-cost metric, use this option to bind a GSLB SNMP template
to the site.
weight
[no] template template-name

Config > Service > GSLB > Site - Template
Assigns a weight to the site. If the weighted-site
metric is enabled in the policy and all metrics before
weighted-site result in a tie, the site with the highest
weight is preferred.
(Optional)
The device-name can be up to 31

alphanumeric characters. The IP
address must be an address that can be
reached by the GSLB AX device.
Default: None
Name of configured SNMP template.
Default: None
The weight can be from 1 100.

Default: 1
[no] weight num

Config > Service > GSLB > Site - General
486 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
Supported Values
SLB Device Parameters

admin-preference
(Optional)
Assigns a preference value to the SLB device. If the

admin-preference metric is enabled in the policy
and all metrics before this one result in a tie, the
SLB device with the highest admin-preference
value is preferred.
You can specify from 0 255.

Default: 100
[no] admin-preference num

gateway
(Optional)
gateway health
check
(Optional)
max-client
(Optional)
passive-rtt-timer
(Optional)
vip-server
(Required)
Config > Service > GSLB > Site - SLB-Device

Specifies the gateway that the SLB device will use
to reach the GLSB local DNS for collecting active
RTT measurements.
[no] gateway ipaddr
Allows GSLB to use a Layer 3 health monitor to
check the health of the SLB devices gateway.
[no] gateway health-check
Specifies the maximum number of clients for which
the GSLB AX device (controller) saves data such as
active and passive RTT measurements.
[no] max-client number
For passive RTT, specifies the number of seconds
during which samples are collected during each
sampling period. You can specify 1-255. The
default is 3.
[no] passive-rtt-timer num
To prevent samples from being taken for this
device, use the no passive-rtt-timer command.
Maps this SLB site to a globally configured GSLB
service IP address (configured by the service-ip
option).
Valid IP address.
Default: Not set
Enabled or disabled
Default: enabled
1-2147483647
Default: 32768
1-255
Default: 3
[no] vip-server name
The name must be the name of a configured service IP. (To configure the
service IP, use the gslb service-ip
command.)
Default: None
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
487 of 950

GSLB Parameters
Parameter
Supported Values
Zone Parameters
dns-mx-record
(Optional)
Configures a DNS Mail Exchange (MX) record for

the zone. The name is the fully-qualified domain
name of the mail server for the zone.
If more than MX record is configured for the same
zone, the priority specifies the order in which the
mail server should attempt to deliver mail to the MX
hosts. The MX with the lowest preference value has
the highest priority and is tried first. The priority
can be 0-65535. There is no default.
dns-ns-record
(Optional)
488 of 950
MX records configured on a zone are used only for

services on which MX records are not configured.
[no] dns-mx-record name
priority
Config > Service > GSLB > Zone - Click Add on
the Service section to display the DNS MX Record
section.
Configures a DNS name server record for the zone.
[no] dns-ns-record domain-name
the Service section to display the DNS NS Record
section.
The name is the fully-qualified domain

name of the mail server for the zone.
The priority can be 0-65535. There is
no default preference.
Default: None
Fully-qualified domain name.

Default: None
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
dns-soa-record
(Optional)

Configures a DNS start of authority (SOA) record
for the GSLB zone. You must specify the DNS
server name and mailbox name. The following
parameters are optional:
Refresh Specifies the number of seconds other
DNS servers wait before requesting updated information for the GSLB zone.
Retry Specifies how many seconds other DNS
servers wait before resending a refresh request, if
GSLB does not respond to the previous request.
Expire Specifies how many seconds GSLB can
remain unresponsive to a refresh request before the
other DNS server drops responding to queries for
the zone.
Serial Specifies the initial serial number of the
SOA record. This number is automatically incremented each time a change occurs to any records for
the GSLB zone.
Supported Values
Valid DNS server name and mailbox
name.
Defaults: No SOA record is configured
by default. If you configure one, its
parameters have the following default
values:
Refresh 3600 seconds
Retry 900 seconds
Expire 1209600 seconds
Serial The default is based on the
current system time on the GSLB AX
device when you create the SOA
record.
TTL Value of the zone TTL when
you create the SOA record
TTL Specifies the number of seconds GSLB will

cache and reuse negative replies (NXDOMAIN
messages). A negative reply is an error message
indicating that a requested domain does not exist.
[no] dns-soa-record dns-servername mailbox-name
[expire seconds]
[refresh seconds]
[retry seconds] [serial num]
[ttl seconds]
policy
Applies a GSLB policy to the zone.
(Optional)
[no] policy policy-name

See Policy Parameters on page 494.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
The policy-name can be up to 31

Default: The default GSLB policy is
used, unless you configure another
policy and apply it to the zone.
489 of 950

GSLB Parameters
Parameter
service
(Required)

Adds a service to the zone. The GSLB AX Series
verifies the availability of the service by sending a
health check to the specified service port.
[no] service port service-name
Config > Service > GSLB > Zone - Service tab
The health check must be assigned to the individual
service. See Service Parameters below.
ttl
(Optional)
Changes the TTL of each DNS record contained in

DNS replies received from the DNS for which the
AX Series is a proxy, for this zone.
Supported Values
The port can be a well-known name
recognized by the CLI, a port number
from 1 to 65535, or * (wildcard matching on any port).
The service-name can be up to 31
alphanumeric characters. (For the
same reason described for zone names,
the AX device converts all upper case
characters in GSLB service names to
lower case.)
Default: None
You can specify from 0 to 1000000
(1,000,000) seconds.
Default: 10 seconds
TTL can be set at different levels of the GSLB configuration; however, only one of the TTL settings is
used. (See DNS Options on page 435.)
ttl seconds [no]
The health check must be assigned to the individual
service. See Service Parameters below.
Service Parameters
action
Specifies the action to perform for DNS traffic.
You can specify one of the following:
(Optional)
Note: Use of the actions configured for services

also must be enabled in the GSLB policy, using the
DNS action option. See Table 13, GSLB Policy
Parameters, on page 494.
Drop Drops DNS queries from the

local DNS server.
[no] action {drop | reject |

forward {both | query | response}}
Config > Service > GSLB > Zone - Click Add in the
Service section.
490 of 950
Reject Rejects DNS queries from

the local DNS server and returns the
Refused message in replies.
Forward Forwards requests or
queries, as follows:
Forward both Forwards queries
to the Authoritative DNS server,
and forwards responses to the
local DNS server.
Forward query Forwards queries to the Authoritative DNS
server, but does not forward
responses to the local DNS
server.
Forward response Forwards
responses to the local DNS
server, but does not forward queries to the Authoritative DNS
server.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
dns-a-record
(Optional)

Configures a DNS Address (A) record for the service, for use with the DNS replace-ip option in the
GSLB policy.
dns-a-record
{service-name | service-ipaddr}
{as-replace | no-resp | static |
ttl num | weight num}
Service section to display the DNS Address Record
section.
Note: The no-resp option is not valid with the static
or as-replace option. If you use no-resp, you cannot
use static or as-replace.
Supported Values
as-replace This option is used with
the ip-replace option in the policy.
When both options are set (as-replace
here and ip-replace in the policy), the
client receives only the IP address set
here by service-ip. This option is disabled by default.
no-resp Prevents the IP address for
this site from being included in DNS
replies to clients. This option is disabled by default.
static This option is used with the
dns server option in the policy. When
both options are set (static here and
dns server in the policy), the GSLB
AX device acts as the DNS server for
the IP address set here by service-ip.
This option is disabled by default.
ttl Assigns a TTL to the service, 02147483647. By default, the TTL of
the zone is used. This option can be
used with the dns server option in the
policy, or with DNS proxy mode
enabled in the policy.
weight Assigns a weight to the service. If the weighted-ip metric is
enabled in the policy and all metrics
before weighted-ip result in a tie, the
service on the site with the highest
weight is selected. The weight can be
1-100. By default, the weight is not
set.
dns-cnamerecord
(Optional)
Configures DNS Canonical Name (CNAME)

records for the service.
The as-backup option specifies that the record is a
backup record.
dns-cname-record alias [as-backup]
[alias ...]
Service section to display the DNS CName Record
section.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Default: None
Default: None
491 of 950

GSLB Parameters
Parameter
dns-mx-record
(Optional)

Configures a DNS Mail Exchange (MX) record for
the service.
If more than MX record is configured for the same
service, the priority specifies the order in which the
mail server should attempt to deliver mail to the MX
hosts. The MX record with the lowest priority number has the highest priority and is tried first.
dns-mx-record name priority
the Service tab to display the DNS MX Record tab.
(Optional)
Note: If you want the GSLB AX device to return

the IP address of the mail service in response to MX
requests, you must configure A records for the mail
service.
Configures a DNS name server record for the service.
dns-ptr-record
dns-ns-record domain-name
[as-backup]
the Service tab to display the DNS NS Record tab.
Configures a DNS pointer record for the service.
dns-ns-record
(Optional)
gateway health
check
(Optional)
geo-location
(Optional)
dns-ptr-record domain-name
the Service tab to display the DNS PTR Record tab.
Allows GSLB to use a Layer 3 health monitor to
check the health of the service by sending health
checks to the site gateway.
[no] health-check gateway
Maps an alias to the specified geographic location
for this service.
alias url
Service section to display the Geo-location section.
This CNAME overrides any CNAME globally configured for the zone.
492 of 950
Supported Values
The name is the fully-qualified domain
name of the mail server for the service.
The priority can be 0-65535. There is
no default.
Fully-qualified domain name

Not set
Fully-qualified domain name

Not set
Enabled or disabled
Default: enabled
The location-name is a global GSLB

parameter and must already be configured. (See Global GSLB parameters
and Site parameters above.)
The alias is a service parameter and
must already be configured. (See
above.)
Default: None
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
ip-order
(Optional)

Specifies the order in which to list the service IP
addresses (VIPs) for this service in the DNS replies
to clients.
Supported Values
Each service-ipaddr is a virtual IP
address assigned to the service at this
site.
The ip-order is one of the metrics used to select the

best IP address for a service.
Generally, each service will have a different virtual IP address for each real
server that provides the service at the
site.
[no] ip-order
{service-name | service-ipaddr}
[service-ipaddr ...]
policy
Service section to display the DNS Address Record
section.
Applies the specified GSLB policy to the service.
(Optional)
[no] policy policy-name
The policy-name can be up to 31

Service section to display the Service section.
You must configure the policy before

you apply it.
Default: The GSLB policy applied to
the zone is also applied to the services
in that zone. If no policy is applied to
the zone, the default GSLB policy is
applied.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
493 of 950

GSLB Parameters
Policy Parameters
Table 13 lists the GSLB policy parameters.
TABLE 13 GSLB Policy Parameters
Parameter
Supported Values
active-rtt
Load balancing metric that selects the site with the

fastest round-trip-time for a DNS query and reply
between a site AX device and the GSLB local DNS.
Load Balancing Metrics
The active RTT metric is disabled by default. You

can enable it to take either a single sample (single
shot) or multiple samples at regular intervals.
[no] active-rtt
[difference num]
[fail-break]
[ignore-id num]
[keep-tracking]
[limit ms]
[single-shot] [skip count]
[timeout seconds]
Config > Service > GSLB > Policy - Metrics
active-servers
admin-preference
494 of 950
Note: This metric requires the GSLB protocol to be

enabled on the site AX devices. (See Metrics That
Require the GSLB Protocol on Site AX Devices on
page 437.)
Load balancing metric that selects the site that has
the most active servers for the requested service.
The state is one of the following:

Enabled
Disabled This is the default.
When you enable the active-rtt metric,
the default number of samples is 5.
The default store-by is slb-device. The
default tolerance is 10 percent.

Enabled
The fail-break option enables GSLB to stop if the

number of active servers for all services is 0.
[no] active-servers [fail-break]
Load balancing metric that selects the service with
the highest administratively set preference.
[no] admin-preference

Enabled
The preference can be from 0 to 255.
The default is 100 for each site.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
TABLE 13 GSLB Policy Parameters (Continued)
Parameter
alias-admin-preference
bw-cost
capacity

Load balancing metric that selects the DNS
CNAME record with the highest administratively
set preference. This metric is similar to the Admin
Preference metric, but applies only to DNS
CNAME records.
[no] alias-admin-preference
Note: The current release does not support configuration of this metric in the GUI.
Load balancing metric that selects sites based on
bandwidth utilization on the site AX links.
current bw-cost value is over the limit.
[no] bw-cost [fail-break]
Sites that have not exceeded their thresholds for
their respective maximum TCP/UDP sessions are
preferred over sites that have exceeded their thresholds.
Example:
Supported Values
Enabled

Enabled

Enabled
The threshold can be from 0 to 100
percent. The default is 90.
Site As maximum session capacity is 800,000 and

Site Bs maximum session capacity is 500,000. If
the session-capacity threshold is set to 90, then for
Site A the capacity threshold is 90% of 800,000,
which is 720,000. Likewise, the capacity threshold
for Site B is 90% of 500,000, which is 450,000.
session utilization on all site SLB devices is over the
threshold.
[no] capacity [threshold num]
[fail-break]
page 437.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
495 of 950

GSLB Parameters
Parameter
connection-load

Sites that are at or below their thresholds of average
new connections per second are preferred over sites
that are above their thresholds.
connection load for all sites is over the limit.
[no] connection-load
[limit average-load] |
[samples num interval seconds]
[fail-break]
geographic

page 437.)
Service IP addresses for the geographic region
where the client is located are preferred over
addresses from other regions.
Supported Values
Enabled
The limit can be from 1 to 999999999
(999,999,999). The default is not set
(unlimited).
The samples can be from 1 to 8. The
default is 5.
The interval can be from 1 to 60 seconds. The default is 5 seconds.

Enabled This is the default.
Disabled
The GSLB AX Series selects the geographic region

by matching the clients IP address with the GSLB
address ranges configured using geo-location
options.
health-check
[no] geographic
Service IP addresses that pass their health checks
are preferred over addresses that do not pass their
health checks.

Disabled
An IP address that fails its health check is not automatically ineligible to be included in the DNS reply
to a client.
[no] health-check
enabled on the site AX devices, if the default health
checks are used on the service IPs. (See Health
Checks on page 432.)
496 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
least-response
num-session

Service IP addresses with the fewest hits are preferred over addresses with more hits.
Supported Values
[no] least-response

page 437.)
Sites that are at or below their thresholds of current
available sessions are preferred over sites that are
above their thresholds.
The tolerance specifies the percentage by which the
number of available sessions on site SLB devices
can differ without causing the num-session metric to
select one SLB device over another. Thus, minor
differences among SLB devices do not cause frequent, unnecessary changes in site preference.
Enabled

Enabled
When you enable the num-session
metric, the default tolerance is 10 percent.
Example:
Site A has 800,000 sessions available and Site B has
600,000 sessions available. The difference between
the two sites is 200,000 available sessions. If numsession is set to 10, then Site A is preferred because
200,000 is larger than 10% of 800,000, which is
80,000.
[no] num-session [tolerance num]
ordered-ip

page 437.)
Service IP addresses are re-ordered in DNS replies
to match the order administratively configured for
the service.

Enabled
The prioritized list is sent to the next metric for further evaluation. If ordered-ip is the last metric, the
prioritized list is sent to the client.
The ordered list of IP addresses must be configured
for the service.
To send only the first (top) IP address in the IP list,
use the top-only option.
[no] ordered-ip [top-only]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
497 of 950

GSLB Parameters
Parameter
passive-rtt

Sites with faster round-trip times (RTTs) between a
client and the site are preferred over sites with
slower times. The passive RTT is the time between
when the site AX device receives a clients TCP
connection (SYN) and the time when the site AX
device receives acknowledgement (ACK) back
from the client for the connection. Passive RTT
measurements are taken for client addresses in each
/24 subnet range.
Supported Values
Enabled
When you enable the passive-rtt metric, the default number of samples is 5.
The default store-by is slb-device. The
default tolerance is 10 percent.
Passive RTT tolerance is a percentage from 0 to

100. It specifies how much the RTT values of sites
must differ in order for GSLB to prefer one site over
the other based on RTT.
Example:
Site As RTT value is 0.3 seconds and Site Bs RTT
value is 0.32 seconds. If the passive RTT tolerance
is 10% then the two sites are treated as having the
same passive RTT preference.
configured RTT limit in a policy is reached.
[no] passive-rtt
[difference num]
[fail-break]
round-robin

page 437.)
Each service IP address is used sequentially, in rotation. The first service IP address is selected for the
first new connection, the second address is selected
for the second new connection, and so on until all
service IP addresses have been selected. Then selection starts over again with the first service IP
address.

Disabled
[no] round-robin
498 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
weighted-alias
weighted-ip

Load balancing metric that prefers CNAME records
with higher weight values over CNAME records
with lower weight values. This metric is similar to
weighted-ip, but applies only to DNS CNAME
records.
[no] weighted-alias
Note: The current release does not support configuration of this metric in the GUI.
Service IP addresses with higher weight values are
used more often than addresses with lower weight
values.
Supported Values
Enabled

Enabled
As a simple example, assume that the weighted-ip

metric is the only enabled metric, or at least always
ends up being the tie breaker. IP address 10.10.10.1
has weight 4 and IP address 10.10.10.2 has weight
2. During a given session aging period, the first 4
requests go to 10.10.10.1, the next 2 requests go to
10.10.10.2, and so on, (4 to 10.10.10.1, then 2 to
10.10.10.2).
The total-hits option first sends requests to the service IP addresses that have fewer hits. After all service IP addresses have the same number of hits,
GSLB sends requests based on weight. This option
is disabled by default.
weighted-site
[no] weighted-ip [total-hits]

Sites with higher weight values are used more often
than sites with lower weight values.
As a simple example, assume that the weighted-site
metric is the only enabled metric, or at least always
ends up being the tie breaker. Site A has weight 4
and site B has weight 2. During a given session
aging period, the first 4 requests go to site A, the
next 2 requests go to site B, and so on, (4 to A, then
2 to B).

Enabled
The total-hits option first sends requests to the sites

that have fewer hits. After all service sites have the
same number of hits, GSLB sends requests based on
weight. This option is disabled by default.
[no] weighted-site [total-hits]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
499 of 950

GSLB Parameters
Parameter
metric-order

Assigns a geographic location to an IP address
range. GSLB forwards client requests from
addresses within the range to the GSLB site that
serves the location.
[no] metric-order metric
[metric ...]
Supported Values
You can specify one or more of the following metrics (listed alphabetically):
active-rtt
active-servers
admin-preference
bw-cost
capacity
The first metric you specify becomes the primary

metric. If you specify additional parameters, they
are used in the priority you specify. All remaining
metrics are prioritized to follow the metrics you
specify.
For example, if you specify only the ordered-ip metric with the command, and the metric order in the
policy has not been changed previously, the
ordered-ip metric becomes the first metric. The
health-check metric becomes the second metric, the
weighted-ip metric becomes the third metric, and so
on.
metric-forcecheck
metric-fail-break
Forces the GSLB controller to always check all metrics in the policy.
[no] metric-force-check
Config > Service > GSLB > Policy
Enables GSLB to stop if there are no valid service
IPs.
[no] metric-fail-break
Note: In the current release, this option can not be
configured using the GUI.
connection-load
geographic
health-check
least-response
num-session
ordered-ip
passive-rtt
weighted-ip
weighted-site
Default metric order: See GSLB Policy on page 430.
Enabled
Enabled
DNS Parameters
action
500 of 950
Enable GSLB to perform the DNS actions specified

in the service configurations.
[no] dns action
Config > Service > GSLB > Policy - DNS Options
Note: To configure the DNS action for a service,
use the action option at the configuration level
for the service. See Table 12, GSLB Parameters,
on page 479.

Enabled
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
active-only
addition-mx
backup-alias
best-only
cache
cname-detect

Removes IP addresses from DNS replies when
those addresses fail a health check.
Supported Values
Note: If none of the IP addresses in the DNS reply

pass the health check, the GSLB AX Series does not
use this metric, since it would result in an empty IP
address list.
[no] dns active-only

Appends MX records in the Additional section in
replies for A records, when the device is configured
for DNS proxy or cache mode.
[no] dns addition-mx
Returns the alias CNAME record configured for the
service, if GSLB does not receive an answer to a
query for the service and no active DNS server
exists.
[no] dns backup-alias
Removes all IP addresses from DNS replies except
for the address selected as the best address by the
GSLB policy metrics.
Enabled

Enabled

Enabled

Enabled
[no] dns best-only [max-answers]

Caches DNS replies and uses them when replying to
clients, instead of sending a new DNS request for
every client query.
[no] dns cache

[aging-time seconds | ttl]
The aging time can be

1-1,000,000,000 seconds (nearly 32
years).
For more information on this option, see Order in

Which Sticky, Server, Cache, and Proxy Options
Are Used on page 436.
Default: TTL set by the DNS server in

the reply
Applies GSLB to CNAME records.

[no] dns cname-detect
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Enabled
Note: If you change the value and later

want to restore it to the default, use the
ttl option.
Disabled
501 of 950

GSLB Parameters
Parameter
external-ip

Returns the external IP address configured for a service IP. If this option is disabled, the internal
address is returned instead.
Supported Values
Disabled
[no] dns external-ip

geoloc-action
Note: The external IP address must be configured

on the service IP. Use the external-ip option at the
configuration level for the service IP. See Table 12,
GSLB Parameters, on page 479.
Performs the DNS traffic handling action specified
for the clients geo-location. The action is specified
as part of service configuration in a zone.

Enabled
[no] dns geoloc-action

geoloc-alias
geoloc-policy
ip-replace
Note: To configure the DNS action for a service,

use the geo-location action option at the configuration level for the service. See Table 12, GSLB
Parameters, on page 479.
Returns the alias name configured for the clients
geo-location.
[no] dns geoloc-alias
Uses the GSLB policy assigned to the clients geolocation.
[no] dns geoloc-policy
Replaces the IP addresses in the DNS reply with the
service IP addresses configured for the service.
[no] dns ip-replace
502 of 950

Enabled
Enabled
Enabled
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
ipv6

Enables support for IPv6 AAAA records.
You can configure the following options:
Supported Values
All options are disabled by default.
Mapping Specifies the actions in response to an

IPv6 DNS query. You can enable one or more of
these options.
Addition Append AAAA records in the DNS
Addition section of replies.
Answer Append AAAA records in the DNS
Answer section of replies.
Exclusive Replace A records (IPv4 address
records) with AAAA records.
Replace Reply with AAAA records only.
Mix Enables GSLB to return both AAAA and A
records in the same answer.
Smart Enables IPv6 return by query type. For the
ipv4-ipv6 mapping records, an A query (IPv4) will
return an A record and an AAAA query (IPv6) will
return an AAAA record.
Note: The current release has the following limitations:
Health checks and the GSLB protocol use IPv4
only.
IP address-related metrics such as RTT are
always based on IPv4.
Virtual servers for GSLB service IPs are required
to have both an IPv4 and an IPv6 address.
logging
[no] dns ipv6 options

Note: The current release does not support configuration of these options using the GUI.
Configures DNS logging.
Disabled by default
[no] dns logging {both | query |

response} [geo-location name | ip
ipaddr]
Note: The current release does not support configuration of these options using the GUI.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
503 of 950

GSLB Parameters
Parameter
server

Directly responds to Address queries for specific
service IP addresses in the GSLB zone. (The AX
device still forwards other types of queries to the
DNS server.)
If you use this option, you do not need to use the
cname-detect option. When a client requests a configured alias name, GSLB applies the policy to the
CNAME records.
addition-mx enables the GSLB AX device to
provide the A record containing the mail servers
IP address in the Additional section, when the
device is configured for DNS server mode.
Supported Values
Enabled
Other defaults:
addition-mx Disabled
authoritative The AX device is a
non-authoritative DNS server for
the zone domain.
mx Disabled
authoritative makes the AX device the authoritative DNS server for the GSLB zone domain, for
the service IPs in which you enable the static
option. If you omit the authoritative option, the
AX device is a non-authoritative DNS server for
the zone domain. The full-list option appends all
A records in the Authoritative section of DNS
replies.
mx Provides the MX record in the Answer section, and the A record for the mail server in the
Additional section, when the device is configured
for DNS server mode.
ns [auto-ns] Provides the NS record.
ptr [auto-ptr] Provides the pointer record.
To place the server option into effect, you also must
enable the static option on the individual service IP.
[no] dns server addition-mx
[no] dns server authoritative
[full-list]
[no] dns server mx
[no] dns server ns [auto-ns]
[no] dns server ptr [auto-ptr]
504 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

GSLB Parameters
Parameter
sticky

Sends the same service IP address to a client for all
requests from that client for the service address.
[no] dns sticky [/prefix-length]
[aging-time minutes]
[ipv6-mask mask-length]
The /prefix-length and ipv6-mask options adjust the
granularity of the feature.
The aging-time option specifies how many minutes
a DNS reply remains sticky. You can specify 165535 minutes.
Note: If you enable the sticky option, the sticky
time must be as long or longer than the zone TTL.
(Use the ttl command at the configuration level for
the zone.)
ttl

Specifies the value to which the AX Series changes
the TTL of each DNS record contained in DNS
replies received from the DNS for which the
AX Series is a proxy.
Supported Values
Enabled
The default prefix is /32, which causes
the AX device to maintain separate
stickiness information for each local
DNS server. For example, if two clients use DNS 10.10.10.25 as their
local DNS server, and two other clients
use DNS 10.20.20.99 as their local
DNS server, the AX maintains separate stickiness information for each set
of clients, by maintaining separate
stickiness information for each of the
local DNS servers.
The aging time can be 1-65535 minutes. Default: 5 minutes
You can specify from 0 to 1000000
(1,000,000) seconds.
Default: 10 seconds
[no] dns ttl num

Geo-location Parameters
geo-location
Assigns a geographic location to an IP address

range. GSLB forwards client requests from
addresses within the range to the GSLB site that
serves the location. This is an alternative to loading
a geo-location database.
start-ip-addr [mask ip-mask]
[end-ip-addr]
[no] geo-location match-first
{global | policy}
The match-first parameter specifies whether to
match the requested IP address with the global geolocation table or with the geo-location table configured in the policy.
The location-name can be up to 127

Default location: None
Default match-first: global
Default overlap: disabled
[no] geo-location overlap

The geo-location mapping and overlap cannot be
configured using the GUI. To configure the matchfirst parameter, select Config > Service > GSLB >
Policy - Geo-location
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
505 of 950

These examples implement the GSLB configuration shown in Figure 130
on page 428. The examples assume that the default GSLB policy is used,
without any changes to the policy settings.
CLI Example
Configuration on the GSLB AX Device (GSLB Controller)
The following commands configure a health monitor for the local DNS
server to be proxied:
AX-Controller(config)#health monitor dns-53
AX-Controller(config-health:monitor)#method dns domain example.com
AX-Controller(config-real server)#exit
The following commands configure the DNS proxy:

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

address and virtual port number of the virtual server in the site AX Series
devices SLB configuration are used as the service IP address and port number on the GSLB AX Series device.
AX-Controller(config)#gslb service-ip servicevip1 2.1.1.10
AX-Controller(config-gslb service ip)#port 80 tcp
AX-Controller(config-gslb service ip)#exit
AX-Controller(config)#gslb service-ip servicevip2 3.1.1.10
AX-Controller(config-gslb service ip)#port 80 tcp
AX-Controller(config-gslb service ip)#exit
The following command loads the IANA file into the geo-location database:
AX-Controller(config)#gslb geo-location load iana
506 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following commands configure the sites. For each site SLB device,
enter the IP address of the AX Series device that provides SLB at the site.
For the VIP server names, enter the service IP name specified above.
AX-Controller(config)#gslb site usa
AX-Controller(config-gslb site)#slb-dev ax-a 2.1.1.1
AX-Controller(config-gslb site-slb dev)#vip-server servicevip1
AX-Controller(config-gslb site-slb dev)#exit
AX-Controller(config-gslb site)#exit
AX-Controller(config)#gslb site asia
AX-Controller(config-gslb site)#slb-dev ax-b 3.1.1.1
AX-Controller(config-gslb site-slb dev)#vip-server servicevip2
AX-Controller(config-gslb site-slb dev)#exit
AX-Controller(config-gslb site)#exit
The following commands configure the GSLB zone:

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

www.a10.co.cn is configured, and the CNAME is associated with geo-location China. If a clients IP address is in the range for the China geo-location,
GSLB sends the CNAME www.a10.co.cn in the DNS reply.
The following command enables the GSLB protocol:
AX-Controller(config)#gslb protocol enable controller
Configuration on Site AX Device AX-A

The following commands configure SLB on site AX device AX-A in
Figure 130 on page 428:
Site-AX-A(config)#slb server www 2.1.1.2
Site-AX-A(config-real server)#port 80 tcp
Site-AX-A(config-real server-node port)#exit
Site-AX-A(config-real server)#exit
Site-AX-A(config)#slb server www2 2.1.1.3
Site-AX-A(config-real server)#port 80 tcp
Site-AX-A(config-real server-node port)#exit
Site-AX-A(config-real server)#exit
Site-AX-A(config)#slb service-group www tcp
Site-AX-A(config-slb service group)#member www:80
Site-AX-A(config-slb service group)#member www2:80
Site-AX-A(config-slb service group)#exit
Site-AX-A(config)#slb virtual-server www 2.1.1.10
Site-AX-A(config-slb virtual server)#port 80 http
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
507 of 950

Site-AX-A(config-slb virtual server-slb virtua...)#service-group www
Site-AX-A(config-slb virtual server-slb virtua...)#exit
Site-AX-A(config-slb virtual server)#exit
Note:
The virtual server IP address must be the same as the GSLB service IP
address configured on the GSLB AX device.
The following command enables the GSLB protocol:
Site-AX-A(config)#gslb protocol enable device
Configuration on Site AX Device AX-B

The following commands configure SLB and enable the GSLB protocol on
site AX device AX-B:
Site-AX-B(config)#slb server www 3.1.1.2
Site-AX-B(config-real server)#port 80 tcp
Site-AX-B(config-real server-node port)#exit
Site-AX-B(config-real server)#exit
Site-AX-B(config)#slb server www2 3.1.1.3
Site-AX-B(config-real server)#port 80 tcp
Site-AX-B(config-real server-node port)#exit
Site-AX-B(config-real server)#exit
Site-AX-B(config)#slb service-group www tcp
Site-AX-B(config-slb service group)#member www:80
Site-AX-B(config-slb service group)#member www2:80
Site-AX-B(config-slb service group)#exit
Site-AX-B(config)#slb virtual-server www 3.1.1.10
Site-AX-B(config-slb virtual server)#port 80 http
Site-AX-B(config-slb virtual server-slb virtua...)#service-group www
Site-AX-B(config-slb virtual server-slb virtua...)#exit
Site-AX-B(config-slb virtual server)#exit
Site-AX-B(config)#gslb protocol enable device
GUI Example
Configuration on the GSLB AX Device (GSLB Controller)
Configure a Health Monitor for the DNS Proxy
2. On the menu bar, select Health Monitor.
3. Click Add.
4. Enter a name for the monitor in the Name field.
508 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

5. In the Method section, select DNS from the Type drop-down list.
6. In the Domain field, enter the domain name. (Generally, this is the same
as the GSLB zone name you will configure.)
Configure the DNS Proxy
1. Begin configuring the proxy:
a. Select Config > Service > GSLB.
b. On the menu bar, select DNS Proxy.
c. Click Add.
d. Enter a name for the proxy in the Name field.
e. In the IP Address field, enter the IP address that will be advertised
as the authoritative DNS server for GSLB zone.
The GUI will not accept the configuration if the IP address you enter here
is the same as the real DNS server IP address you enter when configuring
the service group for this proxy. (below).
Note:
f. In the GSLB Port section, click Add. The GSLB Port section
appears.
2. Configure the service group:
a. In the Service Group drop-down list, select create to create a service group. (See Figure 132 on page 510.)
The Service Group section appears.
b. Enter the service group information. For this example, enter the following:
Name gslb-proxy-sg-1
Port type UDP
Load-balancing metric (algorithm) Round-Robin
Health Monitor default
c. In the Server section, enter the DNS servers real IP address in the
Server field, and enter the DNS port number in the port field.
d. Click Add. The DNS port appears in the list. (See Figure 133 on
page 510.)
e. Click OK. The GSLB Port section reappears. In the service dropdown list, the service group you just configured is selected. (See
Figure 134 on page 511.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
509 of 950

3. Finish configuration of the proxy:
a. Click OK. The Proxy section reappears. (See Figure 135 on
page 511.)
b. Click OK. The DNS proxy appears in the DNS Proxy table. (See
Figure 136 on page 511.)
FIGURE 132
Configure > Service > GSLB > DNS Proxy
FIGURE 133 Configure > Service > GSLB > DNS Proxy - service group
configuration
510 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 134
selected
Configure > Service > GSLB > DNS Proxy - service group
FIGURE 135
configured
Configure > Service > GSLB > DNS Proxy - GSLB port
FIGURE 136
configured
Configure > Service > GSLB > DNS Proxy - DNS proxy
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
511 of 950

Load the IANA Geo-location Database
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.
Configure Services
2. On the menu bar, select Service IP.
3. Click Add.
4. Enter the service name and IP address. For this example, enter the following:
Name servicevip1
IP Address 2.1.1.10 (This is the VIP address of a site. Configure a
separate GSLB service IP for each SLB VIP.)

5. If needed, assign an external IP address to the service IP. The external IP
address allows a service IP that has an internal IP address to be reached
from outside the internal network.
6. Add the service port(s):
a. Enter the port number and select the protocol (TCP or UDP).
b. Optionally, select a health monitor.
c. Click Add. The service port appears in the service port list.
For this example, add TCP port 80 and leave the health monitor
unselected.
(See Figure 137 on page 513.)
7. Click OK.
8. Repeat for each service IP.
512 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 137
Config > Service > GSLB > Service IP
Configure Sites
2. On the menu bar, select Site.
3. Click Add.
4. Enter the site name.
5. In the SLB-Device section, enter information about the AX devices that
provide SLB for the site:
a. Click Add.
b. Enter a name for the device.
c. Enter the IP address at which the GSLB AX device will be able to
reach the site AX device.
d. To add a service to this SLB device, select it from the drop-down list
in the VIP server section and click Add. Repeat for each service.
For this example, enter the following:
Name AX-A
IP Address 2.1.1.1 (This is the IP address of the site AX device
that provides SLB for the site.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
513 of 950

GSLB Service Add a service IP by selecting it from the drop-
down list and clicking Add. For this example, add servicevip1
to site usa.
6. In the IP-Server section, add services to the site. Select a service from
the drop-down list and click Add. Repeat for each service.
7. To manually map a geo-location name to the site, enter the geo-location
name in the Geo-location section and click Add.
8. Click OK. The site appears in the Site table.
FIGURE 138
514 of 950
Configure > Service > GSLB > Site - SLB Device
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 139
Configure > Service > GSLB > Site - site parameters selected
Configure a Zone
2. On the menu bar, select Zone.
3. Click Add.
4. Enter the zone name in the Name field.
5. In the Service section, click Add. (See Figure 140 on page 516.)
The service configuration sections appear.
6. In the Service field, enter the service name.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
515 of 950

7. Select the service type from the Port drop-down list.
8. Add the services:
a.
b.
c.
d.
In the Service section, click Add.

Enter name for the service (for example, www).
Select the service type from the Port drop-down list.
Configure additional options, if applicable to your deployment. (See
Table 12, GSLB Parameters, on page 479.)
e. Click OK.
f. Repeat for each service.
9. Click OK. The zone appears in the GSLB zone list.
FIGURE 140
516 of 950
Configure > Service > GSLB > Zone
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 141
Configure > Service > GSLB > Zone
Enable the GSLB Protocol

3. Select Enabled next to Run GSLB as Controller.
4. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
517 of 950

Configuration on Site AX Devices

SLB configuration is the same with or without GSLB, and is not described
here.
To enable the AX device to run GSLB as a site AX device, perform the following steps on each site AX device:
3. Select Enabled next to Run GSLB as Site SLB Device.
4. Click OK.
518 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
RAM Caching
You can use the AX device as a transparent cache server, along with the
devices 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 application 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 compression 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 sections 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
519 of 950

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. Thee
headers can make the AX device vulnerable to Denial of Service (DoS)
attacks.
To enforce strict RFC compliance, you can enable support for the headers.
520 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
521 of 950

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 configurations 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
522 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring RAM Caching
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.

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 template 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.
4. Enter a name for the template, if you are creating a new one.
5. Enter or change any settings for which you do not want to use the
default settings.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
523 of 950

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 specified 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.
To Export Web Log Archives
1. Select Monitor > Service > Application.
2. On the menu bar, select RAM Caching > Logs.
The list of log archive files appears.
524 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

3. Click on the checkbox next to the filename of each log file you want to
export.
4. Click Export.
To delete log archive files, click the checkbox next to each file you want to
delete, and click Delete.
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
Enter this command at the global configuration level of the CLI. The command changes the CLI to the configuration level for the template, where the
following commands specific to RAM caching are available:
[no] accept-reload-req
This command enables support for the following Cache-Control headers:
When support for these headers is enabled, either header causes the AX
device to reload the cached object from the origin server.
[no] age seconds
This command specifies how long a cached object can remain in the AX
RAM cache without being requested. You can specify 1-999999 seconds
(about 11-1/2 days). The default is 3600 seconds (1 hour).
[no] default-policy-nocache
This command changes the default cache policy in the template from cache
to nocache. This option gives you tighter control over content caching.
When you use the default no-cache policy, the only content that is cached is
cacheable content whose URI matches an explicit cache policy.
[no] max-cache-size MB
This command specifies the size of the AX RAM cache.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
525 of 950

On models AX 1000, AX 2000, AX 2100, AX 2200, AX 3100, and
AX 3200, you can specify 1-512 MB.

On model AX 2500, you can specify 1-1024 MB.
On models AX 2600 and AX 3000, you can specify 1-2048 MB.
On models AX 5100 and AX 5200, you can specify 1-4096 MB.
The default is 80 MB.

[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
0-4194303 bytes (4 MB). If you specify 0, no objects can be cached. The
default is 81920 bytes (80 KB).
[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] 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-4194303 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] 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 Persistence Configurations on page 522.)
[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.
526 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Dynamic Caching Command
Dynamic caching is performed using caching policies. To configure a caching 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:
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.
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.
Note:
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:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
527 of 950

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.
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
528 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

Reverse Source and Reverse Dest fields indicate that the AX device directly
served the requested content to the client from the AX RAM cache. In this
case, the session is actually between the client and the AX device rather
than the real server.
AX(config-slb virtual server-slb virtua...)#show session
Traffic Type
Total
-------------------------------------------TCP Established
4328
TCP Half Open
39026
UDP
0
Non TCP/UDP IP sessions
0
Other
0
Reverse NAT TCP
0
Reverse NAT UDP
0
Free Buff Count
0
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
529 of 950

The following command shows RAM caching statistics.
AX(config-slb virtual server-slb virtua...)#show slb cache
Total
--------------------------------------------------------------Cache Hits
Cache Misses
Memory Used
27648
Bytes Served
Entries Cached
Entries Replaced
Entries Aged Out
Entries Cleaned
Total Requests
Cacheable Requests
No-cache Requests
No-cache Responses
IMS Requests
304 Responses
Revalidation Successes
Revalidation Failures
Policy URI nocache
Policy URI cache
Policy URI invalidate
Content Too Big
Content Too Small
Srvr Resp - Cont Len
220
Srvr Resp - Chnk Enc
37
Srvr Resp - 304 Status
Srvr Resp - Other
Cache Resp - No Comp
383579
Cache Resp - Gzip
Cache Resp - Deflate
Cache Resp - Other
Entry create failures
530 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 configuration 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
531 of 950

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.
532 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
High Availability
This chapter describes High Availability (HA) and how to configure it.
Overview
High Availability (HA) is an AX feature that provides AX-level redundancy
to ensure continuity of service to clients. In HA configurations, AX devices
are deployed in pairs. If one AX device in the HA pair becomes unavailable,
the other AX device takes over.
You can configure either of the following types of HA:
Active-Standby One AX device is the primary SLB device for all vir-
tual services on which HA is enabled. The other AX device is a hot

Standby for the virtual services.
Active-Active Each AX device is the primary SLB device for some of
the configured virtual services, and is a hot Standby for the other configured virtual services.
Active-Active is supported only on AX devices that are deployed in route
mode. Active-Standby is supported on AX devices deployed in transparent
mode or route mode.
Note:
b y
Both AX devices in an HA pair should be the same model and should be

running the same software version. Using different AX models or different software versions in an HA pair is not supported.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
533 of 950

Overview
Layer 3 Active-Standby HA
Figure 142 shows an example of an Active-Standby configuration.
FIGURE 142
534 of 950
Active-Standby HA
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
In this example, each AX device provides SLB for two virtual servers, VIP1
and VIP2.
Each AX device has the following HA configuration elements:
HA ID The HA ID of AX1 is 1 and the AX ID of AX2 is 2. An AX
device must have an HA ID, which can be 1 or 2. The ID must be different on each AX device. The ID can be used as a tie breaker to select the
Active AX device. (See How the Active AX Device Is Selected on
page 551.)
HA group HA group 1 is configured on each AX device. An AX
device can have up to 31 HA groups.

Both VIPs on each AX device are members of the HA group.
Each HA group must be configured with a priority. The priority can be
used as a tie breaker to select the Active AX device for a VIP.
Session synchronization Also called connection mirroring, session
synchronization sends information about active client sessions to the

Standby AX device. If a failover occurs, the client sessions are maintained without interruption.
(For a complete list of configurable HA parameters, see HA Configuration
Parameters on page 556.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
535 of 950

Overview
Layer 3 Active-Active HA
Figure 143 shows an example of an Active-Active configuration.
FIGURE 143
Active-Active HA
In the Active-Active configuration, as in the Active-standby configuration.

only one AX is active for a given VIP. But unlike the Active-Standby configuration, the same AX device does not need to be the Active AX device
for all the VIPs. Instead, each of the AX devices can be the Active AX
device for some VIPs. In this example, AX1 is Active for VIP2 and AX2 is
Active for VIP1.
536 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
This configuration is similar to the configuration for Active-Standby shown
in Figure 142, with the following exceptions:
Both HA groups are configured on each of the AX devices. In Active-
Standby, only a single HA group is configured.

The priority values have been set so that each HA group has a higher
priority on one AX device than it does on the other AX device. In this

example, HA group 1 has a higher priority on AX2, whereas HA group
2 has a higher priority on AX1.
On each AX device, one of the VIPs is assigned to HA group 1 and the
other VIP is assigned to HA group 2.

On both AX devices, HA pre-emption is enabled. HA pre-emption
enables the devices to use the HA group priority values to select the
Active and Standby AX device for each VIP. Without HA pre-emption,
the AX selection is based on which of the AX devices comes up first.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
537 of 950

Overview
Layer 2 Active-Standby HA (Inline Deployment)

AX devices support Layer 2 hot standby inline deployment. Inline deployment allows you to insert a pair of AX devices into an existing network
without the need to reconfigure other devices in the network.
Inline support applies specifically to network topologies where inserting a
pair of AX switches would cause a Layer 2 loop, as shown in this example.
FIGURE 144
Topology Supported for Layer 2 Inline HA Deployment
In this example, a pair of routers configured as a redundant pair route traffic

between clients and servers. The redundant router pair can be implemented
using Virtual Router Redundancy Protocol (VRRP), Extreme Standby
Router Protocol (ESRP), or another equivalent router redundancy protocol.
538 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Each real server is connected to the router pair through a Layer 2 switch.
Neither the Layer 2 switches nor the routers are running Spanning Tree Protocol (STP). The network does not have any Layer 2 loops because the
Layer 2 switches are not connected directly together, and the routers do not
forward Layer 2 traffic.
If a pair of AX switches in transparent mode are added, the AX switches can
add redundant Layer 2 paths, which cause Layer 2 loops. To prevent loops
in this deployment, without making any configuration changes on the other
devices in the network, you can enable HA inline mode on the AX devices.
Inline mode automatically blocks redundant paths through the Standby AX
device, without the need to enable STP on any devices.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
539 of 950

Overview
FIGURE 145
Layer 2 Inline HA Deployment
Restrictions
Supported for Active-Standby HA deployments only. Not supported for
Active-Active HA.
Inline mode is designed for one HA group in Hot-Standby mode. Do not
configure more than one HA group on an AX running in inline mode.
540 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
In order to prevent Layer 2 loops in a Layer 2 host-standby environ-
ment, the Standby AX does not forward traffic. In addition, the Active
AX in the HA pair is designed to not forward packets destined for the
Standby AX. Depending on the network topology, certain traffic to the
Standby AX might be dropped if it must first pass through the Active
AX.
Preferred HA Port
When you enable inline mode on an AX, the AX uses a preferred HA port
for session synchronization and for management traffic between the AX
devices in the HA pair. For example, if you use the CLI on one AX to ping
the other AX, the ping packets are sent only on the preferred HA port. Likewise, the other AX sends the ping reply only on its preferred HA port.
Management traffic between AX devices includes any of the following
types of traffic:
Telnet
SSH
Ping
Optionally, you can designate the preferred HA port when you enable inline
mode. In Figure 145 on page 540, Ethernet interface 5 on each AX has been
configured as the preferred HA port.
The AX selects the Active AX devices preferred HA port as follows:
1. Is a preferred port specified with the inline configuration, and is the port
up? If so, use the port.
2. If no preferred HA port is specified in the configuration or that port is
down, the first HA interface that comes up on the AX is used as the preferred HA port.
3. If the preferred HA port selected by 1. or 2. above goes down, the HA
interface with the lowest port number is used. If that port also goes
down, the HA interface with the next-lowest port number is used, and so
on.
HA heartbeat messages are not restricted to the preferred HA port. Heartbeat messages are sent out all HA interfaces unless you disable the messages on specific interfaces.
Note:
b y
The preferred port must be added as an HA interface and heartbeat messages must be enabled on the interface.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
541 of 950

Overview
Port Restart
When a transition from Standby to Active occurs because the formerly
Active AX device becomes unavailable, the other devices that are directly
connected to the unavailable AX detect that their links to the AX have gone
down. The devices then flush their cached MAC entries on the down links.
For example, in Figure 145 on page 540, while AX1 is still Active, the
active router (the one on the left) uses the MAC entries it has learned on its
link with AX1 to reach downstream devices. If the link with AX1 goes
down, the router flushes the MAC entries. The router then relearns the
MAC addresses on the link with AX2 when it becomes the Active AX.
This mechanism is applicable when the link with AX1 goes down. However, if the transition from Active to Standby does not involve failure of the
router's link with AX1, the router does not flush its learned MAC entries on
the link. As a result, the router might continue to send traffic for downstream devices through the router's link with AX1. Since AX1 is now the
Standby, it drops the traffic, thereby causing reachability issues.
For example, if you administratively force a failover by changing the HA
configurations of the AX devices and enabling HA pre-emption, the link
between the router and AX1 remains up. In this case, the router continues to
have MAC addresses through this link.
To ensure that devices connected to the formerly Active AX flush their
learned MAC entries on their links with AX1, you can enable HA port
restart.
HA port restart toggles a specified set of ports on the formerly Active AX
by disabling the ports, waiting for a specified number of milliseconds, then
re-enabling the ports. Toggling the ports causes the links to go down, which
in turn causes the devices on the other ends of the links to flush their learned
MAC entries on the links. The devices then can relearn MACs through links
with the newly Active AX.
542 of 950
Note:
You must omit at least one port connecting the AX devices from the
restart port-list. This is so that heartbeat messages between the AX
devices are maintained; otherwise, flapping might occur.
Note:
On model AX 2000 or AX 2100, A10 recommends that you do not

include Fiber ports in the restart port list.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Layer 3 Active-Standby HA (Inline Deployment)

Inline mode HA is also supported for AX devices deployed in route mode
(Layer 3).
Layer 3 HA for inline mode is beneficial in network topologies where the
AX interfaces with the clients and real servers are in the same subnet.
FIGURE 146
Inline Mode for Layer 3 HA
In this example, each AX device has multiple Ethernet ports connected to

the clients, and multiple Ethernet ports connected to the servers. On each
AX device, all these Ethernet interfaces are configured as a single Virtual
Ethernet (VE) interface with a single IP address. The routers, both AX
devices, and the servers are all in the same subnet.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
543 of 950

Overview
Normally, this topology would introduce a traffic loop. However, the HA
inline mode prevents loops by logically blocking through traffic on the
standby AX device. Spanning Tree Protocol (STP) is not required in order
to prevent loops.
A dedicated link between the AX devices is used for HA management traffic. In this example, the dedicated link is in another subnet.
Comparison to Layer 2 Inline Mode
Layer 3 inline configuration is similar to Layer 2 inline mode configuration,
with the following exceptions:
Layer 3 inline mode does not require designation of a preferred port or
configuration of port restart.

CPU processing must be enabled on the Ethernet interfaces that will
receive server replies to client requests. CPU processing is required on

these interfaces in order to change the source IP address from the
servers real IP address back into the VIP address.
Restrictions
Supported for Active-Standby HA deployments only. Not supported for
Active-Active HA.
Inline mode is designed for one HA group in Hot-Standby mode. Do not
configure more than one HA group on an AX running in inline mode.

In order to prevent Layer 2 loops in a Layer 2 host-standby environ-
ment, the Standby AX does not forward traffic. In addition, the Active
AX in the HA pair is designed to not forward packets destined for the
Standby AX. Depending on the network topology, certain traffic to the
Standby AX might be dropped if it must first pass through the Active
AX.
HA Messages
The AX devices in an HA pair communicate their HA status with the following types of messages:
HA heartbeat messages
Gratuitous ARP requests and replies
544 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
HA Heartbeat Messages
Each of the AX devices regularly sends HA heartbeat messages out its HA
interfaces. The Standby AX device listens for the heartbeat messages. If the
Standby AX device stops receiving heartbeat messages from the Active AX
device, the Standby AX device transitions to Active and takes over networking and SLB operations from the other AX device.
By default, heartbeat messages are sent every 200 milliseconds. If the
Standby AX device does not receive a heartbeat message for 1 second
(5 times the heartbeat interval), the Standby AX device transitions to
Active.
The heartbeat interval and retry count are configurable. (See HA Configuration Parameters on page 556.)
Gratuitous ARPs
When an AX transitions from Standby to Active, the newly Active AX
device sends gratuitous ARP requests and replies (ARPs) for the IP address
under HA control. Gratuitous ARPs are sent for the following types of
addresses:
Virtual server IP addresses, for the VIPs that are assigned to an HA
group.
Floating IP address, if configured
NAT pool IP addresses, for NAT pools assigned to an HA group
Devices that receive the ARPs learn that the MAC address for the AX HA
pair has moved, and update their forwarding tables accordingly.
The Active AX device sends the gratuitous ARPs immediately upon becoming the Active AX device. To make sure ARPs are being received by the target addresses, the AX device re-sends the ARPs 4 additional times, at 500millisecond intervals.
After this, the AX device sends gratuitous ARPs every 30 seconds to keep
its IP information current.
The ARP retry count is configurable. (See HA Configuration Parameters
on page 556.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
545 of 950

Overview
HA Interfaces
When configuring HA, you specify each of the interfaces that are HA interfaces. An HA interface is an interface that is connected to an upstream
router, a real server, or the other AX device in the HA pair.
HA heartbeat messages can be sent only on HA interfaces. Optionally, you
can disable the messages on individual interfaces. When you configure an
HA interface that is a tagged member of one or more VLANs, you must
specify the VLAN on which to send the heartbeat messages.
Note:
The maximum number of HA interfaces you can configure is the same as

the number of Ethernet data ports on the AX device.
Note:
If the heartbeat messages from one AX device to the other will pass
though a Layer 2 switch, the switch must be able to pass UDP IP multicast packets.
Changes to the state of an HA interface can trigger a failover. By default,
the HA state of an interface can be Up or Down. Optionally, you can specify
the HA interface type as one of the following:
Server interface A real server can be reached through the interface.
Router interface An upstream router (and ultimately, clients) can be
reached through the interface.

Both Both a server and upstream router can be reached through the
interface.
If you specify the HA interface type, the HA status of the AX device is
based on the status of the AX link with the real server and/or upstream
router. The HA status can be one of the following:
Up All configured HA router and server interfaces are up.
Partially Up Some HA router or server interfaces are down but at least
one server link and one router link are up.

Down All router interfaces, or all server interfaces, or both are down.
The status also is Down if both router interfaces and server interfaces
are not configured and an HA interface goes down.
If both types of interfaces (router interfaces and server interfaces) are configured, the HA interfaces for which a type has not been configured are not
included in the HA interface status determination.
During selection of the active AX, the AX with the highest state becomes
the active AX and all HA interfaces on that AX become active. For exam-
546 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
ple, if one AX is UP and the other AX is only Partially Up, the AX that is
UP becomes the active AX.
If each AX has the same state, the active AX is selected as follows:
If HA pre-emption is disabled (the default), the first AX to come up is
the active AX.

If HA pre-emption is enabled, the AX with the higher HA group priority
becomes active for that group. If the group priorities on the two AX
devices are also the same, the AX that has the lowest HA ID (1 or 2)
becomes active.
You can configure up to 31 HA groups on an AX, and assign a separate
HA priority to each. For Active-Standby configurations, use only one
group ID. For Active-Active configurations, use multiple groups IDs and
assign VIPs to different groups.
Note:
Session Synchronization
HA session synchronization sends information about active client sessions
to the Standby AX device. If a failover occurs, the client sessions are maintained without interruption. Session synchronization is optional. Without it,
a failover causes client sessions to be terminated. Session synchronization
can be enabled on individual virtual ports.
Session synchronization applies primarily to Layer 4 sessions. Session synchronization does not apply to DNS sessions. Since these sessions are typically very short lived, there is no benefit to synchronizing them. Likewise,
session synchronization does not apply to static NAT sessions. Synchronization of these sessions is not needed since the newly Active AX device will
create a new flow for the session following failover.
To enable session synchronization, see Enabling Session Synchronization
on page 595.
Session synchronization is required for config sync. Config sync uses the
session synchronization link. (For more information, Synchronizing Configuration Information on page 598.)
Note:
b y
Session synchronization is also called connection mirroring.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
547 of 950

Overview
Optional Failover Triggers

In addition to HA interface-based failover, you can configure failover based
one any of the following:
Inactive VLAN (VLAN-based failover)
Unresponsive gateway router (gateway-based failover)
Unresponsive real servers (VIP-based failover)
VLAN-based Failover
You can enable HA checking for individual VLANs. When HA checking is
enabled for a VLAN, the active AX device in the HA pair monitors traffic
activity on the VLAN. If there is no traffic on the VLAN for half the duration of a configurable timeout, the AX device attempts to generate traffic by
issuing ping requests to servers if configured, or broadcast ARP requests
through the VLAN.
If the AX device does not receive any traffic on the VLAN before the timeout expires, a failover occurs. The timeout can be 2-600 seconds. You must
specify the timeout. Although there is no default, A10 recommends trying
30 seconds.
This HA checking method provides a passive means to detect network
health, whereas heartbeat messages are an active mechanism. You can use
either or both methods to check VLAN health. If you use both methods on a
VLAN, A10 recommends that you specify an HA checking interval (timeout) that is much longer than the heartbeat interval.
For a configuration example, see VLAN-Based Failover Example on
page 588.
Gateway-based Failover
Gateway-based failover uses ICMP health monitors to check the availability
of the gateways. If any of the active AX devices gateways fails a health
check, the AX device changes its HA status to Down. If the HA status of the
other AX device is higher than Down, a failover occurs.
Likewise, if the gateway becomes available again and all gateways pass
their health checks, the AX device recalculates its HA status according to
the HA interface counts. If the new HA status of the AX device is higher
than the other AX devices HA status, a failover occurs.
548 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Configuration of gateway-based failover requires the following steps:
1. Configure a health monitor that uses the ICMP method.
2. Configure the gateway as an SLB real server and apply the ICMP health
monitor to the server.
3. Enable HA checking for the gateway.
For a configuration example, see Gateway-Based Failover Example on
page 589.
Route-based Failover
Route-based failover reduces the HA priority of all HA groups on the AX
device, if a specific route is missing from the IPv4 or IPv6 route table.
You can configure this feature for individual IP routes. When you configure
this feature for a route, you also specify the value to subtract from the HA
priority of all HA groups, if the route is missing from the route table.
You can configure this option for up to 100 IPv4 routes and up to 100 IPv6
routes. This option is valid for all types of IP routes supported in this release
(static, RIP, and OSPF).
If the priority of an HA group falls below the priority for the same group on
the other AX device in an HA pair, a failover can be triggered.
Notes
This feature applies only to routes in the data route table. The feature
does not apply to routes in the management route table.

For failover to occur due to HA priority changes, the HA pre-emption
option must be enabled.

For a configuration example, see Route-Based Failover Example on
page 591.
Real Server or Port Health-based Failover

You can configure the AX device to decrease the HA priority of an HA
group, if a real server or ports health status changes to Down.
You can configure this feature on individual real servers and ports. The feature is disabled by default. To enable the feature, assign an HA weight to the
server or port. If the server or ports health status changes to Down, the
weight value is subtracted from the priority value of the HA group. You can
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
549 of 950

Overview
specify a single HA group or allow the priority change to apply to all HA
groups.
If the server or ports status changes back to Up, the weight value is added
back to the HA groups priority value.
If the HA priority of a group falls below the priority of the same group on
the other AX device, HA failover can be triggered.
Notes
The lowest HA priority value a server or port can have is 1.
If HA weights for an HA group are assigned to both the server and an
individual port, and both health checks are unsuccessful, only the server
weight is subtracted from the HA groups priority.
For failover to occur due to HA priority changes, the HA pre-emption
option must be enabled.
VIP-based Failover
VIP-based failover allows service for a VIP to be transferred from one AX
device in an HA pair to the other AX device based on HA status changes of
the real servers.
When you configure an HA group ID, you also specify its priority. If HA
pre-emption is enabled, the HA groups priority can be used to determine
which AX device in the HA pair becomes the Active AX for the HA group.
In this case, the AX device that has a higher value for the groups priority
becomes the Active AX device for the group.
If you enable the dynamic HA option on a virtual server, the AX device
reduces the HA priority of the group assigned to the virtual server, if a real
server becomes unavailable. (A real server is unavailable if it is marked
Down by the AX device because the server failed its health check.) If the
priority value is reduced to a value that is lower than the groups priority
value on the other AX device in the HA pair, and HA pre-emption is
enabled, service of the virtual serve is failed over to the other AX device.
When a real server becomes available again, the weight value that was subtracted from the HA groups priority is re-added. If this results in the priority value being higher than on the other AX device, the virtual server is
failed over again to the AX device with the higher priority value for the
group.
550 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Configure the same HA group ID on any floating IP addresses or Source
IP NAT pools used by the virtual server. For example, if you assign a virtual server to HA group 31, also assign any floating IP addresses and IP
Source NAT pools used by the virtual server to HA group 31.
Note:
For a configuration example, see VIP-Based Failover Example on

page 593.
How the Active AX Device Is Selected

In Active-Standby configurations, only one AX device is Active and the
other is the Standby. After you configure HA, the Active AX device is
selected using the process shown in Figure 147.
FIGURE 147
b y
Initial Selection of Active AX Device
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
551 of 950

Overview
After initial selection of the Active AX device, that device remains the
Active AX device unless one of the following events occurs:
The Standby AX device stops receiving HA heartbeat messages from
the Active AX device.

The HA interface status of the Active AX device becomes lower than
the HA interface status of the Standby AX device.

VLAN-based failover is configured and the VLAN becomes inactive.
Gateway-based failover is configured and the gateway becomes unavail-
able.
HA pre-emption is enabled, and the configured HA priority is changed
to be higher on the Standby AX device.

Figure 148 shows the events that can cause an HA failover.
552 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
FIGURE 148
b y
HA Failover
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
553 of 950

Overview
HA Pre-Emption
By default, a failover occurs only in the following cases:
The Standby AX device stops receiving HA heartbeat messages form
the other AX device in the HA pair.

HA interface state changes give the Standby AX device a better HA
state than the Active AX device. (See HA Interfaces on page 546.)

VLAN-based failover is configured and the VLAN becomes inactive.
(See VLAN-based Failover on page 548.)

Gateway-based failover is configured and the gateway becomes unavail-
able. (See Gateway-based Failover on page 548.)

VIP-based failover is configured and the unavailability of real servers
causes the Standby AX to have the greater HA priority for the VIPs HA
group. (See VIP-based Failover on page 550.)
By default, failover does not occur due to HA configuration changes to the
HA priority.
To enable the AX devices to failover in response to changes in priority,
enable HA pre-emption. When pre-emption is enabled, the AX device with
the higher HA priority becomes the Active AX device. If the HA priority is
equal on both AX devices, then the AX device with the lower HA ID (1)
becomes the Active AX device.
Note:
554 of 950
To force Active groups to change to Standby status, without changing HA

group priorities and enabling pre-emption, see Forcing Active Groups to
Change to Standby Status on page 595.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
HA Sets
Optionally, you can provide even more redundancy by configuring multiple
sets of HA pairs.
FIGURE 149
Multiple HA Pairs
In this example, two HA pairs are configured. Each pair is distinguished by

an HA set ID. Each HA pair can be used to handle a different set of real
servers.
You can configure up to 7 HA sets. This feature is supported for Layer 2 and
Layer 3 HA configurations. The set ID can be specified along with the HA
ID. (For syntax information, see Table 14 on page 556.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
555 of 950

Overview
HA Configuration Parameters
Table 14 lists the HA parameters.
TABLE 14 HA Parameters
Parameter
Supported Values
HA ID
HA ID of the AX device, and HA set to which the

AX device belongs.
HA ID: 1 or 2
The HA ID uniquely identifies the AX device

within the HA pair.
Default: Neither parameter is set
Global HA Parameters
and
HA set ID
HA set ID: 1-7
The HA set ID specifies the HA set to which the AX

device belongs. This parameter is applicable to configurations that use multiple AX pairs.
[no] ha id {1 | 2} [set-id num]
HA group ID
Config > HA > Setting > HA Global - General

Uniquely identifies the HA group on an individual
AX device.
HA group ID: 1-31
The priority value can be used during selection of

the Active AX device. (SeeHow the Active AX
Device Is Selected on page 551.)
Default: not set
Priority: 1 (low priority) to 255 (high

priority
[no] ha group group-id priority num

Floating IP
address
Config > HA > Setting > HA Global - Group

IP address that downstream devices should use as
their default gateway. The same address is shared by
both AX devices in the HA pair. Regardless of
which device is Active, downstream devices can
reach their default gateway at this IP address.
Default: not set
[no] floating-ip ipaddr

ha-group group-id
Config > HA > Setting > HA Global - Floating IP
Address
556 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
TABLE 14 HA Parameters (Continued)
Parameter
HA interfaces

Interfaces used for HA management.
Supported Values
AX Ethernet interfaces
HA heartbeat messages are sent on HA interfaces,

unless you use the option to disable the messages.
Default: not set
At least one HA interface must be specified. If the

interface is tagged, then a VLAN ID must be specified if heartbeat messages are enabled on the interface.
If you specify the interface type (server, router, or
both), changes to the interface state can control
failover. (See HA Interfaces on page 546 and
How the Active AX Device Is Selected on
page 551.)
[no] ha interface ethernet port-num
[router-interface |
server-interface | both]
VLAN-based
HA
Config > Network > Interface > LAN - Select the

interface and then click HA.
Enables the AX device to change its HA status
based on the health of a VLAN.
When HA checking is enabled for a VLAN, the
active AX device in the HA pair monitors traffic
activity on the VLAN. If there is no traffic on the
VLAN for half the duration of a configurable timeout, the AX device attempts to generate traffic by
issuing ping requests to servers if configured, or
broadcast ARP requests through the VLAN.
Valid VLAN ID
Default: not set
The timeout can be 2-600 seconds.
Although there is no default timeout,
A10 recommends trying 30 seconds.
If the AX device does not receive any traffic on the

VLAN before the timeout expires, a failover occurs.
[no] ha check vlan vlan-id timeout
seconds
Gateway-based
HA
Config > HA > Setting > HA Global - Status Check

Enables the AX device to change its HA status
based on the health of a gateway router.
IP address of the gateway
If the gateway fails a Layer 3 (ICMP) health check,

the AX device changes its HA status to Down. If the
HA status of the other AX device is higher than
Down, a failover occurs.
Additional configuration is required.

(See Gateway-based Failover on
page 548.)
Default: not set
[no] ha check gateway ipaddr

Config > HA > Setting > HA Global - Status Check
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
557 of 950

Overview
Parameter
Session synchronization
(Also called
connection mirroring)

Enables the AX devices to share information about
active client sessions. If a failover occurs, client sessions continue uninterrupted. The Standby AX
device, when it becomes Active, uses the session
information it received from the Active AX device
before the failover to continue the sessions without
terminating them.
Supported Values
IP address of the other AX device
Default: not set
To enable session synchronization, specify the IP

address of the other AX device in the HA pair.
Session synchronization does not apply to DNS sessions. Since these sessions are typically very short
lived, there is no benefit to synchronizing them.
Note: This option also requires session synchronization to be enabled on the individual virtual service
ports. (See HA Parameters for Virtual Service
Ports below.)
[no] ha conn-mirror ip ipaddr
Pre-emption

Controls whether failovers can be caused by configuration changes to HA priority or HA ID.
Enabled or disabled
Default: disabled
[no] ha preemption-enable
HA heartbeat
interval

Interval at which the AX device sends HA heartbeat
messages on its HA interfaces.
[no] ha time-interval
100-msec-units
Retry count

Number of HA heartbeat intervals the Standby
device will wait for a heartbeat message from the
Active AX device before failing over to become the
Active AX device.
1-255 units of 100 milliseconds

(ms) each
Default: 200 ms
2-255
Default: 5
[no] ha timeout-retry-count num

ARP repeat
count
558 of 950

Number of additional gratuitous ARPs, in addition
to the first ones, an AX sends after transitioning
from Standby to Active in an HA configuration.
[no] ha arp-retry num
1-255
Default: 4 additional gratuitous
ARPs, for a total of 5
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Parameter
Forced failover
Layer 2/3
forwarding of
Layer 4 traffic on
the Standby AX
device

Forces HA groups to change from Active to
Standby status.
[no] ha force-self-standby
[group-id]
Note: This option provides a simple method to force
a failover, without the need to change HA group priorities and enable pre-emption. The option is not
added to the configuration and does not persist
across reboots.
Note: The current release does not support configuration of this parameter using the GUI.
Enables Layer 2/3 forwarding of Layer 4 traffic on
the Standby AX device.
[no] ha forward-l4-packet-onstandby
Note: The current release does not support configuration of this parameter using the GUI.
Supported Values
Valid HA group ID.
If you do not specify a group ID, all
Active groups are forced to change
from Active to Standby status.
Enabled or disabled
Default: Disabled. Layer 4 traffic is
dropped by the Standby AX device.
Global HA Parameters for Layer 2 Inline Mode

Inline mode state
Enables Layer 2 inline mode and, optionally, specifies the HA interface to use for session synchronization and for management traffic between the AX
devices.
[no] ha inline-mode
[preferred-port port-num]
Restart port list
Config > HA > Setting - HA Inline Mode

List of Ethernet interfaces on the previously Active
AX device to toggle (shut down and restart) following HA failover.
Enabled or disabled
Default: disabled
When inline mode is enabled, the preferred port is selected as described in
Preferred HA Port on page 541.
AX Ethernet interfaces
Default: not set
[no] ha restart-port-list ethernet

port-list
Port restart time

Amount of time interfaces in the restart port list
remain disabled following a failover.
[no] ha restart-time 100-msec-units
1-100 units of 100 milliseconds (ms)

Default: 20 units of 100 ms (2 seconds)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
559 of 950

Overview
Parameter
Supported Values
Global HA Parameters for Layer 3 Inline Mode

Inline mode state
OSPF on
Standby AX
device
Enables Layer 3 inline mode.
Enabled or disabled
[no] ha l3-inline-mode
Default: disabled

Leaves OSPF enabled on the Standby AX device.
Enabled or disabled
[no] ha ospf-inline vlan vlan-id

Note: This option is not configurable using the
GUI.
Default for all HA modes except

Layer 3 inline: disabled. OSPF is disabled on the Standby AX device.
Default for Layer 3 inline mode:
enabled. OSPF is allowed to run on all
VLANs by default.
100 milliseconds (ms) to 10000 ms, in
increments of 100 ms
Default: 3000 ms (3 seconds)
Link event delay
Change the delay waited by the AX device before

changing the HA state (Up, Partially Up, or Down)
in response to link-state changes on HA interfaces.
[no] ha link-event-delay
100-ms-unit
HA group ID
HA group ID for a virtual server.
1-31
This is required to enable HA for the VIP.
Default: not set
HA Parameters for Virtual Servers

Server weight

Weight value assigned to real servers bound to the
virtual server.
1-255
Not set
The weight is used for VIP-based failover. (See

VIP-based Failover on page 550.)
[no] ha-dynamic server-weight
Link event delay
560 of 950
Config > Service > SLB > Virtual Server - Select

the HA group, then select the Dynamic Server
Weight.
Change the delay waited by the AX device before
changing the HA state (Up, Partially Up, or Down)
in response to link-state changes on HA interfaces.
[no] ha link-event-delay
100-ms-unit
100 milliseconds (ms) to 10000 ms, in

increments of 100 ms
Default: 3000 ms (3 seconds)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Parameter
Supported Values
HA Parameters for Virtual Service Ports

Session
synchronization
Enables active client sessions on this virtual port to

continue uninterrupted following a failover.
(Also called
connection mirroring)
Note: This option also requires session synchronization to be enabled globally. (See Global HA
Parameters above.)
Enabled or disabled
Default: disabled
[no] ha-conn-mirror
Config > Service > SLB > Virtual Server - Port
HA Parameters for Real Servers

Priority cost
Decreases the HA priority of an HA group, if the

real servers health status changes to Down.
[no] ha-priority-cost weight
[ha-group group-id]
Weight: 1-255
HA group: 1-31. If no group is specified, the weight applies to all HA
groups.
Default: not set
HA Parameters for Real Ports

Priority cost
Decreases the HA priority of an HA group, if the

real ports health status changes to Down.
[no] ha-priority-cost weight
[ha-group group-id]
Weight: 1-255
HA group: 1-31. If no group is specified, the weight applies to all HA
groups.
Default: not set
HA Parameters for Firewall Load Balancing (FWLB)

Note: For an example of an FWLB HA configuration, see Firewall Load Balancing on page 327.
HA group ID
HA group ID for a virtual firewall or virtual firewall 1-31
port.
Default: not set
Server (for virtual firewall)
Session
synchronization

Server - Port (for virtual firewall port)
Enables active client sessions on this virtual firewall
port to continue uninterrupted following a failover.
Enabled or disabled
Default: disabled
Note: This option also requires session synchronization to be enabled globally. (See Global HA
Parameters above.)
[no] ha-conn-mirror
Server (for virtual firewall)
Server - Port (for virtual firewall port)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
561 of 950

Overview
Parameter
Supported Values
HA Parameters for IP Network Address Translation (NAT) Pools

HA group ID
HA group ID for IP NAT.
1-31
Option with ip nat pool, ipv6 nat pool, or ip nat

inside command: ha-group group-id
Default: not set

Config > Service > IP Source NAT > NAT Range
HA Parameters for IP Routes

Priority cost
Reduces the HA priority of all HA groups on the

AX device, if the specified route is missing from the
IPv4 or IPv6 route table.
Default: not set
For IPv4 routes:

[no] ha check route
destination-ipaddr /mask-length
priority-cost weight
[gateway ipaddr]
[protocol {static | dynamic}]
[distance num]
For IPv6 routes:
[no] ha check route
destination-ipv6addr/mask-length
[gateway ipv6addr]
[distance num]
562 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

HA Status Indicators
HA Status Indicators
The HA status of an AX device is displayed in the GUI and CLI. The HA
status indicators provide the following information:
Current HA status of the AX device: Active or Standby
Configuration status:
Most recent configuration update The system time and date when
the most recent configuration change was made.

Most recent configuration save The system time and date when
the configuration was saved to the startup-config.
Most recent config-sync The system time and date when the most
recent configuration change was made.
If the AX device is configured with multiple Role-Based Administration
(RBA) partitions, separate configuration status information is shown for
each partition.
In the GUI
The current HA status is shown as one of the following:
Active
Standby
Not Configured
The config-sync status is shown as one of the following:

Sync
Not-Sync
The GUI does not indicate when the most recent configuration update or
save occurred. This information is available in the CLI. (See below.)
In the CLI
In the CLI, the HA the status is shown in the command prompt. For example:
AX-Active#
or
AX-Standby#
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
563 of 950

Configuring Layer 3 HA
Note:
If HA is not configured, the prompt is simply the hostname (AX by

default).
Configuration status is displayed in show running-config output. Here is an
example:
AX-Active#show running-config
!Current configuration: 8134 bytes
partition partition-1
!
!Configuration last updated at 08:11:05 IST Mon May 17 2010
!Configuration last saved at 15:16:49 IST Sat May 15 2010
!Configuration last synchronized at 08:15:02 IST Mon May 17 2010
Disabling HA Status Display in the CLI Prompt

Display of the HA status in the CLI prompt is enabled by default. To disable
it, use the following command at the global configuration level of the CLI:
[no] terminal no-ha-prompt
To configure Layer 3 HA:
1. Configure the following global HA parameters:
HA ID
HA group ID and priority. For an Active-Standby configuration,
configure one group ID. For Active-Active, configure multiple HA
group IDs.
Floating IP address (optional)
Session synchronization (optional)
HA pre-emption (optional)
2. Configure the HA interfaces.
3. Add each virtual server to an HA group.
4. If session synchronization is globally enabled, enable it on the individual virtual ports whose client sessions you want to synchronize.
5. If IP NAT pools are configured, add each pool to an HA group.
564 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

Configuring Global HA Parameters
1. Select Config > HA > Setting.
a. In the Identifier drop-down list, select the HA ID for the AX device.
b. Select Enabled next to HA Status.
c. To enable pre-emption, select Enabled next to Preempt Status.
d. To enable connection mirroring, enter the IP address of the other
AX device in the HA Mirroring IP Address field.
Enter the real IP address of the AX device, not the floating IP address that
downstream devices will use as their default gateway address.
Note:
2. In the Group section, configure HA group parameters:

a. Select HA group 1 from the Group Name drop-down list.
b. In the Priority field, enter the priority for HA group 1 and click Add.
c. If you are configuring Active-Active, select the next HA group from
the Group Name drop-down list, enter its priority in the Priority
field, and click Add.
Repeat for each additional group used in the configuration.
3. In the Floating IP Address section, configure the floating IP addresses
for the HA groups.
a. Select an HA group from the Group Name drop-down list.
b. Select the address type (IPv4 or IPv6).
c. Enter the floating IP address for the group.
d. Click Add.
e. If you are configuring Active-Active, select the next HA group from
the Group Name drop-down list, and repeat the previous steps.
4. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
565 of 950

Configuring HA Interfaces
2. On the menu bar, select LAN. The list of the AX devices physical
Ethernet data interfaces appears.
3. Perform the following steps for each HA interface. (For information, see
HA Interfaces on page 546.)
a. Click on the interface number.
b. In the HA section, select Enabled next to HA Enabled.
c. To specify the interface type, select one of the following or leave the
setting None:
Router-Interface
Server-Interface
Both
d. To enable HA heartbeat messages, select Enabled next to Heartbeat.
e. To restrict the HA heartbeat messages to a specific VLAN, enter the
VLAN ID in the VLAN field.
f. Click OK.
Configuring HA Parameters on a Virtual Server
2. On the menu bar, select Virtual Server.
3. Click on the virtual server name or click Add to add a new one.
4. In the General section, select the HA group ID from the HA Group
drop-down list.
Note:
The Dynamic Server Weight option is used for VIP-based failover. For
information, see VIP-based Failover on page 550.
5. Configure other general settings, not related to HA, if needed.
6. If you plan to use session synchronization (connection mirroring) for a
service port:
a. In the Port section, click Add to add a new virtual service port or
select an existing port and click Edit. The Virtual Server Port section appears.
b. Select enabled next to HA Connection Mirror.
c. Click OK. The service port list re-appears.
566 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The GUI does not support enabling connection mirroring on some types
of service ports. However, you can enable connection mirroring for these
service types using the CLI.
Note:
7. Click OK to complete configuration of the virtual server.

HA Configuration of AX1
FIGURE 150
b y
Config > HA > Setting > HA Global
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
567 of 950

FIGURE 151
Note:
This example shows HA configuration of a single interface. Make sure to

configure HA settings on the other HA interfaces too.
FIGURE 152
568 of 950
Config > Service > Network > LAN (Ethernet interface 1)
Config > Service > SLB > Virtual Server (VIP1)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 153
HA Configuration of AX2
FIGURE 154
b y
Config > HA > Setting
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
569 of 950

FIGURE 155
FIGURE 156
USING THE CLI

1. To configure the global HA parameters, use the following commands at
the global configuration level of the CLI:
ha id {1 | 2} [set-id num]
ha group group-id priority num
floating-ip ipaddr ha-group group-id
ha interface ethernet port-num
[router-interface | server-interface | both]
ha conn-mirror ip ipaddr
ha preemption-enable
2. To add a virtual server to an HA group, use the following command at
the configuration level for the virtual server:
ha-group group-id
570 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Use the same HA group ID for the same virtual server, on both AX
devices.
3. If session synchronization is globally enabled, use the following command at the configuration level for the virtual port to enable session synchronization for the port:
ha-conn-mirror
4. If IP NAT pools are configured, use the following option with the ip nat
pool or ipv6 nat pool command.
ha-group group-id
(For the complete command syntax, see Table 14 on page 556.)
Commands on AX1
This examples shows the CLI commands to implement the Active-Active
configuration shown in Figure 143 on page 536.
The following commands configure the HA ID and HA groups. Since this is
an Active-Active configuration, both HA groups are configured. The priority for group 1 is set to a low value. The same group will be set to a higher
priority value on the other AX device. Likewise, the priority of group 2 is
set to a high value on this AX device but will be set to a lower value on the
other AX device.
Later in the configuration, each virtual server will need to be added to one
or the other of the HA groups.
AX1(config)#ha id 1
AX1(config)#ha group 1 priority 1
The following commands configure the floating IP addresses for each HA

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

are specified, so that the HA state of the AX device can be more precisely
calculated based on HA interface state. (See HA Interfaces on page 546.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
571 of 950

Heartbeat messages are disabled on all HA interfaces except the dedicated
HA link between the AX devices.
AX1(config)#ha interface ethernet 1 router-interface no-heartbeat
AX1(config)#ha interface ethernet 3 server-interface no-heartbeat
AX1(config)#ha interface ethernet 5
The following command enables session synchronization (connection mirroring). The feature also will need to be enabled on individual virtual ports,
later in the configuration. The IP address is the real address of the other AX
device.
AX1(config)#ha conn-mirror ip 10.10.30.2
The following command enables HA pre-emption, to ensure that the Active

and Standby for each virtual server are chosen based on the configuration.
By default, when HA is first configured, Active and Standby are selected
based on which AX device comes up first.
AX1(config)#ha preemption-enable
The following commands add each of the virtual servers to an HA group,

and enables session synchronization on the virtual ports. (For brevity, this
example does not show the complete SLB configuration, only the HA part
of the SLB configuration.)
AX1(config)#slb virtual-server VIP1
AX(config-slb virtual server)#ha-group 1
AX(config-slb virtual server-slb virtua...)#ha-conn-mirror
AX(config-slb virtual server)#exit
AX1(config-slb virtual server)#ha-group 2
AX1(config-slb virtual server)#port 80 tcp
AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror
AX1(config-slb virtual server-slb virtua...)#exit
AX1(config-slb virtual server)#exit
572 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Commands on AX2
Here are the commands for AX2. The priority values for the groups are different from the values set on AX1, so that group 1 has higher priority on this
AX device than on AX1. Likewise, the priority of group 2 is set so that its
priority is higher on AX1.
AX2(config)#ha id 2
The floating IP addresses must be the same as the ones set on AX1.
The IP address for session synchronization is the address of AX1.

The HA configuration for virtual servers and virtual ports is identical to the
configuration on AX1.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
573 of 950

Configuring Layer 2 HA (Inline Mode)

HA ID
HA group ID and priority. Configure only one group ID. Configure
the same ID on both AX devices.
Inline mode and optional preferred port
Restart port list and time (optional)
HA interfaces
2. Add each virtual server to the HA group.
4. If IP NAT pools are configured, add each pool to the HA group.
Note:
If source NAT is not configured for the VIP, but real servers send
responses to a gateway IP address other than the AX floating IP address,
CPU processing must be enabled on the AX interfaces connected to the
real servers. This applies to the following AX models: AX 2200,
AX 3100, AX 3200, AX 5100, and AX 5200. On other models, the option
for CPU processing is not valid and is not required.
Layer 2 Inline HA Configuration Example

The following configuration examples implement the deployment shown in
Figure 145 on page 540. In addition to the inline features described in this
section, the sample configuration also uses the following HA features:
Identification of HA interface type: server or router The interface
types affect the AX devices summary link state for HA. (See HA
Interfaces on page 546.)
Session synchronization (also called connection mirroring) Existing
client sessions remain up during a failover.

Floating IP The default gateway IP address used by the real servers is
a floating IP address shared by the AX devices, rather than the IP

address of the Active AX. Servers can still reach clients through their
574 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

default gateway after an HA failover, without the need for the gateway
address to be changed to the Standby AX devices address.
USING THE GUI

Configuring Global HA Parameters
a. In the General section, select the HA ID for the AX device from the
Identifier drop-down list.
b. Select Yes next to HA Status.
c. To enable pre-emption, select Yes next to Preempt Status.
d. To enable connection mirroring, enter the IP address of the other
AX device in the HA Mirroring IP Address field.
Enter the real IP address of the AX device, not the floating IP address that
downstream devices will use as their default gateway address.
Note:
2. In the Group section, configure HA group parameters:

a. Select HA group 1 from the Group Name drop-down list.
b. In the Priority field, enter the priority for HA group 1 and click Add.
3. In the Floating IP Address section, configure the floating IP address for
the HA group.
a. Select an HA group 1 from the Group Name drop-down list.
b. Select the address type (IPv4 or IPv6).
c. Enter the floating IP address for the group.
d. Click Add.
4. Click OK.
Configuring HA Interface Parameters
2. On the menu bar, select LAN. The list of the AX devices physical
Ethernet data interfaces appears.
3. Perform the following steps for each HA interface. (For information, see
HA Interfaces on page 546.)
a. Click on the interface number.
b. In the HA section, select Enabled next to HA Enabled.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
575 of 950

c. To specify the interface type, select one of the following or leave the
setting None:
Router-Interface
Server-Interface
Both
d. To enable HA heartbeat messages, select Enabled next to Heartbeat.
e. To restrict the HA heartbeat messages to a specific VLAN, enter the
VLAN ID in the VLAN field.
f. If source NAT is not configured for the VIP, but real servers send
responses to a gateway IP address other than the AX floating IP
address, select CPU Process in the General section. This requirement applies to the following AX models: AX 2200, AX 3100, AX
3200, AX 5100, and AX 5200. On other models, the command for
CPU processing is not valid and is not required.
g. Click OK.
Configuring Inline Parameters
2. Select HA Inline Mode on the menu bar.
3. Select Enabled next to Inline Mode Status.
4. Select the preferred port.
5. In Restart Port List section, select the HA interfaces.
6. Click >> to move them to the Selected list.
7. Click OK.
The following GUI screens configure HA on AX1 in Figure 145 on
page 540.
576 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 157
b y
Config > HA > Setting
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
577 of 950

FIGURE 158
Note:
This example shows HA configuration of a single interface. Make sure to

configure HA settings on the other HA interfaces too.
FIGURE 159
578 of 950
Config > Service > Network > LAN (Ethernet interface 1)
Config > HA > Setting > HA Inline Mode
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

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

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

routers, to occur if the AX transitions to Standby.
AX1(config)#ha restart-port-list ethernet 1 to 2
If source NAT is not configured for the VIP, but real servers send
responses to a gateway IP address other than the AX floating IP address,
enter the cpu-process command at the configuration level for each interface connected to the real servers. This requirement applies to the following AX models: AX 2200, AX 3100, AX 3200, AX 5100, and AX 5200.
On other models, the command for CPU processing is not valid and is not
required.
Note:
The following command enables HA pre-emption mode, which causes

failover to occur in response to administrative changes to the HA configuration. (For example, if you change the HA priority so that the other AX has
higher priority, this will trigger a failover, but only if pre-emption mode is
enabled.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
579 of 950

The following command specifies the IP address of the other AX, to use for
session synchronization.
The following command configures the floating IP address for the real servers to use as their default gateway address.
The following commands configure a health method, real servers, a server

group, and a VIP for an HTTP service.
AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3
AX1(config-health:monitor)#method http url HEAD /index.html
AX1(config-health:monitor)#exit
AX1(config)#slb server s1 172.168.10.30
AX1(config-real server)#port 80 tcp
AX1(config-real server-node port)#health-check myHttp
AX1(config-real server-node port)#exit
AX1(config-real server)#exit
AX1(config)#slb service-group g80 tcp
AX1(config-slb service group)#member s1:80
AX1(config-slb service group)#exit
AX1(config)#slb virtual-server v1 172.168.10.80
AX1(config-slb virtual server-slb virtua...)#service-group g80
580 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Commands on AX2
Here are the commands for implementing HA on the standby AX, AX2.
Most of the commands are the same as those on AX1, with the following
exceptions:
The HA ID is 2.
The HA priority is 1.
The session synchronization (conn-mirror) IP address is the address of
the Active AX. (On the Active AX, the session synchronization IP
address is the address of the Standby AX.)
AX2(config)#ha id 2
AX2(config)#ha inline-mode preferred-port 5
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
581 of 950


HA ID
HA group ID and priority. Configure only one group ID. Configure
the same ID on both AX devices.
Inline mode
HA interfaces
2. Enable CPU processing on the Ethernet interfaces that will receive
server replies to client requests.
3. Add each virtual server to the HA group.
5. If IP NAT pools are configured, add each pool to the HA group.
582 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Layer 3 Inline HA Configuration Example

The following configuration example implements the deployment shown in
The GUI does not support configuration of Layer 3 inline mode in the
current release.
Note:
USING THE CLI

1. To enable Layer 3 inline mode, use the following command at the global configuration level of the CLI:
ha l3-inline-mode
2. To enable CPU processing on an interface, use the following command
at the configuration level for the interface:
cpu-process
If the interface is part of a trunk, use the command on the lead interface
of the trunk. (The lead interface of a trunk is the lowest-numbered interface in the trunk.)
Commands on AX1
The following commands configure the interfaces. Since Ethernet interfaces
3 and 4 will receive server replies to client requests, CPU processing is
enabled on those interfaces.
AX1(config)#interface ethernet 1
AX1(config-if:ethernet1)#enable
AX1(config-if:ethernet1)#interface ethernet 2
AX1(config-if:ethernet3)#cpu-process
AX1(config-if:ethernet5)#exit
AX1(config)#vlan 100
AX1(config-vlan:100)#untagged ethernet 1 to 4
AX1(config-vlan:100)#router-interface ve 1
AX1(config-vlan:100)#exit
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
583 of 950

AX1(config)#vlan 5
AX1(config-vlan:5)#untagged ethernet 5
AX1(config)#interface ve1
AX1(config-if:ve1)#ip address 172.168.10.2 /24
AX1(config-if:ve1)#interface ve5
AX1(config-if:ve5)#exit
The following commands configure the HA ID and set the HA priority. HA

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

AX1(config)#ha l3-inline-mode
The following commands configure the HA interfaces. Each interface that is

connected to a server, a router, or the other AX can be configured as an HA
interface. (Make sure to add the dedicated HA link between the AX devices
as one of the HA interfaces.)
The following command enables restart of the HA ports connected to the

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

failover to occur in response to administrative changes to the HA configuration. (For example, if you change the HA priority so that the other AX has
higher priority, this will trigger a failover, but only if pre-emption mode is
enabled.)
The following command specifies the IP address of the other AX, to use for
session synchronization.
584 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following command configures the floating IP address for the real servers to use as their default gateway address.
The following commands configure a health method, real servers, a server

group, and a VIP for an HTTP service.
Commands on AX2
Here are the commands for implementing HA on AX2. Most of the commands are the same as those on AX1, with the following exceptions:
The IP interfaces are different.
The HA ID is 2.
The HA priority is 1.
The session synchronization (conn-mirror) IP address is the address of

AX1. (On AX1, the session synchronization IP address is the address of
AX2.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
585 of 950

AX2(config)#interface ethernet 1
AX2(config-if:ethernet5)#exit
AX2(config)#vlan 100
AX2(config-vlan:100)#untagged ethernet 1 to 4
AX2(config)#vlan 5
AX2(config-vlan:5)#untagged ethernet 5
AX2(config)#interface ve1
AX2(config-if:ve1)#interface ve5
AX2(config-if:ve5)#exit
AX2(config)#ha id 2
AX2(config)#ha l3-inline-mode
586 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
587 of 950

Configuring Optional Failover Triggers

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

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

other sections in this chapter.
VLAN-Based Failover Example

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

1. Select Config > HA > Setting > HA Global.
2. In the Status Check section, enter the VLAN ID in the VLAN ID field.
3. Enter the timeout in the Timeout field.
The timeout can be 2-600 seconds. You must specify the timeout.
Although there is no default, A10 recommends trying 30 seconds.
4. Click Add.
5. Repeat step 2 through step 4 for each VLAN to be monitored for HA.
6. Click OK.
588 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

To enable HA checking for a VLAN, use the following command at the
[no] ha check vlan vlan-id timeout seconds
The timeout can be 2-600 seconds. You must specify the timeout. Although
there is no default, A10 recommends trying 30 seconds.
The following command enables VLAN-based failover for VLAN 10 and
sets the timeout to 30 seconds:
AX(config)#ha check vlan 10 timeout 30
Gateway-Based Failover Example

To configure gateway-based failover, use either of the following methods.
(For a description of the feature, see Gateway-based Failover on
page 548.)
USING THE GUI

1. Configure a health monitor that uses the ICMP method:
a. Select Config > Service > Health Monitor.
b. Select Health Monitor on the menu bar.
c. Click Add.
d. In the Health Monitor section, enter a name for the monitor.
e. In the Method section, select ICMP from the Type drop-down list.
f. Click OK.
2. Configure the gateway as an SLB real server and apply the ICMP health
monitor to the server:
c. Click Add. The General section appears.
d. In the General section, enter a name for the gateway in the Name
field.
e. In the IP Address field, enter the IP address of the gateway.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
589 of 950

f. In the Health Monitor drop-down list, select the ICMP health monitor you configured in step 1.
g. Click OK.
3. Enable gateway-based failover:
a. Select Config > HA > Setting > HA Global.
b. In the Status Check section, enter the IP address of the gateway in
the IP Address field.
c. Click Add.
d. Repeat step b and step c for each gateway to be monitored for HA.
e. Click OK.
USING THE CLI

1. To configure a health monitor for a gateway, use the following commands.
[no] method icmp
Enter this command at the configuration level for the health monitor.
2. To configure the gateway as an SLB real server and apply the health
monitor to the server, use the following command.
[no] slb server server-name ipaddr
3. To enable HA health checking for the gateway, use the following command at the global configuration level.
[no] ha check gateway ipaddr
CLI Example
The following commands configure an ICMP health method:
AX(config)#health monitor gatewayhm1
AX(config-health:monitor)#method icmp
590 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following commands configure a real server for the gateway and apply
the health monitor to it:
AX(config)#slb server gateway1 10.10.10.1
AX(config-real server)#health-check gatewayhm1
The following command enables HA health checking for the gateway:

AX(config)#ha check gateway 10.10.10.1
Route-Based Failover Example

You can configure HA route awareness for IPv4 routes and IPv6 routes.
Note:
HA Route Awareness for IPv4 Routes

To configure HA route awareness for an IPv4 route, use the following command at the global configuration level of the CLI:
[no] ha check route destination-ipaddr /mask-length
[gateway ipaddr]
[distance num]
The destination-ipaddr /mask-length option specifies the destination IPv4
subnet of the route.
The priority-cost weight option specifies the value to subtract from the HA
priority of each HA group, if the IP route table does not have a route to the
destination subnet.
The gateway addr option specifies the next-hop gateway for the route.
The protocol option specifies the source of the route:
static The route was added by an administrator.
dynamic The route was added by a routing protocol. (This includes
redistributed routes.)
The distance num option specifies the metric value (cost) of the route.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
591 of 950

Omitting an optional parameter matches on all routes. For example, if you
do not specify the next-hop gateway, routes that match based on the other
parameters can have any next-hop gateway.
HA Route Awareness for IPv6 Routes
To configure HA route awareness for an IPv6 route, use the following command at the global configuration level of the CLI:
[no] ha check route
destination-ipv6addr/mask-length
[gateway ipv6addr]
[distance num]
The destination-ipv6addr/mask-length option specifies the destination IPv6
address. The other options are the same as those for IPv4 routes. (See
above.)
CLI Examples
The following command configures HA route awareness for a default IPv4
route. If this route is not in the IP route table, 255 is subtracted from the HA
priority of all HA groups.
AX(config)#ha check route 0.0.0.0 /0 priority-cost 255
Note:
The lowest possible HA priority value is 1. Deleting 255 sets the HA priority value to 1, regardless of the original priority value.
The following command configures HA route awareness for a dynamic
route to subnet 10.10.10.x with route cost 10. If the IP route table does not
have a dynamic route to this destination with the specified cost, 10 is subtracted from the HA priority value for each HA group.
AX(config)#ha check route 10.10.10.0 /24 priority-cost 10 protocol dynamic distance 10
The following commands configure HA route awareness for an IPv6 route

to 3000::/64. Based on the combination of these commands, if the IPv6
route table does not contain any routes to the destination, 105 is subtracted
from the HA priority of each HA group.
If the IPv6 route table does contain a static route to the destination, but the
next-hop gateway is not 2001::1, the AX device subtracts only 5 from the
HA priority of each HA group.
AX(config)#ha check route 3000::/64 priority-cost 100
AX(config)#ha check route 3000::/64 priority-cost 5 protocol static gateway
2001::1
592 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

VIP-Based Failover Example

To configure VIP-based failover, use either of the following methods.
These procedures apply specifically to the VIP-based failover parameters.
You also need to configure HA global and interface parameters. See Configuring Global HA Parameters on page 565 and Configuring HA Interfaces on page 566.
(For a description of the feature, see VIP-based Failover on page 550.)
USING THE GUI

To configure VIP-based failover on a virtual server:
1. Configure HA global and interface parameters, if you have not already
done so.
4. Click on the virtual server name or click Add to create a new one.
5. Select the HA group from the HA Group drop-down list.
The Dynamic Server Weight field appears.
If the HA Group drop-down list does not have any group IDs, you still
need to configure global HA parameters. See Configuring Global HA
Parameters on page 565.
Note:
6. Enter other parameters if needed (for example, the name, IP address,

and virtual service ports).
7. Click OK.
USING THE CLI

To configure VIP-based failover, use the following commands:
Enter this command at the configuration level for a virtual server, to assign
the virtual server to the HA group. The group-id can be 1-31.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
593 of 950

Enter this command at the configuration level for the virtual server to
enable VIP-based failover. The server-weight specifies the amount to subtract from the HA group's priority value for each real server that becomes
unavailable. The weight can be 1-255. The default is 1.
CLI Example
The following command configures HA group 6 on AX-1 and assigns priority 100 to the group:
The following command enables HA pre-emption. HA pre-emption must be

enabled in order for failover to occur based on HA group priority changes.
The following command configures a floating IP address and assigns it to

HA group 6:
The following commands assign virtual server VIP2 to HA group 6 and

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

for HA group 6 is set to 80. The server weight for HA group 6 on VIP2 is
set to 10, the same weight value set on AX-1. Up to 2 real servers bound to
VIP2 can become unavailable on AX-1 without triggering a failover. However, if a third real server becomes unavailable, the priority of HA group 6 is
reduced to 70, which is lower than the priority value set on AX-2 for the
group. In this case, a failover does occur for VIP2.
AX-2(config)#slb virtual VIP2 192.168.10.22
AX-2(config-slb virtual server)#ha-group 6
AX-2(config-slb virtual server)#ha-dynamic 10
594 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Forcing Active Groups to Change to Standby Status
Forcing Active Groups to Change to Standby Status

To force HA groups to change from Active to Standby status, use the following command at the global configuration level of the CLI:
[no] ha force-self-standby [group-id]
If you specify a group ID, only the specified group is forced to change from
Active to Standby. If you do not specify a group ID, all Active groups are
forced to change to Standby status.
CLI Example
The following command forces HA group 1 to change from Active to
Standby status:
AX(config)#ha force-self-standby 1
Enabling Session Synchronization

Session synchronization backs up live client sessions on the Backup AX
device.
To enable session synchronization:
Globally enable the feature, specifying the IP address of the other AX
device in the HA pair.

Enable the feature on individual virtual ports. Session synchronization is
supported for Layer 4 sessions.

HA session synchronization is required for persistent sessions (source-IP
persistence, and so on), and is therefore automatically enabled for these
sessions by the AX device. Persistent sessions are synchronized even if
session synchronization is disabled in the configuration.
Note:
USING THE GUI

To globally enable the feature:
2. On the menu bar, select HA Global.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
595 of 950

Enabling Session Synchronization
3. In the Mirror IP Address field, enter the IP address of the other AX
device in the HA pair.
4. Click OK or Apply.
To enable the feature on individual virtual ports:
1. Select Config > Service > Server.
4. On the Port tab, select the port and click Edit.
5. Select Enabled next to HA Connection Mirror.
Note:
If the HA Connection Mirror option is not displayed, session synchronization is not supported for this service type.
6. Click OK to redisplay the Port tab.
7. Click OK again.
USING THE CLI

To globally enable session synchronization, use the following command at
[no] ha conn-mirror ip ipaddr
The ipaddr must be an IP address on the other AX device.
To enable session synchronization on a virtual port, use the following command at the configuration level for the port:
[no] ha-conn-mirror
CLI Example
The following command sets the session synchronization address to
10.10.10.66, the IP address of the other AX in this HA pair:
AX(config)#ha conn-mirror ip 10.10.10.66
The following commands access the configuration level for a virtual port
and enable connection mirroring on the port:
596 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring OSPF-Related HA Parameters
AX(config-slb virtual server-slb virtua...)#ha-conn-mirror
Configuring OSPF-Related HA Parameters

The following sections describe how to configure OSPF-related HA parameters.
OSPF Awareness of HA
The AX device uses HA-aware VIPs, floating IPs, IP NAT pools, and IP
range lists with route redistribution to achieve HA-aware dynamic routing.
However, by default, the OSPF protocol on the AX device is not aware of
the HA state (Active or Standby) of the AX device. Consequently, following
HA failover of an AX device, other OSPF routers might continue forwarding traffic to the Standby AX device (the former Active AX device), instead
of the new Active AX device.
In Layer 3 inline mode, all VLANs on the AX device participate in OSPF
routing by default. (See OSPF Support on Standby AX in Layer 3 Inline
Mode on page 598.)
Note:
You can assign an additional cost to an AX devices OSPF interfaces when

the HA status for any group on the device is Standby. If failover of one or
more HA groups from Active to Standby occurs, the AX device does the
following:
Updates the cost of all its OSPF interfaces
Sends Link-State Advertisement (LSA) updates to its OSPF neighbors
advertising the interface cost change

After an OSPF neighbor receives the LSA update, the neighbor updates its
OSPF link-state database with the increased cost of the links. The increased
cost biases route selection away from paths that use the Standby AX device.
Similarly, if a failover results in HA status Active for all HA groups on an
AX device, the device removes the additional cost added for Standby status
from all its OSPF interfaces and sends LSA updates to advertise the change.
The reduced cost biases route selection toward paths that use the Active AX
device and away from paths that use the Standby AX device.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
597 of 950

Synchronizing Configuration Information
Note:
The additional cost for Standby status is removed only if the HA status for
all HA groups on the device is Active. Otherwise, if the status of any of
the groups is Standby, the additional cost remains in effect for all OSPF
interfaces on the device.
Enabling OSPF Awareness of HA
To enable OSPF awareness of HA, use the following command at the OSPF
configuration level.
[no] ha-standby-extra-cost num
The num option specifies the extra cost to add to the AX devices OSPF
interfaces, if the HA status of one or more of the devices HA groups is
Standby. You can specify 1-65535. If the resulting cost value is more than
65535, the cost is set to 65535.
Enter the command on each of the AX devices in the HA pair.
OSPF Support on Standby AX in Layer 3 Inline Mode

In HA Layer 3 inline mode deployments, OSPF adjacencies are automatically formed between the Active and Standby AX devices and all OSPF
routers on all VLANs.
To limit OSPF adjacency formation to a specific VLAN only, explicitly
configure adjacency formation for that VLAN. In this case, OSPF adjacency formation does not occur for any other VLANs. Use the following
ha ospf-inline vlan vlan-id

You can use config-sync options to synchronize some or all of the following:
Startup-config, to the other AX devices startup-config or running-con-
fig
Running-config, to the other AX devices running-config or startup-con-
fig)
598 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Data files:
SSL certificates and private-key files
aFleX files
External health check files
Black/white-list files
Requirements
Session synchronization (connection mirroring) is required for config sync.
Config sync uses the session synchronization link. To enable session synchronization, see Enabling Session Synchronization on page 595.
SSH management access must be enabled on both ends of the link. (See
Securing Admin Access by Ethernet on page 677.)
Configuration Items That Are Backed Up

The following configuration items are backed up during HA configuration
synchronization:
Admin accounts and settings
Floating IP addresses
IP NAT configuration
Access control lists (ACLs)
Health monitors
Policy-based SLB (black/white lists)
SLB
FWLB
GSLB
Data Files:
aFleX files
External health check files
SSL certificate and private-key files
Black/white-list files
Note:
b y
For IP NAT configuration items to be backed up, you must specify an HA

group ID as part of the NAT configuration.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
599 of 950

Configuration Items That Are Not Backed Up

The following configuration items are not backed up during HA configuration synchronization:
Management access settings (the ones described in Securing Admin
Access by Ethernet on page 677)

AX Hostname
MAC addresses
Management IP addresses
Trunks or VLANs
Interface settings
OSPF or RIP settings
ARP entries or settings
Reload of the Target AX Device

In certain cases, the target AX device is automatically reloaded, but in other
cases, reload is either optional or is not allowed.
Table 15 lists the cases in which reload is automatic, optional, or not
allowed.
TABLE 15 Reload of Target AX Device After Config-Sync
Admin Role
Root or Super User
(Read-Write)
Status of Target AX1

Standby
Active
Partition Write
Standby
Active
Target Config
startup-config
running-config
startup-config
running-config
startup-config
running-config
startup-config
running-config
Reload?
Automatic
Automatic
Optional2
Not reloaded by default
Automatic
Not Allowed
Not Allowed
Not Allowed
Not Allowed
1. Active means the AX device is currently the active device for at least one HA group.
2. If the target AX device is not reloaded, the GUI Save button on the Standby AX device does not blink to indicate
unsaved changes. It is recommended to save the configuration if required to keep the running-config before the next
reboot.
600 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

An admin who is logged on with Root or Read-Write (Super Admin) privileges can synchronize for all Role-Based Administration (RBA) partitions
or for a specific partition.
An admin who is logged on with Partition Write privileges can synchronize
only for the partition to which the admin is assigned, and can only synchronize to the startup-config on the other device. The with-reload and to-running-config options are not available to Partition Write admins.
Caveats
Before synchronizing the Active and Standby AX devices, verify that both
are running the same software version. HA configuration synchronization
between two different software versions is not recommended, since some
configuration commands in the newer version might not be supported in the
older version.
The HA configuration synchronization process does not check user privileges on the Standby AX device and will synchronize to it using read-only
privileges. However, you must be logged onto the Active AX with configuration (read-write) access.
If the configuration includes Policy-based SLB (black/white lists), the time
it takes for synchronization depends on the size of the black/white-list file.
This is because the synchronization process is blocked until the files are
transferred from active to standby.
Do not make other configuration changes to the Active or Standby AX
device during synchronization.
Data that is synchronized from a Standby AX device to an Active AX
device is not available on the Active AX device until that device is rebooted
or the software is reloaded.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
601 of 950

Performing HA Synchronization
To synchronize the AX devices in an HA configuration, use the CLI commands described below.
USING THE GUI

1. Select Config > HA > Config Sync.
2. In the User and Password fields, enter the admin username and password for logging onto the other AX device.
3. If Role-Based Administration (RBA) is configured on the AX device,
select whether to synchronize all partitions or only the currently selected
partition. (For information, see Synchronizing the Configuration on
page 812.)
4. Next to Operation, select the information to be copied to the other AX
device:
All Copies all the following to the other AX device:
Floating IP addresses
IP NAT configuration
Access control lists (ACLs)
Health monitors
Policy-based SLB (black/white lists)
SLB
FWLB
GSLB
Data files (see below)
The items listed above that appear in the configuration file are copied to the other AX devices running-config.
Data Files Copies only the SSL certificates and private-key files,
aFleX files, External health heck files, and black/white-list files to
the other AX device
Running-config Copies everything listed for the All option, except
the data files, from this AX devices running-config
Startup-config Copies everything listed for the All option, except
the data files, from this AX devices startup-config
5. Next to Peer Option, select the target for the synchronization:
To Running-config Copies the items selected in step 4 to the other
AX devices running-config
To Startup-config Copies the items selected in step 4 to the other
AX devices startup-config
602 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

6. To reload the other AX device after synchronization, select With
Reload. Otherwise, the other AX device is not reloaded following the
synchronization.
In some cases, reload of the other AX device either is automatic or is not
allowed. See Table 15 on page 600.
Note:
7. Click OK.
USING THE CLI

The ha sync commands are available at the global configuration level of the
CLI.
The all-partitions and partition partition-name options are applicable on
AX devices that are configured for Role-Based Administration (RBA).
For information, see Role-Based Administration on page 797.
Note:
To synchronize data files and the running-config, use the following command:
ha sync all
{to-startup-config [with-reload] |
to-running-config}
[all-partitions | partition partition-name]
In some cases, reload of the other AX device either is automatic or is not
allowed. See Table 15 on page 600.
Note:
To synchronize the Active AX devices startup-config to the Standby AX

devices startup-config or running-config, without also synchronizing the
data files, use the following command:
ha sync startup-config
to-running-config}
To synchronize the Active AX devices running-config to the Standby AX
devices running-config or startup-config, without also synchronizing the
data files, use the following command:
ha sync running-config
to-running-config}
To synchronize the data files by copying the Active AX devices data files
to the Standby AX device, use the following command:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
603 of 950

Tip for Ensuring Fast HA Failover
ha sync data-files

You can use health checking of the upstream and downstream routers to
help ensure rapid HA failover.
The time it takes for traffic to reconverge following HA failover can vary
based on the network environment, and depends on the following:
How fast the ARPs (typically, ARPs of the default gateways) are learned
on the newly active AX device

How fast the MAC tables in the devices along the traffic paths are
updated
To help reconvergence occur faster, you can create a real server configuration for each router, and use an ICMP health monitor for checking the health
of the gateways. The health checks keep the ARP entries for the gateway
routers active, which can help to reduce reconvergence time considerably.
In a typical SLB configuration that includes a client-side router and a
server-side router, configure a real server for each router.
To configure health checking of the gateway routers:
1. (Optional) Configure an ICMP health monitor.
For Layer 3 inline deployments, it is recommended to use very short
values (1 second) for the interval and timeout. (For examples of Layer 3
inline HA deployments for TCS, see Transparent Cache Switching on
page 295.)
2. Create an SLB real server configuration for each gateway. If you plan to
use a custom ICMP health monitor (previous step), apply the health
monitor to the server.
Perform these steps on both AX devices in the HA pair.
Note:
604 of 950
The AX device also has an HA gateway health checking feature. This feature also uses ICMP health monitors. However, if you use the HA gateway health checking feature, HA failover is triggered if a gateway fails a
health check. If you use real server configurations instead, as shown in the
following examples, HA failover is not triggered by a failed health check.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

CLI Example IPv4
AX(config-health:monitor)#method icmp interval 1 timeout 1
AX(config)#slb server gateway-upstream 192.168.10.1
AX(config)#slb server gateway-downstream 10.10.10.1
To use the default ICMP health monitor instead, the configuration is even
simpler:
AX(config)#slb server gateway-upstream 192.168.10.1
AX(config)#slb server gateway-downstream 10.10.10.1
CLI Example IPv6

AX(config-health:monitor)#method icmp interval 1 timeout 1
AX(config)#slb server up-router 2309:e90::1
AX(config)#slb server down-router 2309:e90::3
To use the default ICMP health monitor:

AX(config)#slb server up-router 2309:e90::1
AX(config)#slb server down-router 2309:e90::3
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
605 of 950

606 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Network Address Translation

This chapter describes Network Address Translation (NAT) and how to configure it. NAT translates the source or destination IP address of a packet
before forwarding the packet.
The AX device uses NAT to perform SLB. The AX device also supports traditional Layer 3 NAT, which you can configure if required by your network.
Note:
b y
This chapter does not include information about Large-Scale NAT (LSN).
For LSN information, see Large-Scale Network Address Translation on
page 639.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
607 of 950

SLB NAT
SLB NAT
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 160 shows an example.
Note:
Destination NAT is disabled for virtual ports on which Direct Server

Return (DSR) is enabled.
FIGURE 160
608 of 950
SLB NAT
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SLB NAT
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 servers IP
address to the VIP address.
The default SLB NAT behavior does not translate the clients 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 609.)
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 614.)
IP Source NAT Configuration Limits

The AX device supports the following:
NAT pool addresses Maximum of 500 NAT pool addresses supported,
in all NAT pools. For example, you can configure 1 NAT pool containing 500 NAT addresses, or 100 NAT pools containing 5 addresses each,
and so on.
NAT pools Maximum of 100 NAT pools supported.
NAT pool groups Maximum of 50 NAT pool groups supported. Each
NAT pool group can contain up to 5 NAT pools.
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
609 of 950

SLB NAT
Connection reuse requires SLB source NAT. Since the TCP connection with
the real server needs to remain established after a clients session ends, the
clients IP address cannot be used as the source address for the connection,
Instead, the source address must be an IP address from a NAT pool or pool
group configured on the AX device.
The pool or pool group must have a unique IP address for each reusable
TCP connection you want to establish.
To configure connection reuse:
1. Configure a NAT pool or set of pools to specify the IP addresses to use
as source addresses for the reusable connections with the real servers.
To use a single, contiguous range of addresses, only one pool is
needed.
To use a non-contiguous range of addresses, configure a separate
pool for each contiguous portion of the range, then configure a pool
group that contains the pools.
The addresses within an individual pool still must be contiguous,
but you can have gaps between the ending address in one pool and
the starting address in another pool. You also can use pools that are
in different subnets.
A pool group can contain up to 5 pools. Pool group members must
belong to the same protocol family (IPv4 or IPv6) and must use the
same HA ID. A pool can be a member of multiple pool groups. Up
to 50 NAT pool groups are supported.
2. Configure a connection reuse template.
3. If you plan to use policy-based source NAT, to select from among multiple 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 policy-based source NAT, bind each ACL to its pool.
5. Add the connection reuse template to the service port.
Note:
610 of 950
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SLB NAT
USING THE GUI

1. To configure a pool of addresses:
a. Select Config > Service > IP Source NAT.
b. Select IPv4 Pool or IPv6 Pool on the menu bar.
c. Click New. The Pool section appears.
d. Enter a name for the pool.
e. Enter the start and end addresses.
f. Enter the network mask.
g. If the AX device is deployed in transparent mode, enter the default
gateway to use for NATted traffic.
h. To use session synchronization for NAT translations, select the HA
group.
i. Click OK.
2. To configure a connection reuse template:
b. Select Connection Reuse on the menu bar.
c. Click New. The Connection Reuse section appears.
e. Edit the other parameters or leave them at their default settings.
f. Click OK. The template appears in the connection reuse template
table.
3. To enable source NAT on the virtual port:
a. Select Config > Service > Server.
c. Select the virtual server name or click New.
d. If you are adding a new virtual server, enter the general server settings.
e. Click Port.
f. Select the port and click Edit, or click New. The Virtual Server Port
section appears.
g. Enter or select the port settings, if the port is new.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
611 of 950

SLB NAT
h. Do one of the following:
To use a single pool or pool group for all source addresses, select
the pool from the Source NAT pool drop-down list.
To use separate pools based on source addresses, use the
ACL-SNAT Binding fields to bind each ACL to its pool.
For each binding, select the ACL from the Access List dropdown list, select the pool from the Source NAT Pool drop-down
list, and click Add.
i. Do not click OK yet. Go to step 4.
4. To add the connection reuse template to the virtual port:
a. In the Connection Reuse Template drop-down list, select the template.
b. Click OK.
c. Click OK again.
USING THE CLI

1. To configure an IP address pool, use one of the following commands at
the global configuration level of the CLI.
To configure an IPv4 pool:
ip nat pool pool-name start-ipaddr end-ipaddr
netmask {subnet-mask | /mask-length}
[gateway ipaddr] [ha-group-id group-id]

ipv6 nat pool pool-name
start-ipv6-addr end-ipv6-addr
netmask mask-length
To configure a pool group, configure a separate IP pool for each contiguous 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
612 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SLB NAT
This command creates the template and changes the CLI to configuration 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 reusable connections to establish with each real server. You can specify 065535. For unlimited connections, specify 0. The default is 1000.
The timeout command specifies the maximum number of seconds a
reusable connection can remain idle before it times out. You can specify
1-3600 seconds. The default is 2400 seconds (40 minutes).
3. To enable source NAT, do one of the following:
To enable source NAT on the virtual port and use a single pool or
pool group for all source addresses, use the following command at
the configuration level for the virtual port:
source-nat pool {pool-name | pool-group-name}
To enable policy-based source NAT and use separate pools based on
source IP address, use the following command at the configuration
level for the port. This command binds an ACL to its pool:
access-list acl-num source-nat-pool pool-name
If you do not specify a NAT pool with this command, the ACL is used
only to filter the traffic.
Note:
4. Add the connection reuse template to the virtual port, use the following
command at the configuration level for the virtual port:
template connection-reuse template-name
CLI Example
The following commands configure standard ACLs that match on different
client addresses:
AX(config)#access-list 30 permit ip 192.168.1.1
AX(config)#access-list 50 permit ip 192.168.20.69
The following commands configure source NAT pools:

AX(config)#ip nat pool pool1 10.10.10.200 10.10.10.100 netmask /16
ha-group-id 1
ha-group-id 1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
613 of 950

SLB NAT
The following commands configure a real server and a service group:
AX(config)#slb server s1 192.168.19.48
AX(config)#slb service-group group80 tcp
AX(config-slb service group)#method weighted-rr
AX(config-slb service group)#member s1:80
The following commands configure policy-based source NAT, by binding

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

The AX device allows source NAT to be enabled on a virtual port. In cases
where real servers are in a different subnet than the VIP, source NAT
ensures that reply traffic from a server will pass back through the AX
device.
You can enable source NAT on a virtual port in either of the following ways:
Use the the source-nat option to bind a single IP address pool or pool
group to the virtual port. This option is applicable if all the real servers
are in the same subnet.
Use sets of ACL-pool pairs, one for each real server subnet. You must
use this method if the real servers are in multiple subnets. This section
describes how to use this method.
For the real server to be able to send replies back through the AX device,
use an extended ACL. The source IP address must match on the client
address. The destination IP address must match on the real server address.
The action must be permit.
The ACL should not match on the virtual IP address (unless the virtual IP
address is in the same subnet as the real servers, in which case source NAT
is probably not required). Figure 161 on page 615 shows an example.
614 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SLB NAT
FIGURE 161
Multiple NAT Pools Bound to a Virtual Port
In this example, a service group has real servers that are located in two different 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 servers subnet.

An IP address pool or pool group containing translation addresses in the
real servers subnet.

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
615 of 950

SLB NAT
For example, if SLB selects a real server in the 10.10.10.x subnet, then the
source IP address is translated from the clients address to an address in
pool 1. When the server replies, it replies to the address from pool 1.
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.
Note:
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 contains addresses in one of the real server subnets.
The following commands bind the ACLs and IP address pools to a virtual
port on the VIP:
pool1
pool2
Direct Server Return

You can disable destination NAT on a virtual port, to enable Direct Server
Return (DSR). DSR enables a real server to respond to clients directly
instead of going through the AX device. The AX is not required to return
the servers 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.
616 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SLB NAT
When DSR is enabled, only the destination MAC address is translated from
the VIPs MAC address to the real servers IP address. The destination IP
address is still the VIP.
To use DSR, the AX device and the real servers must be in the same Layer 2
subnet. The VIP address must be configured as a loopback address on the
real servers.
To enable DSR on a virtual port, use either of the following methods.
Note:
To configure health checking for DSR, see Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments on page 386.
Note:
For examples of DSR configurations, see Network Setup on page 71.
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 section 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
617 of 950

SLB NAT
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-onvip command is also used, 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, 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 servers
You can enable this feature globally or on individual virtual ports:
To globally configure IP NAT support for VIPs, use the following command
[no] snat-on-vip
618 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
To configure IP NAT support for an individual virtual port, use the command 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
servers IP address, and a default gateway is defined for the pool, the AX
device forwards the server traffic through the pools default gateway.
This feature is disabled by default. To enable it, use the following command
[no] slb snat-gwy-for-l3
IP Source NAT
Independently of SLB NAT, you can configure traditional, Layer 3 IP
source NAT. IP source NAT translates internal host addresses into routable
addresses before sending the hosts traffic to the Internet. When reply traffic
is received, the AX device then retranslates addresses back into internal
addresses before sending the reply to the client.
You can configure dynamic or static IP source NAT:
Dynamic source IP NAT Internal addresses are dynamically translated
into external addresses from a pool.

Static source IP NAT Internal addresses are explicitly mapped to
external addresses.
Configuration Elements for Dynamic NAT
Dynamic NAT uses the following configuration elements:
Access Control List (ACL) to identify the inside host addresses to be
translated
Pool to identify a contiguous range of external addresses into which to
translate inside addresses

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
619 of 950

IP Source NAT
Optionally, pool group to use non-contiguous address ranges. To use a
non-contiguous range of addresses, you can configure separate pools,

then combine them in a pool group and map the ACL to the pool group.
The addresses within an individual pool still must be contiguous, but
you can have gaps between the ending address in one pool and the starting address in another pool. You also can use pools that are in different
subnets.
A pool group can contain up to 5 pools. Pool group members must
belong to the same protocol family (IPv4 or IPv6) and must use the
same HA ID. A pool can be a member of multiple pool groups. Up to 50
NAT pool groups are supported.
If a pool group contains pools in different subnets, the AX device selects
the pool that matches the outbound subnet. For example, of there are
two routes to a given destination, in different subnets, and the pool
group has a pool for one of those subnets, the AX selects the pool that is
in the subnet for the outbound route.
The AX device searches the pools beginning with the first one added to
the group, and selects the first match. If none of the pools are in the destination subnet, the AX uses the first pool that has available addresses.
Inside NAT setting on the interface connected to the inside host.
Outside NAT setting on the interface connected to the Internet. Inside
host addresses are translated into external addresses from a pool before
the host traffic is sent to the Internet.
Note:
The AX device enables you to specify the default gateway for an IP

source NAT pool to use. However, the pools default gateway can be used
only if the data route table already has either a default route or a direct
route to the destination of the NAT traffic. In this case, the pools default
gateway will override the route, for NAT traffic that uses the pool.
If the data route table does not have a default route or a direct route to the
NAT traffic destination, the pools default gateway can not be used. In this
case, the NAT traffic can not reach its destination.
Configuration Elements for Static NAT
Static NAT uses the following configuration elements:
Static mappings or an address range list A static mapping is a one-to-
one mapping of an inside address to an external address. An address

range list is a contiguous range of inside addresses and external
addresses to translate them into.
Inside NAT setting on the interface connected to the inside host.
620 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
Outside NAT setting on the interface connected to the Internet. Inside
host addresses are translated into external addresses from a static mapping or a range list before the host traffic is sent to the Internet.
Configuring Dynamic IP Source NAT

To configure dynamic source NAT:
1. Configure an Access Control List (ACL) to identify the inside addresses
that need to be translated.
2. Configure a pool of external addresses to use for translation. To use noncontiguous ranges of addresses, configure multiple pools and add them
to a pool group.
3. Enable inside source NAT and map the ACL to the pool.
4. Enable inside NAT on the interfaces connected to the inside hosts.
5. Enable outside NAT on the interfaces connected to the Internet.
Note:
In addition, on some AX models, if Layer 2 IP NAT is required, you also

must enable CPU processing on the NAT interfaces. This applies to models AX 2200, AX 3100, AX 3200, AX 5100, and AX 5200. This additional step is performed at the configuration level for each NAT interface.
The procedures below do not include this additional step.
Note:
In step 3, the GUI supports binding IPv4 pools to ACLs but not IPv6
pools. To bind an IPv6 pool to an ACL, use the CLI instead.
USING THE GUI
1. To configure an ACL to identify the inside addresses that need to be

translated:
a. Select Config > Network > ACL.
b. Select the ACL type, Standard or Extended, on the menu bar.
c. Click Add.
d. Enter or select the values to filter.
e. Click OK. The new ACL appears in the Standard ACL table or
Extended ACL table.
f. Click OK to commit the ACL change.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
621 of 950

IP Source NAT
2. To configure a pool of external addresses to use for translation:
a. Select Config > Service > IP Source NAT.
b. Select IPv4 Pool or IPv6 Pool on the menu bar.
c. Click Add.
d. Enter a name for the pool.
e. Enter the start and end addresses.
f. Enter the network mask.
g. If the AX device is deployed in transparent mode, enter the default
gateway to use for NATted traffic.
h. To use session synchronization for NAT translations, select the HA
group.
i. Click OK.
3. To enable inside source NAT and map the ACL to the pool:
a. Select Config > Service > IP Source NAT, if not already selected.
b. Select Binding on the menu bar.
c. Select the ACL number from the ACL drop-down list.
d. Select the pool ID from the NAT Pool drop-down list.
e. Click Add. The new binding appears in the ACL section.
f. Click OK.
4. To enable inside NAT on the interfaces connected to the inside hosts:
a. Select Config > Service > IP Source NAT, if not already selected.
b. Select Interface on the menu bar.
c. Select the interface connected to the internal hosts.
d. In the Direction drop-down list, select Inside.
e. Click Add.
f. Repeat for each interface connected to the internal hosts.
g. Do not click OK yet. Instead, go to the next step.
5. To enable outside NAT on the interfaces connected to the Internet:
a. Select the interface connected to the Internet.
b. In the Direction drop-down list, select Outside.
c. Click Add.
622 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
d. Repeat for each interface connected to the Internet.
e. Click OK.
FIGURE 162
Configure > Network > ACL > Standard ACL
FIGURE 163
Configure > Service > IP Source NAT > IPv4 Pool
FIGURE 164
Configure > Service > IP Source NAT > Binding
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
623 of 950

IP Source NAT
FIGURE 165
Configure > Service > IP Source NAT > Interface
USING THE CLI

1. To configure an ACL to identify the inside addresses that need to be
translated, use either of the following commands at the global configuration level of the CLI.
Use a standard ACL to specify the host IP addresses to translate. All
host addresses that are permitted by the ACL are translated before traffic
is sent to the Internet.
To also specify other information including destination addresses and
source and destination protocol ports, use an extended ACL.
Standard ACL Syntax
access-list acl-num {permit | deny}
source-ipaddr {filter-mask | /mask-length}
Extended ACL Syntax
access-list acl-num {permit | deny} {ip | icmp}
{any | host host-src-ipaddr |
net-src-ipaddr {filter-mask | /mask-length}}
{any | host host-dst-ipaddr |
net-dst-ipaddr {filter-mask | /mask-length}}
624 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
or
access-list acl-num {permit | deny} {tcp | udp}
[eq src-port | gt src-port | lt src-port |
range start-src-port end-src-port]
[eq dst-port | gt dst-port | lt dst-port |
range start-dst-port end-dst-port]
2. To configure a pool of external addresses to use for translation, use one
of the following commands at the global configuration level of the CLI.
[gateway ipaddr]
[ha-group-id group-id [ha-use-all-ports]]
The ha-use-all-ports option applies only to DNS virtual ports. Using this
option with other virtual port types is not valid. (For information about
this option, see the AX Series CLI Reference.)
Note:

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

ip nat pool-group pool-group-name
{pool-name ...}
3. To enable inside source NAT and map the ACL to the pool, use the following command:
ip nat inside source list acl-name
pool {pool-name | pool-group-name}
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
625 of 950

IP Source NAT
4. To enable inside NAT on the interfaces connected to the inside hosts,
interface [ethernet port-num | ve ve-num]
ip nat inside
The interface command changes the CLI to the configuration level for
the interface connected to the internal hosts. These are the hosts identified by the ACL configured in step 1 and used by the commands in
step 2 and step 3.
5. To enable outside NAT on the interfaces connected to the Internet, use
the following commands:
ip nat outside
CLI EXAMPLE
The following commands configure an ACL to specify the internal hosts to
be NATted. In this example, all hosts in the 10.10.10.x subnet are to receive
NAT service for traffic to the Internet.
AX(config)#access-list 1 permit 10.10.10.0 0.0.0.255
The following command configures an IPv4 pool of external addresses to

use for the NAT translations. In this example, 10.10.10.x addresses will be
translated into 192.168.1.1 or 192.168.1.2:
The following command enables inside source NAT and associates the ACL
with the pool:
AX(config)#ip nat inside source list 1 pool pool1
The following commands enable inside source NAT on the interface connected to the internal hosts:
AX(config-if:ethernet4)#ip nat inside
The following commands enable source NAT on the interface connected to

the external hosts:
AX(config-if:ethernet6)#ip nat outside
626 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
Configuring Static IP Source NAT

You can configure individual static source NAT mappings or configure a
range of static mappings.
After configuring the static source NAT mappings, do the following:
Enable inside NAT on the interfaces connected to the inside hosts.
Enable outside NAT on the interfaces connected to the Internet.
Limitations for Static NAT Mappings

Application Layer Gateway (ALG) services other than FTP are not sup-
ported when the server is on the inside.

HA session synchronization is not supported. However, sessions will
not be interrupted by HA failovers.

Syn-cookies are not supported.
USING THE GUI

The GUI supports configuring a static NAT range but does not support
configuring individual mappings.
Note:
1. To configure the static translations of internal host addresses to external

addresses:
a. Select NAT Range on the menu bar.
b. Click Add.
c. Enter a name for the range.
d. Select the address type (IPv4 or IPv6)
e. In the From fields, enter the first (lowest numbered) address and
network mask in the range of inside host addresses to be translated.
f. In the To field, enter the first (lowest numbered) address and network mask in the range of external addresses into which to translate
the inside host addresses.
g. In the Count field, enter the number of addresses to be translated.
h. To apply HA to the addresses, select the HA group.
i. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
627 of 950

IP Source NAT
2. To enable inside NAT on the interfaces connected to the inside hosts:
a. Select Interface on the menu bar.
b. Select the interface from the Interface drop-down list.
c. Select Inside in the Direction drop-down list.
d. Click OK.
e. Repeat for each inside interface.
3. To enable outside NAT on the interfaces connected to the Internet:
a. Select Interface on the menu bar.
b. Select the interface from the Interface drop-down list.
c. Select Outside in the Direction drop-down list.
d. Click OK.
e. Repeat for each outside interface.
USING THE CLI

1. To configure the external addresses to use for translation, use one of the
following commands.
To configure individual address mappings, use the following command
to configure each mapping:
ip nat inside source
static source-ipaddr nat-ipaddr
[ha-group-id group-id]
The source-ipaddr is the internal host that will send requests. The natipaddr is the address into which the AX device will translate the sourceipaddr before forwarding the requests.
Similarly, for inbound static NAT, the following syntax is supported:
[no] ip nat inside source static destinationipaddr nat-ipaddr
The destination-ipaddr is the internal host to which external hosts send
requests. The nat-ipaddr is the address into which the AX device will
translate the destination-ipaddr before forwarding the requests.
To configure a range list to use for static mappings:
ip nat range-list list-name
source-ipaddr /mask-length
nat-ipaddr /mask-length
count number [ha-group-id group-id]
628 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

ip nat inside
The interface command changes the CLI to the configuration level for
the interface connected to the internal hosts.
4. To enable outside NAT on the interfaces connected to the Internet, use
the following commands:
ip nat outside
CLI EXAMPLE
The following commands enable static NAT, configure an IP address range
named nat-list-1 that maps up to 100 local addresses starting from
10.10.10.97 to Internet addresses starting from 192.168.22.50, set Ethernet
interface 2 as the inside NAT interface, and set Ethernet interface 4 as the
outside NAT interface.
AX(config)#ip nat range-list nat-list-1 10.10.10.97 /16 192.168.22.50 /16 count
100
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
629 of 950

IP Source NAT
NAT ALG Support for PPTP

NAT Application Layer Gateway (ALG) support for the Point-to-Point Tunneling Protocol (PPTP) enables clients and servers to exchange Point-toPoint (PPP) traffic through the AX device over a Generic Routing Encapsulation (GRE) tunnel.
PPTP is used to connect Microsoft Virtual Private Network (VPN) clients
and VPN hosts. Figure 166 shows an example.
FIGURE 166
NAT ALG for PPTP
The AX device is deployed between PPTP clients and the VPN server (VPN
Server using PPTP). The AX interface connected to the PPTP clients is
enabled for inside source NAT. The AX interface connected to the VPN
server is enabled for outside source NAT.
Each client runs a PPTP Network Server (PNS). To set up a VPN session,
the PNS sends an Outgoing-Call-Request to the PPTP Access Concentrator
(PAC), which is the VPN server. The destination TCP port is the PPTP port
(1723 by default). The request includes a Call ID that the PNS chooses.
Because multiple clients may share the same NAT address, the AX device
must ensure that clients do not share the same Call ID as well. Therefore,
the AX device assigns to each client a NAT Call ID (analogous to a NAT
source port for TCP) and modifies the Outgoing-Call-Request to use the
NAT Call ID instead.
The PAC replies to the Outgoing-Call-Request with a Call ID of its own.
This is like a TCP destination port. The AX device does not change the
630 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
PACs Call ID. The PAC then assigns to the client an IP address belonging
to the VPN subnet.
On the AX device, the GRE session is created after the PNS sends its reply.
In the GRE session, the Call ID is used as the Layer 4 port, instead of a
TCP/UDP port number. (See the example of show session output in CLI
Example on page 633.)
In Figure 166 on page 630, client (PNS) 10.1.1.1 wants to connect to a VPN
through the VPN Server (PAC) 10.3.3.2, which is using PPTP. Client
10.1.1.1 establishes a PPTP control session (on port 1723) with 10.3.3.2.
When the client sends the Outgoing-Call-Request over that TCP session
with its desired Call ID, the AX device will translate the Call ID into a
unique Call ID for NAT. Once the VPN server replies with its own Call ID,
the AX device will establish the GRE session.
After the Call IDs are exchanged, the client and server encapsulate VPN
subnet traffic in a GRE tunnel. The GRE tunnel packets are sent under normal IP between 10.1.1.1 and 10.3.3.2. A GRE packet for PPTP uses a Call
ID in the same way as a TCP or UDP destination port. Therefore, GRE
packets from the server (10.3.3.2) will use the NAT Call ID. The AX device
translates the NAT Call ID back into the clients original Call ID before
sending the packet to the client.
One GRE session is supported per control session, which means one call
at a time is supported. In practice, PPTP is used only for VPNs, in which
case multiple concurrent calls do not occur.
Note:
Configuring NAT ALG for PPTP

To configure an AX device to support NAT ALG for PPTP:
Configure dynamic IP source NAT:
Configure an ACL that matches on the PPTP client subnet(s).
Configure an IP source NAT pool that contains the range of IP
addresses into which to translate client addresses.

Configure an inside source NAT list, using the ACL and pool.
Enable inside IP source NAT on the AX interface connected to the
VPN clients.
Enable outside IP source NAT on the AX interface connected to the
VPN server.
If NAT ALG support for PPTP is disabled, enable it. (The feature is
enabled by default.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
631 of 950

IP Source NAT
Note:
In the current release, NAT ALG support for PPTP is not supported with
static NAT or NAT range lists.
Note:
In the current release, NAT ALG support for PPTP can not be disabled or
re-enabled using the GUI.
USING THE CLI

To configure dynamic IP source NAT, use the following commands.
First, to configure the ACL, use the following command at the global configuration level of the CLI:
access-list acl-num permit
Note:
The ACL must permit IP traffic. The syntax above is for a standard ACL.
If you plan to use an extended ACL instead, make sure to use the ip
option, instead of icmp, tcp, or udp.
To configure the IP address pool, use the following command at the global
To configure an IP source NAT list, use the following command at the
ip nat inside source list acl-name
pool {pool-name | pool-group-name}
To enable inside source NAT on an interface, use the following command at
the configuration level for the interface:
[no] ip nat inside
To enable outside source NAT on an interface, use the following command
at the configuration level for the interface:
[no] ip nat outside
To enable or disable NAT ALG support for PPTP, use the following command at the global configuration level of the CLI:
ip nat alg pptp {enable | disable}
The feature is enabled by default. The default protocol port number is 1723
and can not be changed.
632 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
To display GRE sessions, use the following commands:
show session
To display or clear statistics, use the following commands:
show ip nat alg pptp statistics
clear ip nat alg pptp statistics
CLI Example
The commands in this section implement the NAT ALG for PPTP configuration shown in Figure 166 on page 630.
The following commands configure dynamic inside source NAT.
AX(config)#access-list 1 permit 10.1.1.0 0.0.0.255
AX(config)#ip nat pool pptp-pool 192.168.1.100 192.168.1.110 netmask /24
AX(config)#ip nat inside source list 1 pool pptp-pool
The following commands specify the inside NAT interface and the outside
NAT interface.
The following command displays session information:

AX(config-if:ethernet2)#show session
Prot Forward Source
Age Hash
Forward Dest
Reverse Source
Reverse Dest
---------------------------------------------------------------------------------------------------------Gre 10.1.1.1:49152
240 1
10.3.3.2:32799
10.3.3.2:32799
192.168.1.100:2109
Tcp 10.1.1.1:2301
240 2
10.3.3.2:1723
10.3.3.2:1723
192.168.1.100:2109
This example shows the GRE session and the TCP session over which the
GRE session is transported. For the GRE session, the number following
each IP address is the PPTP Call ID. For the TCP session, the number is the
TCP protocol port.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
633 of 950

IP Source NAT
The following command displays PPTP NAT ALG statistics.
AX(config-if:ethernet2)#show ip nat alg pptp statistics
Statistics for PPTP NAT ALG:
----------------------------Calls In Progress:
10
Call Creation Failure:
Truncated PNS Message:
Truncated PAC Message:
Mismatched PNS Call ID:
Mismatched PAC Call ID:
Retransmitted PAC Message:
Truncated GRE Packets:
Unknown GRE Packets:
No Matching Session Drops:
Fast Aging for IP NATted ICMP and DNS Sessions

The AX device uses application-aware aging for IP NATted sessions, in
cases where the AX device performs IP NAT translation of the internal client IP addresses.
The default timeout for IP NATted ICMP sessions, as well as UDP sessions
on port 53 (DNS), is set to the SLB maximum session life (MSL), which is
2 seconds by default.
Note:
634 of 950
Fast aging applies to sessions between internal clients and external

resources, in cases where the AX device performs IP NAT translation of
the client addresses. This type of traffic is not SLB traffic between clients
and a VIP configured on the AX device. For SLB DNS traffic, short aging
based on the MSL time is the default aging mechanism.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
Table 16 summarizes the session timeouts and how to configure them.
TABLE 16 Session Timeout for IP NATted ICMP and UDP Sessions
Default Timeout for IP NATted ICMP DNS
Sessions
SLB MSL timeout (2 seconds by default)
Note: For DNS, this is the default only for the default
DNS port (53).
Method To Change Timeout

You can use either of the following methods:
Change the SLB MSL timeout.
Change the IP NAT translation timeout:
ICMP Change the IP NAT translation ICMP
timeout, by specifying the number of seconds for
the timeout, instead of fast.
DNS Change the IP NAT translation UDP timeout for the DNS port, by specifying the number of
seconds for the timeout, instead of fast. The
timeout is configurable for individual UDP ports.
USING THE CLI

To display the timeout that will be used for IP NATted sessions, use the following command:
show ip nat timeouts
To change the IP NAT translation timeout for ICMP, use the following command:
[no] ip nat translation icmp-timeout
{seconds | fast}
To change the IP NAT translation timeout for a UDP port, use the following
command:
[no] ip nat translation service-timeout
udp port-num {seconds | fast}
The port-num option specifies the UDP port number. The fast option sets
the timeout to the SLB MSL timeout, for the specified UDP port.
CLI Example
The following command displays the current IP NAT translation timeouts:
AX#show ip nat timeouts
NAT Timeout values in seconds:
SYN
TCP
UDP
ICMP
-----------------------60
300
300
fast
Service 53/udp has fast-aging configured

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
635 of 950

IP Source NAT
In this example, the output indicates that fast aging is used for IP NATted
ICMP sessions, and for IP NATted DNS sessions on port 53.
The message at the bottom of the display indicates that the fast aging setting
(SLB MSL timeout) will be used for IP NATted UDP sessions on port 53. If
the message is not shown in the output, then the timeout shown under
UDP will be used instead.
Client and Server TCP Resets for NATted TCP Sessions

By default, the AX device does not send TCP Resets to the client and server
when a NATted TCP session becomes idle. To enable this option, use the
following command at the global configuration level of the CLI:
ip nat reset-idle-tcp-conn
Requirements for Translation of DNS Traffic

If you plan to use IP NAT for DNS traffic, make sure the configuration
includes the following:
Both the DNS request from the inside client, and the response from the
external DNS server, must pass through the IP NAT outside interface.
If an ACL is configured on the interface that will receive the DNS
responses (the IP NAT outside interface), the ACL must include a permit rule that allows traffic from the DNS server. Otherwise, the traffic
will be denied by the implicit (non-visible) deny any any rule at the end
of the ACL.
IP NAT Use in Transparent Mode in Multi-Netted Environment

If the AX device is deployed in transparent mode, the device uses NAT IP
addresses to perform health monitoring on servers that are outside the IP
subnet or VLAN of the AX device. If there are multiple IP addresses in the
NAT pool, the AX device uses only the last IP address in the pool for the
health checks. Also, the AX device only responds to control traffic (for
example, management and ICMP traffic) on the last IP address in the pool.
In the following example, the AX devices IP address is on the
172.168.101.0/24 subnet. A NAT pool has been configured to reach servers
outside of that subnet/VLAN.
636 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Source NAT
AX#show ip
System is running in Transparent Mode
IP address:
172.168.101.4 255.255.255.0
IP Gateway address:
172.168.101.251
SMTP Server address:
Not configured
AX#show ip nat pool

Total IP NAT Pools: 4
Pool Name
Start Address
End Address
Mask
Gateway
HA Group
---------------------------------------------------------------------------Pool-A
173.168.10.20
173.168.10.25
/24
173.168.10.250 0
In this configuration, the AX device will initiate health checks using the last
IP address in the pool as the source IP address. In this example, the AX
device will use IP address 173.168.10.25. In addition, the AX device will
only respond to control traffic directed to 173.168.10.25 from the
173.168.10.0/24 subnet.
NAT Range List Requires AX Interface or Route Within the Global

Subnet
In an IP source NAT configuration, return UDP or ICMP traffic may not be
able to reach the AX device. This can occur under the following circumstances:
IP source NAT is configured using a NAT range list.
The AX device does not have any data interfaces or routes that contain
an address within the subnet of the range list's global address(es).

To work around this issue, configure an IP interface that is within the NAT
range lists global subnet. You can configure the address on any active data
interface on the AX device.
This issue does not affect NATted traffic other than ICMP or UDP traffic, or
use of an ACL with a NAT pool.
IP NAT in HA Configurations
If you are using IP source NAT or full NAT in an HA configuration, make
sure to add the NAT pool or range list to an HA group. Doing so allows a
newly Active AX device to properly continue management of NAT
resources following a failover.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
637 of 950

IP Source NAT
USING THE GUI

In the GUI, you can select the HA group from the HA Group drop-down list
on the following configuration tabs:
Config > Service > IP Source NAT > NAT Range
USING THE CLI

In the CLI, the ha-group-id option is supported with the following NAT
commands:
[no] ip nat pool pool-name start-ipaddr end-ipaddr
netmask {subnet-mask | /mask-length} [gateway ipaddr]
[no] ipv6 nat pool pool-name start-ipv6-addr
end-ipv6-addr netmask mask-length [gateway ipaddr]
[no] ip nat range-list list-name
source-ipaddr
/mask-length
nat-ipaddr
count number [ha-group-id group-id]
638 of 950
b y
/mask-length
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Large-Scale Network Address Translation

This chapter describes Large-scale Network Address Translation (LSN) and
The A10 Networks implementation of LSN conforms to the following
RFCs:
draft-nishitani-cgn-02 This is the main RFC for LSN.
RFC 4787 Network Address Translation (NAT) Behavioral Require-
ments for Unicast UDP

RFC 5382 NAT Behavioral Requirements for TCP
RFC 5508 NAT Behavioral Requirements for ICMP
Note:
LSN is supported only on the 64-bit ACOS models: AX 2500, AX 2600,

AX 3000, AX 5100, and AX 5200.
Note:
The current release provides Application Layer Gateway (ALG) support

for FTP only.
Note:
LSN requires the new-path processing option. This option was

enabled by default in AX Release 2.5.0 (the Beta release for LSN) but
is disabled by default in the current release. New-path processing is
required for LSN and applies only to LSN. The option does not apply to
any other features. (To enable the option, see step 7 in Configuring
Large-Scale NAT on page 655.)
Overview
LSN provides robust NAT support for network carriers (also called Internet Service Providers or ISPs). Carriers can use LSN to provide NAT
service for multiple enterprises and residential clients. Figure 167 shows an
example of a carrier using LSN to provide NAT to residential clients.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
639 of 950

Overview
FIGURE 167
Large-Scale NAT
The carriers clients are on an internal subnet, 5.5.5.x/24, in the carriers

network. When a client sends a request, the AX device running LSN creates
a mapping of the clients internal address and protocol port to a public
address and protocol port. In this example, LSN creates the following mapping:
Client Internal Address
5.5.5.1:65535
640 of 950
Client Public Address

192.168.1.1:65535
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Although subnets 10.x.x.x and 192.168.1.x are private subnets, the examples in this section use them as public subnets.
Note:
After LSN creates an IP address mapping for a client, LSN uses the same
mapping for all traffic between the client and any external IP address. For
example, if client 5.5.5.1 opens multiple HTTP sessions and an email session, LSN uses the same external IP address for the client for all the sessions, as shown in Figure 168.
FIGURE 168
b y
LSN Address Mapping
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
641 of 950

Overview
NAT Data Session Aging
The clients data session remains in effect until the AX device detects that
the session has ended or until the session ages out due to inactivity.
For a TCP session, the data session is removed when the AX device
observes the FIN messages exchanged by the two end points of the session. If the AX device does not observe the FIN exchange but the session is idle, the mapping is removed when the session ages out.
For a UDP session, the data session is removed when the session ages
out.
For an ICMP session, the data session ends when the ICMP reply is
received, or when the session ages out.

NAT session aging is individually configurable for TCP, UDP, and ICMP,
using the ip nat translation command.
tcp-timeout Configurable to 60-1500 seconds. The default is 300 sec-
onds.
udp-timeout Configurable to 60-1500 seconds. The default is 300
seconds.
icmp-timeout Configurable to 60-1500 seconds, or fast. The fast
option uses the SLB maximum session life (MSL), which is 2 seconds
by default. The default is fast.
Optionally, static mappings can be configured. A static mapping never ages
out.
NAT Mapping Removal and Full-Cone Behavior
When a NAT data session is removed, removal of the NAT mapping used by
the data session depends on whether full-cone behavior is present:
If full-cone behavior is not present, the NAT mapping is removed when
the data session is removed.

If full-cone behavior is present, the NAT mapping remains in effect until
all the data session that use the mapping a removed. For example, if a
client uses source port 50000 to connect to two different destinations,
the same NAT mapping is used for both data sessions. (This is endpointindependent mapping.) The NAT mapping is not removed until the data
sessions with both destinations have been removed.
LSN maintains the NAT mapping for a full-cone session for a period of
time, the STUN timeout, after the last data session ends. The STUN timeout
is 2 minutes by default and is configurable. (See STUN Timeout on
page 659.)
642 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
By default, full-cone behavior for the well-known destination ports
(1-1024) is disabled. Full-cone behavior does not apply to ICMP sessions.
How LSN Differs from Traditional NAT

LSN fulfills the following requirements that traditional NAT is unable to
fulfill:
High transparency Existing user applications continue to work with
minimal to no impact on customers.

Well defined NAT behavior LSNs consistent, deterministic behavior
allows for easy development of new user applications. Traditional NAT

implementations vary considerably, and may not work for all applications.
Fairness in resource sharing LSN provides user guarantees and protec-
tion.
LSN works for both client-server (traditional) and client-client (P2P)
applications.
The benefits LSN provides that traditional NAT can not provide are
described in this section and in more detail in Benefits of LSN on
page 645.
Traditional NAT works for client-to-server applications, wherein a client
opens a connection to a server and requests data, and the server responds
back to the client. However, traditional NAT is often inadequate for contemporary applications such as peer-to-peer (P2P) file-sharing, instant messengers (IM), and Voice-over-IP (VoIP).
To provide NAT for these types of applications, LSN is required. Figure 169
shows an example of P2P file sharing among LSN clients and other devices.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
643 of 950

Overview
FIGURE 169
LSN Clients Using P2P File Sharing
In this example, multiple clients are registered with a P2P file-sharing

tracker as sharers of file example.torrent. All clients are registered on the
file-sharing tracker by their public IP addresses. LSN allows each of the
internal clients to use the same public IP address, with different Layer 4
source port numbers. LSN also allows the clients in the internal subnet to
share the file among themselves, as well as with other clients who are outside the internal network.
644 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Benefits of LSN
LSN provides the following benefits not provided by traditional NAT:
Sticky NAT
Application transparency through full-cone NAT to support peer-to-peer
(P2P) applications
Hairpinning support
Configurable user quotas to ensure fair allocation of NAT mappings
Static port reservation
Sticky NAT
Once an internal user uses a NAT IP, the user always uses the same NAT IP
for future connections. If all user sessions are cleared, then a different NAT
IP may be assigned.
Some applications that open multiple sessions to the same or multiple servers often do not work well without sticky NAT.
Full-Cone NAT
Traditional NAT works well for client-to-server applications, wherein a client opens a connection to a server and requests data, and the server responds
back to the client. However, traditional NAT is inadequate to support clientto-client applications, such as the following:
Peer-to-peer (P2P) file-sharing applications
Instant messengers (IM)
Voice-over-IP (VoIP)
To overcome the shortcomings of traditional NAT, LSN implements fullcone NAT. Full-cone NAT, also known as one-to-one NAT, has two specific
behaviors:
Endpoint-Independent Mapping (See Figure 168 on page 641.) After
LSN maps an internal clients source IP address and Layer 4 (TCP or

UDP) port to an external IP address and port, the same mapping is used
for all traffic from that internal source IP and port, regardless of the destination. For ping, the ICMP query identifier is treated the same way as a
UDP or TCP port.
Internal-IP-and-L4-Port = External-IP-and-L4-Port, for all destinations
Internal-IP-and-ICMP-query-ID = External-IP-and-ICMP-queryID, for all destinations
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
645 of 950

Overview
Endpoint-Independent Filtering (See Figure 169 on page 644.) For
traffic from any source to a given mapped client, LSN always allows the
traffic to be forwarded to the internal client regardless of the endpoint.
These techniques provide consistent NAT mapping behavior, enabling client-to-client applications such as P2P, client-to-server applications, and
NAT traversal techniques such as STUN, to work correctly.
Note:
646 of 950
Endpoint-Independent Filtering is different from security filtering such as

provided by ACLs, black/white lists, and so on. Endpoint-Independent
Filtering simply means that LSN does not cause an internal client to be
unreachable by certain sources, by using different mappings based on destination. The AX devices security features can still be used to control
access to clients.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Hairpinning
Hairpinning allows inside clients to communicate with one another using
their outside addresses. This feature is useful for applications that require
global addresses. Figure 170 shows an example.
FIGURE 170
LSN NAT Hairpinning
User Quotas
LSN user quotas limit the number of NAT port mappings allowed for individual internal IP addresses. For example, you can limit each inside IP
address to a maximum of 100 TCP NAT ports. Once a client reaches the
quota, the client is not allowed to open additional TCP sessions.
You can configure separate quotas for each of the following protocols, on a
global or individual LSN Limit-ID (LID) basis:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
647 of 950

Overview
TCP
UDP
ICMP
When an internal user first makes a NAT mapping, it will be assigned to a

NAT IP as part of sticky NAT. Before choosing a NAT IP for a particular
internal user, LSN checks to ensure there are enough ports free on that NAT
IP to satisfy the user quota. This guarantees that internal users will be able
to use as many ports as possible.
For example, if the TCP user quota is 100 ports, the user will only be
assigned to the NAT IP if it has at least 100 free NAT ports.
Once the assignment is made, LSN reserves 100 ports on that NAT IP. For
example, if a certain class of user has a TCP user-quota of 100, and LSN
assume there are 64,000 ports on a NAT IP, then 640 users of that type can
be mapped to that NAT IP.
In some situations, you might want to relax the user-quota requirement if
users are not expected to use their entire user-quota. In this case, you can
specify a reserve value for each user quota. For example, you can configure
a TCP user-quota of 100 with a reserve value of 50. For the above calculation, LSN only checks that the NAT IP has 50 free NAT ports instead of the
full 100. In that case, there can be twice as many (1280) users assigned to
that NAT IP.
How the Reserve Value Affects NAT IP Selection
If the inside client is not yet assigned to a NAT IP address, LSN selects an
available NAT IP address. The NAT IP address must meet the following
requirements in order to be used for the client:
The TCP port reserve on the NAT IP address must contain enough
reserved TCP ports to fulfill the configured per-user TCP reserve.

The configured per-user TCP reserve must not exceed the number of
free ports on the NAT IP address.

The UDP port reserve on the NAT IP address must contain enough
reserved UDP ports to fulfill the configured per-user UDP reserve.

The configured per-user UDP reserve must not exceed the number of
free ports on the NAT IP address.

Note:
648 of 950
There is a difference between available reserve ports and free ports. It is

possible to allocate more than the reserve value. However, it is not possible to allocate more than the user-quota value.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
All requirements above must be met for any type of session (TCP, UDP, or
ICMP). If the NAT IP address can not meet all requirements, another available address is selected and evaluated for the same requirements. The process continues until an available NAT IP address that meets all requirements
is found.
Example:
Assume the following user quotas and reserve values are in effect:
UDP user quota 2000, with reserve 100
TCP user quota 2000, with reserve 200
In this configuration, a new inside client can be assigned to a NAT IP

address only if the address has at least 100 unreserved UDP ports and 200
unreserved TCP ports.
In addition, the NAT IP address must have at least 100 free UDP ports and
200 free TCP ports.
Extended User Quota for Always-Available Services
By default, once a client reaches their quota for a protocol, no new translations for that protocol are allowed. To ensure that ports are available for
essential services, you can configure an extended quota for the protocol
ports used by those essential services. For example, to ensure that email service remains available, you can configure an extended quota for TCP port
25, the standard port used by Simple Mail Transfer Protocol (SMTP).
Extended quotas can be configured on individual LSN LIDs, for individual
destination ports.
Maximum User Per IP
By default, there is no limit to the number of internal addresses that can be
mapped to a single public address at the same time. You can specify
1-65535 as the limit.
Static Port Reservation

A common issue with NAT occurs when an inside user wants to advertise a
service on a port. For example, an HTTP server will need to advertise port
80. However, since the NAT IP is shared, only one user per NAT IP will be
able to have port 80.
You can allow an inside user to reserve a specific NAT port. In this example,
the NAT port 80 would be statically assigned to the particular user.
Note:
b y
This concept of port reservation is sometimes called port forwarding.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
649 of 950

Overview
LSN Logging
The AX device generates logs for LSN operational events and for LSN traffic.
LSN Operational Logging

Table 17 lists the types of LSN operational events that are logged.
TABLE 17 LSN Operational Logs
Severity Level
Critical
Warning
Notice
Event
User-quota creation failure
Full-cone session creation
failure
New inside user unable to
get NAT IP
Current inside user on
NAT IP can not get new
NAT port
User quota exceeded
Extended user quota

exceeded
Message String
LSN: User-quota creation failed (out of memory)
for pool...
LSN: Full-cone session creation failed (out-ofmemory) for pool...
LSN: New user could not get a NAT IP on pool..
LSN: NAT port usage exceeded on pool...
LSN: ICMP user-quota exceeded on pool...

LSN: UDP user-quota exceeded on pool...
LSN: TCP user-quota exceeded on pool...
LSN: UDP extended user-quota exceeded on
pool...
LSN: TCP extended user-quota exceeded on
pool...
Here is an example of the full string for a log:

May 13 2010 15:15:43 Warning [AX]:LSN: NAT port usage exceeded on pool pool2
(4146 times)
This log indicates that a current NAT IP user with an external IP address
from pool2 could not get a new NAT port session, because no ports were
available. The log indicates 4146 occurrences of the same event.
LSN events are logged to the AX devices local log buffer based on the log
settings for the system.
650 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
LSN Traffic Logging

LSN traffic logs are sent only to external log servers.
There are two basic types of LSN traffic logs:
Session logs, to indicate creation or deletion of ICMP, TCP, and UDP
sessions
NAT port mapping logs, to indicate creation or freeing of NAT port
mappings for ICMP, TCP, and UDP

Table 18 lists the LSN traffic logs that can be generated.
TABLE 18 LSN Traffic Logs
Event
ICMP data session
created
TCP data session
created
UDP data session
created
ICMP data session
deleted
TCP data session
deleted
UDP data session
deleted
LSN port mapping
created for ICMP
Message String Format

AX_hostname NAT-ICMP-C:
fwd_src_ip:fwd_src_port<-->fwd_dest_ip:fwd_dest_port,
rev_src_ip:rev_src_port<-->rev_dest_ip:rev_dest_port
AX_hostname NAT-TCP-C:
AX_hostname NAT-UDP-C:
AX_hostname NAT-ICMP-D:
AX_hostname NAT-TCP-D:
AX_hostname NAT-UDP-D:
AX_hostname NAT-ICMP-C: inside_ip:inside_port<-->nat_ip:nat_port
to dest_ip:dest_port
Note: In this message and the other port mapping creation messages, the destination
(to dest_ip:dest_port) is not included in the message by default. You can enable
the destination to be included when you configure LSN external logging.
LSN port mapping
created for TCP
LSN port mapping
created for UDP
LSN port mapping for
ICMP freed
TCP freed
UDP freed
AX_hostname NAT-TCP-C: inside_ip:inside_port<-->nat_ip:nat_port

AX_hostname NAT-UDP-C: inside_ip:inside_port<-->nat_ip:nat_port
AX_hostname NAT-ICMP-F: inside_ip:inside_port<-->nat_ip:nat_port
AX_hostname NAT-TCP-F: inside_ip:inside_port<-->nat_ip:nat_port
AX_hostname NAT-UDP-F: inside_ip:inside_port<-->nat_ip:nat_port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
651 of 950

Overview
You can specify the severity level of LSN traffic logs when you configure
external logging (described below). The default severity level is debugging.
LSN port mapping logs are enabled by default. LSN session logs are disabled by default. You can enable or disable each type of log when you configure external logging.
Examples
The following logs indicate the creation and deletion of a UDP session.
AX5200 NAT-UDP-N: 10.10.10.100:46301<-->172.7.7.100: 300, 172.7.7.100:5300
<-->172.7.7.25:46301
AX5200 NAT-UDP-D: 10.10.10.100:46301<-->172.7.7.100: 300, 172.7.7.100:5300
<-->172.7.7.25:46301
The following logs indicate the creation and freeing of a port mapping for
UDP.
AX5200 NAT-UDP-C: 10.10.10.100:63226 -> 172.7.7.25:6226 to 172.7.7.100:5300
AX5200 NAT-UDP-F: 10.10.10.100:63226 -> 172.7.7.25:6226
Remote Logging
LSN traffic logs can be sent only to external log servers. LSN traffic logs
are not sent to the AX devices local log buffer.
You can use a group of external log servers. The AX device uses a hash
value based on the client IP address to select an external log server, and
always sends logs for that client to the same server. (For configuration information, see Configuring External Logging for LSN Traffic Logs on
page 660.)
External LSN logging applies only to LSN traffic logs, not to LSN operational event logs.
Note:
LSN NAT Capacities

Pools and Pool Groups
AX Release 2.4.3 increases the capacity for LSN NAT resources that can be
configured on an AX device. These increases apply only to LSN.
Up to 500 LSN pools can be configured. In previous releases, up to 100
LSN pools can be configured.

Up to 200 LSN pool groups can be configured. In previous releases, up
to 50 LSN pool groups can be configured.

Each pool group can contain up to 25 pools. In previous releases, each
pool group can contain up to 5 pools.
652 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
This release also has a CLI syntax enhancement for LSN pool-group configuration. (See CLI Syntax Enhancement for LSN Pool-Group Configuration on page 156.)
Note:
Maximum LSN Pool IP Addresses

By default, the AX models that support LSN can support up to the following
maximum numbers of LSN pool addresses (outside addresses) per system:
AX 5200 10,000 outside IPs
AX 5100 10,000 outside IPs
AX 3000 4000 outside IPs
This limit is configurable. To display the current and configurable values,

use the show system resource-usage command. Here is an example on
model AX 5200:
AX5200(config)#show system resource-usage
Resource
Current
Default
Minimum
Maximum
-------------------------------------------------------------------------l4-session-count
33554432
33554432
8388608
134217728
nat-pool-addr-count
10000
2000
500
10000
real-server-count
1024
1024
512
16384
real-port-count
2048
2048
512
32768
...
The Current column shows the maximum number of LSN pool addresses
currently allowed on the system. The default column shows the default
maximum allowed. In this example, the maximum has been increased by an
administrator, to the highest allowed amount, 10000.
To change the maximum number of LSN pool addresses allowed on the system, use the following command at the global configuration level of the
CLI:
[no]
system
maximum
resource-usage
nat-pool-addr-count
The maximum value can be any value in the range between the values in the
Minimum and Maximum columns in the show system resource-usage output.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
653 of 950

Overview
Note:
To place a system resource change into effect, you must reload or reboot
the AX device. If you change the maximum number of Layer 4 sessions
(l4-session-count), a reboot is required.
Notes and Limitations

User-Quota and Extended-User-Quota Decrement
For user quotas, the extended user quota (if configured) is always decremented before the user quota.
Example:
TCP user quota is 10.
Extended user quota for TCP port 80 is 5.
An inside user creates 5 non-port-80 sessions followed by 10 port-80 sessions. In this case:
The first 5 port-80 sessions that finish will always decrement the
extended user quota.

The non-port-80 sessions will still decrement the regular user quota.
Dynamic Class-List Changes

Class-list changes do not affect LSN sessions that are already in effect when
the class list changes occur.
Example:
Some data sessions, user-quota sessions, or full-cone sessions are created
for inside user X. Then, the class list is changed in a way that affects X.
The sessions for X will stay alive as long as there is traffic matching them.
LSN IP Selection
The method used for selection of an IP address within an LSN pool does not
apply to pool selection within a pool group.
Selection of a pool from within a pool group is always random. After a pool
is randomly selected, the configured IP selection method is used to select an
IP address from the pool.
654 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring Large-Scale NAT
Example:
The least-used-strict method is enabled for LSN IP address selection. For a
new NAT session:
1. A pool is randomly chosen from the pool group.
2. The least-used IP address within that pool is chosen for the new NAT
session.

To configure LSN:
1. Configure NAT pools (and optionally, pool groups). Use the LSN
option to indicate the pools are for use by LSN.
2. Configure LSN Limit IDs (LIDs). For each LID, specify the NAT pool
to use. Optionally, set user quotas for the LID.
3. Configure class lists for the user subnets that require LSN. A class list is
a list of internal subnets or hosts. Within a class list, you can bind each
internal subnet to an individual LSN LID.
4. Bind a class-list for use with LSN. The class lists will apply to packets
from the inside NAT interface to the outside NAT interface. There can
be at most 1 class-list for this purpose.
5. Enable inside NAT on the interface connected to the internal clients.
6. Enable outside NAT on the interface connected to the Internet.
7. Enable new-path processing.
New-path processing was enabled by default in AX Release 2.5.0 but is
disabled by default in the current release. New-path processing is required
for LSN and applies only to LSN. The option does not apply to any other
features.
Note:
The CLI commands for performing these configuration steps are described
below.
For information about additional options, see the following sections:
Configuring Static Mappings on page 659
Configuring Full-Cone Support on page 659
Configuring External Logging for LSN Traffic Logs on page 660
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
655 of 950

Configure the IP Selection Method on page 662
Configuring the LSN SYN Timeout on page 663
Configure an LSN NAT Pool

Use the following command at the global configuration level of the CLI:
[no] ip nat pool pool-name start-ipaddr end-ipaddr
netmask {subnet-mask | /mask-length} lsn
[max-users-per-ip num]
This command configures an LSN NAT pool. The start-ipaddr and endipaddr options specify the beginning and ending public IP addresses in the
range to be mapped to internal addresses. The netmask option specifies the
subnet mask or mask length for the addresses.
The lsn option enables the pool for use by LSN.
The max-user-per-ip option specifies the maximum number of internal
addresses that can be mapped to a single public address at the same time.
You can specify 1-65535. By default, there is no limit.
Note:
LSN pools can not be used for SLB.

Pool Modification
If you need to modify a pool used for LSN, all sessions using that pool must
be cleared first.
1. Remove the pool from any pool groups and LIDs that use the pool.
2. Clear the sessions (clear ip nat lsn all-sessions pool pool-name).
3. Reconfigure the pool.
4. Add the pool back to the pool groups and LIDs that use the pool.
Configure a LID
[no] lsn-lid num
Enter this command at the global configuration level of the CLI. The num
specifies the LID number and can be 1-31, for a maximum of 31 LIDs. This
command changes the CLI to the configuration level for the LID, where the
following LID-related commands are available:
656 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

[no] source-nat-pool pool-name
This command binds an LSN NAT pool to the LID.
[no] user-quota {tcp | udp | icmp} quota-num
[reserve reserve-num]
This command configures the per-user mapping quota for each type of protocol supported for LSN (TCP, UDP, or ICMP). The quota-num option specifies the maximum number of sessions allowed per client and can be
1-64000. There is no default user quota.
The reserve option allows you to specify how many ports to reserve on a
NAT IP for each user, 0-64000. If unspecified, the reserve value is the same
as the user-quota value.
[no] extended-user-quota {tcp | udp | icmp}
service-port portnum sessions num
This command configures a per-user extended quota for essential services.
The port option specifies the Layer 4 protocol port of the service, and can
be 1-65535. The sessions option specifies how many extended sessions are
allowed for the protocol port, and can be 1-255. There is no default
extended user quota.
Configure a Class List

[no] class-list {list-name | filename file}
This command changes the CLI to the configuration level for the class list.
The list-name option will add the list to the running-config. If the list will be
large, you might want to use the filename file option to save the list to a file
instead. In this case, the list entries are not displayed in the running-config.
The following class-list-related command is available:
[no] priv-addr {subnet-mask | /mask-length}
lsn-lid num
The priv-addr option specifies the internal host or subnet address. Use the
subnet-mask or /mask-length option to specify the subnet mask or mask
length. The lsn-lid num option specifies the LID number.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
657 of 950

Class List Syntax
Each entry (row) in the class list defines a client class, and has the following
format:
ipaddr /network-mask lsn-lid num [; comment-string]
Each entry consists of the following:
ipaddr Specifies the inside subnet that requires LSN. The network-
mask specifies the network mask.

To configure a wildcard IP address, specify 0.0.0.0 /0. The wildcard
address matches on all addresses that do not match any entry in the class
list.
lsn-lid num Specifies the LID.
; 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.
Example Class Lists
Here is an example of a class list for inside subnet 5.5.5.x/24 using LID 2.
5.5.5.0 /24 lsn-lid 2
Bind the CLass List for Use with LSN

[no] ip nat inside source class-list list-name
Enable Inside NAT on the Interface Connected to Internal Clients

Use the following command at the configuration level for the interface:
[no] ip nat inside
Enable Outside NAT on the Interface Connected to the Internet

Use the following command at the configuration level for the interface:
[no] ip nat outside
658 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Enable New-path Processing

[no] slb new-path-enable
Optional Configuration
The following sections describe additional configuration options.
Configuring Static Mappings

Optionally, to configure static mappings for a range of protocol ports for an
internal address, use the following command at the global configuration
level of the CLI:
[no] ip nat lsn port-reservation inside
priv-ipaddr
start-priv-portnum
end-priv-portnum
nat public-ipaddr start-public-portnum
end-public-portnum
The priv-ipaddr option specifies the internal IP address. The start-priv-portnum and end-priv-portnum options specify the range of internal protocol
port numbers. Likewise, the public-ipaddr option specifies the public IP
address to map to the internal IP address. The start-public-portnum and endpublic-portnum options specify the range of public protocol port numbers to
map to the range of internal protocol port numbers.
Configuring Full-Cone Support

By default, LSN does not provide full-cone support for user sessions initiated from an internal IP address to a well-known TCP or UDP port (0-1023)
on an external address. To enable full-cone support for these sessions, use
the following command at the global configuration level of the CLI:
[no] ip nat lsn enable-full-cone-for-well-known
STUN Timeout
LSN maintains the NAT mapping for a full-cone session for a period of
time, the STUN timeout, after the session ends. If the client requests a new
session for the same port before the mapping times out, the mapping is used
again, for the new session. If the mapping is not used again before the
STUN timeout expires, the mapping is removed.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
659 of 950

The default STUN timeout is 2 minutes. To change the STUN timeout, use
[no] ip nat lsn stun-timeout minutes
You can specify 0-60 minutes.
Configuring External Logging for LSN Traffic Logs

LSN traffic logs can be sent only to external log servers. If you configure a
group of external log servers, the AX device load balances the messages
among the servers. Source-IP based hashing is used to select an external log
server. This method ensures that LSN logs for a given source IP address
always go to the same log server.
To configure LSN logging to external servers:
1. Create an SLB real server configuration for each log server.
2. Configure a UDP service group and add the log servers to the group.
The service group can contain a maximum of 32 members for external
LSN logging.
3. Configure an LSN logging template. Within the template, specify the
service group and the types of events to log.
The commands for configuring real servers and service groups are the same
as those used for SLB. (See the example in Configuration of External Logging for LSN Traffic Logs on page 665.)
To configure an LSN external logging template, use the following commands:
[no] ip nat template logging template-name
This command changes the CLI to the configuration level for the template,
where the following configuration commands are available:
This command adds the service group of external log servers to the template.
[no] log port-mappings
[no] log sessions
These commands enable or disable LSN traffic logs. The port-mappings
option is enabled by default. The sessions option is disabled by default. (For
more information about each type of LSN traffic log, see LSN Logging
on page 650.)
660 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

[no] source-port port-num
This command specifies the UDP port number from which the AX device
will send the log messages. The default is 514.
[no] severity severity-level
This command specifies the severity level to assign to LSN traffic logs generated using this template. You can enter the name or the number of a severity level. The default is 7 (debugging).
{0 | emergency}
{1 | alert}
{2 | critical}
{3 | error}
{4 | warning}
{5 | notification}
{6 | information}
{7 | debugging}
[no] facility facility-name

This command specifies the logging facility to use. The default is local0.
For a list of available facilities, enter the following command: facility ?
[no] include-destination
This command includes the destination IP addresses and protocol ports in
NAT port mapping logs. This option is disabled by default.
Activating the LSN Logging Template
To activate the LSN external logging template, use the following command
[no] ip nat lsn logging default-template
template-name
LSN external logging does not take effect until you use this command.
Using a Different LSN Logging Template for Individual Pools
The default LSN logging template is used for all LSN pools. To use a different LSN logging template for an individual pool, configure the template,
then use the following command at the global configuration level of the
CLI:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
661 of 950

[no] ip nat lsn logging pool pool-name template
template-name
Configure the IP Selection Method

The method used by LSN to select an IP address from an LSN NAT pool is
configurable, on a global basis. You can select one of the following IP
address selection methods:
random (the default)
round-robin
least-used-strict Selects the address with the fewest NAT ports of any
type (ICMP, TCP, or UDP) used

least-udp-used-strict Selects the address with the fewest UDP NAT
ports used
least-tcp-used-strict Selects the address with the fewest TCP NAT
ports used
least-reserved-strict Selects the address with the fewest NAT ports of
any type (ICMP, TCP, or UDP) reserved

least-reserved-udp-strict Selects the address with the fewest UDP NAT
ports reserved
least-reserved-tcp-strict Selects the address with the fewest TCP NAT
ports reserved
least-users Selects the address with the fewest users
The IP address selection method applies only to the IP addresses within

individual pools. The method does not apply to selection of pools within a
pool group. LSN randomly selects a pool from within a pool group, then
uses the configured IP address selection method to select an address from
within the pool.
To specify the method for LSN IP address selection within a pool, use the
following command at the global configuration level of the CLI:
[no] ip nat lsn ip-selection method
The method can be one of the options listed above. The method you specify
applies to all LSN pools.
662 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Displaying LSN Information
Configuring the LSN SYN Timeout

LSN has its own SYN timeout, separate from the IP NAT translation timeout. The LSN timeout can be 2-7 seconds, and is 4 seconds by default.
To change the LSN timeout, use the following command at the global configuration level of the CLI:
[no] ip nat lsn syn-timeout seconds
In AX Release 2.5.0 (the Beta release for LSN), the ip nat translation
syn-timeout command was used for the LSN timeout. Accordingly, the
configurable range was changed from 60-300 seconds to 2-7 seconds. In
AX Release 2.4.3, the ip nat translation syn-timeout command is not
used for LSN, and the configurable range has been restored to 60-300 seconds. In AX Release 2.4.3, to configure the LSN SYN timeout, use the
ip nat lsn syn-timeout command instead of the ip nat translation syntimeout command.
Note:
Displaying LSN Information

Use the following commands to display LSN information.
show class-list [list-name]
This command shows configured class lists.
show ip nat lsn full-cone-sessions
This command shows currently active full-cone sessions.
show ip nat lsn pool-statistics
This command shows statistics related to IP address pools used for LSN.
show ip nat lsn user-quota-sessions
This command shows currently active user quota sessions.
show ip nat lsn port-reservations
This command shows configured LSN static port reservations.
show ip nat lsn statistics
This command shows global statistics related to LSN.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
663 of 950

Clearing LSN Statistics and Sessions

Use the following command to clear LSN statistics:
clear ip nat lsn statistics
Use the following commands to clear LSN sessions:
clear ip nat lsn full-cone-sessions
clear ip nat lsn data-sessions
clear ip nat lsn all-sessions pool pool-name
Note:
The last command is required before removing a pool from a pool group.
The commands in this section implement the LSN configuration shown in
The following command configures an LSN NAT pool:
AX(config)#ip nat pool LSN_POOL1 192.168.1.1 192.168.1.254 netmask /24 lsn
The following commands configure an LSN LID. The LID is bound to pool
LSN_POOL1. Per-user quotas are configured for TCP, UDP, and ICMP.
For UDP, this class of users will reserve only 100 UDP ports instead of 300.
An extended quota of sessions per client is allocated for TCP port 25
(SMTP).
AX(config)#lsn-lid 5
AX(config-lsn lid)#source-nat-pool LSN_POOL1
AX(config-lsn lid)#user-quota tcp 100
AX(config-lsn lid)#user-quota udp 300 reserve 100
AX(config-lsn lid)#user-quota icmp 10
AX(config-lsn lid)#extended-user-quota tcp port 25 sessions 3
AX(config-lsn lid)#end
The following commands configure a class list to bind the internal subnet to
the LID:
AX(config)#class-list list1
AX(config-class list)#5.5.5.0 /24 lsn-lid 5
AX(config-class list)#end
The following command enables LSN for the class list:

AX(config)#ip nat inside source class-list list1
664 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following commands enable inside NAT on the interface connected to
the internal clients:
The following commands enable outside NAT on the interface connected to

the Internet:
The following command enables new-path processing, which is required for

LSN:
AX(config)#slb new-path-enable
Configuration of External Logging for LSN Traffic Logs

The following commands configure external logging for LSN traffic logs:
AX5200(config)#slb server syslog1 192.168.1.100
AX5200(config-real server)#port 514 udp
AX5200(config)#slb service-group syslog udp
AX5200(config-slb svc group)#member syslog1:514
AX5200(config-slb svc group)#exit
AX5200(config)#ip nat template logging lsn_logging
AX5200(config-nat logging)#log port-mappings
AX5200(config-nat logging)#service-group syslog
AX5200(config-nat logging)#exit
AX5200(config)#ip nat lsn logging default-template lsn_logging
Display Commands
The following commands display LSN information:
AX(config)#end
AX#show class-list list1
Name:
list1
Total single IP:
0
Total IP subnet:
2
Content:
192.168.1.0 /24 lsn-lid 2
192.168.0.0 /16 lsn-lid 1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
665 of 950

AX#show ip nat lsn full-cone-sessions
LSN Full Cone Sessions:
Prot Inside Address
NAT Address
Conns
Pool
CPU Age
-------------------------------------------------------------------------------------------------UDP 1.0.208.99:1105
6.6.0.158:1345
1
pool1
1
0
UDP 1.4.144.150:1093
6.6.0.140:31573
1
pool1
4
0
UDP 1.0.167.140:1117
6.6.0.145:12277
1
pool1
13
0
AX#show ip nat lsn user-quota-sessions

LSN User-Quota Sessions:
Inside Address
NAT Address
ICMP
UDP
TCP
Pool
LID
--------------------------------------------------------------------------------------1.1.138.159
6.6.0.158
0
3
0
pool1
3
1.0.235.149
6.6.0.134
0
3
0
pool1
3
1.0.35.54
6.6.0.188
0
2
0
pool1
3
AX#show ip nat lsn port-reservations
LSN Port Reservations
Inside Address
Start
End
NAT Address
Start
End
-------------------------------------------------------------------------------------10.0.0.1
80
1024
172.7.7.30
80
1024
AX#show ip nat lsn pool-statistics
LSN Address Pool Statistics:
---------------------------pool0
Address
Users ICMP
Freed Total UDP
Freed Total Rsvd
TCP
Freed Total Rsvd
-------------------------------------------------------------------------------------------------------172.7.7.20
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.21
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.22
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.23
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.24
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.25
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.26
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.27
0
0
0
0
0
0
0
0
0
0
0
0
172.7.7.28
0
0
0
0
0
0
0
0
0
3
3
0
172.7.7.29
0
0
0
0
0
0
0
0
0
0
0
0
Table 17 describes the fields in the show ip nat lsn pool-statistics output.
TABLE 19 show ip nat lsn pool-statistics fields
Field
Address
Users
666 of 950
ICMP
Freed (ICMP)
Total (ICMP)
Description
NAT (global) IP address.
Number of inside IP addresses currently using the NAT IP
address.
Number of ICMP identifiers currently in use.
Total number of ICMP identifiers freed.
Total number of ICMP identifiers allocated.
UDP
Freed (UDP)
ICMP column + Freed column = Total column.

Number of UDP ports currently in use.
Total number of UDP ports freed.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 19 show ip nat lsn pool-statistics fields (Continued)
Field
Total (UDP)
Description
Total number of UDP ports allocated.
Rsvd (UDP)
UDP column + Freed column = Total column.

Total of all UDP reserve settings for each user that is currently using the NAT IP address.
TCP
Freed (TCP)
Total (TCP)
Rsvd (TCP)
For example, if an LID has the setting user-quota udp 100

reserve 50, and there are 50 users using the LID d on the
NAT IP address, the Rsvd value is 50*50 = 2500.
Number of TCP ports currently in use.
Total number of TCP ports freed.
Total number of TCP ports allocated.
TCP column + Freed column = Total column.
Total of all TCP reserve settings for each user that is currently using the NAT IP address.
For example, if an LID has the setting user-quota tcp 100
reserve 60, and there are 10 users using the LID d on the
NAT IP address, the Rsvd value is 10*60 = 600.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
667 of 950

668 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring Additional Admin Accounts
Management Security Features

In addition to basic security provided by login and enable passwords,
AX Series devices support the following advanced management access
security features:
Multiple admin accounts with distinct levels of access
Admin account lockout in response to excessive invalid passwords
Interface-level access control for individual management access types
(Telnet, SSH, and so on)

Web access features for securing access through the GUI
Authentication, Authorization, and Accounting (AAA) for remotely
managed access security

The following sections describe these features and show how to configure
them.
If you have not already changed the default admin password and the
enable password, A10 Networks recommends that you do so now, before
implementing security options described in this chapter.
Note:

The AX device comes with one admin account, admin, by default. The
admin account has Root privileges and cannot be deleted.
When logged onto the AX device with the admin account, you can configure additional admin accounts. For each admin account, you can configure
the following settings:
Username and password
Privilege level (read or read-write)
IP host or subnet address from which the admin is allowed to log on
Account state (enabled or disabled)
Note:
b y
You cannot change the privilege level of the admin account or disable
it.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
669 of 950
Configuring an Admin Account

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

1. Select Config > System > Admin.
2. Click Add. The Administrator section appears.
3. Enter the name in the Name field.
4. Leave Change Administrator Password selected.
(If you do not change the password, the default is used: a10.)
5. Enter the password for the new admin account in the Password and Confirm Password fields.
6. To restrict login access by the admin to a specific host or subnet:
a. Enter the address in the Trusted Host IP Address field.
b. To restrict access to just a single host, edit the value in the Netmask
field to 255.255.255.255.
c. To restrict access to a subnet, edit the value in the Netmask field to
the subnet mask for the subnet.
Note:
To allow access from any host, leave the Trusted Host IP Address and
Netmask fields blank.
7. From the Privilege drop-down list, select the access level:
Super Admin Allows access to all levels of the system. This
account is not the Root account and can be deleted. This account
cannot configure other admin accounts. (Only the admin account
that has Root privileges can configure other admin accounts.)
Read Only Admin Allows monitoring access to the system but not
configuration access. In the CLI, this account can only access the
User EXEC and Privileged EXEC levels, not the configuration levels. In the GUI, this account cannot modify configuration information.
Partition Write Admin The admin has read-write privileges within
the private partition to which the admin is assigned. The admin has
read-only privileges for the shared partition.
Partition Read Admin The admin has read-only privileges within
the private partition to which the admin is assigned, and read-only
privileges for the shared partition.
670 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Partition RS Operator The admin is assigned to a private partition
but has permission only to view service port statistics for real servers in the partition, and to disable or re-enable the real servers and
their service ports.
The Partition roles apply to Role-Based Administration (RBA). For information about this feature, see Role-Based Administration on page 797.
Note:
8. Leave the Status enabled.

9. Click OK.
10. The new admin appears in the Admin table.
FIGURE 171
Config > Admin > Admin
FIGURE 172
Config > Admin - new admin added
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
671 of 950
USING THE CLI

1. Log on through the CLI and access the global configuration level.
2. Enter the following command to create the new admin account:
[no] admin admin-username
This command changes the CLI to the configuration level for the new
account.
3. Use the following commands to complete the configuration:
password string
trusted-host ipaddr {subnet-mask | /mask-length}
privilege priv-level [partition-name]
The password command assigns the password, which can be 1-63 characters. The default is a10.
The trusted-host command specifies the host or subnet from which the
admin is allowed to log in. The default is 0.0.0.0 /0 (any host or subnet).
The privilege command specifies the privileges granted to the admin
account:
read The admin can access the User EXEC and Privileged EXEC
levels of the CLI only. This is the default.
write The admin can access all levels of the CLI but cannot configure other admin accounts.
partition-read The admin has read-only privileges within the private partition to which the admin is assigned, and read-only privileges for the shared partition.
partition-write The admin has read-write privileges within the
private partition to which the admin is assigned. The admin has
read-only privileges for the shared partition.
partition-enable-disable The admin has read-only privileges for
real servers, with permission to view service port statistics and to
disable or re-enable the servers and their service ports. No other
read-only or read-write privileges are granted.
The partition-name specifies the name of the private partition to which
the admin is assigned. This option applies only to admins that have privilege level partition-read, partition-write, or partition-enable-disable.
Note:
To restrict write access to specific configuration areas, see Configuring

AAA for Admin Access on page 683.
4. To verify the new admin account, enter the following command:
show admin
672 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

CLI EXAMPLES
The following commands add admin adminuser2 with password
12345678 and read-write privilege:
AX(config)#admin adminuser2
AX(config-admin:adminuser2)#password 12345678
AX(config-admin:adminuser2)#privilege write
AX(config-admin:adminuser2)#show admin
UserName
Status
Privilege Partition
------------------------------------------------------admin
Enabled
Root
adminuser2
Enabled
Read/Write
The following commands add admin adminuser3 with password abcdefgh and read-write privilege, and restrict login access to the 10.10.10.x
subnet only:
AX(config)#admin adminuser3
AX(config-admin:adminuser3)#password abcdefgh
AX(config-admin:adminuser3)#privilege write
AX(config-admin:adminuser3)#trusted-host 10.10.10.0 /24
AX(config-admin:adminuser3)#show admin
UserName
Status
Privilege Partition
------------------------------------------------------admin
Enabled
Root
adminuser2
Enabled
Read/Write
adminuser3
Enabled
Read/Write
AX(config-admin:adminuser3)#show admin adminuser3 detail

User Name
...... adminuser3
Status
...... Enabled
Privilege
...... Read/Write
Partition
......
Trusted Host(Netmask) ...... 10.10.10.0(255.255.255.0)
Lock Status
...... No
Lock Time
......
Unlock Time
......
Password Type
...... Encrypted
Password
...... $1$6334ba07$CKbWL/LuSNdY12kcE.KdS0
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
673 of 950
Deleting an Admin Account

An admin with Root privileges can delete other admin accounts. If you need
to delete an admin account:
1. Display the admin session table to determine whether the admin has any
active admin sessions.
2. Clear any sessions the admin has open.
3. Delete the admin account.
Note:
To delete an admin account, you first must terminate any active sessions
the admin account has open. The account is not deleted if there are any
open sessions for the account.
USING THE GUI

1. To display the admin session table, select Monitor > System > Admin.
2. To clear an admin session, click on the checkbox next to the session to
select it, then click Delete.
3. To delete the admin account:
a. Select Config > System > Admin.
b. Click on the checkbox next to the admin name.
c. Click Delete.
USING THE CLI

1. To display the admin session table, use the following command at the
Privileged EXEC level or any configuration level:
show admin session
2. To clear an admin session, use the following command at the Privileged
EXEC level or any configuration level:
clear admin session session-id
The session-id is the ID listed in the ID column of the show admin session output.
3. To delete the admin account, use the following command at the global
configuration level:
no admin admin-username
674 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring Admin Lockout
Configuring Admin Lockout

By default, there is no limit to the number of times an incorrect password
can be entered with an admin account to attempt access. You can enable the
AX device to lock admin accounts for a specific period of time following a
specific number of invalid passwords entered for the account.
Table 20 lists the admin lockout parameters you can configure.
TABLE 20 Admin Lockout Parameters
Parameter
Feature state
Threshold
Reset time
Duration
Description
Controls whether admin accounts can be
locked.
Number of failed login attempts allowed for
an admin account before it is locked.
Number of minutes the AX device remembers
a failed login attempt.
For an account to be locked, greater than the
number of failed login attempts specified by
the threshold must occur within the reset time.
Number of minutes a locked account remains
locked. To keep accounts locked until you or
another authorized administrator unlocks
them, set the value to 0.
Default
Disabled
5
10 minutes
10 minutes
To configure admin lockout, use either of the following methods.
USING THE GUI

To enable the lockout feature:
2. Select Lockout Policy on the menu bar.
3. Select Enable Administrator lockout Feature.
4. Optionally, change lockout settings. (For descriptions, see Table 20 on
page 675.)
5. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
675 of 950

To view lockout status or manually unlock a locked account:
1. Select Monitor > System > Admin.
2. Select the admin account.
3. Click Unlock.
USING THE CLI

2. Optionally, enter the following commands to change lockout settings:
admin lockout threshold number
admin lockout duration minutes
admin lockout reset-time minutes
(For descriptions, see Table 20 on page 675.)
3. Use the following command to enable admin lockout:
admin lockout enable
To view lockout status or manually unlock a locked account:
2. Enter the following command to view the lockout status of an admin
account:
show admin admin-username detail
3. Enter the following command to access the configuration level for the
admin account:
admin admin-username
4. Use the following command to unlock the account:
unlock
676 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Securing Admin Access by Ethernet

By default, certain types of management access through the AX devices
Ethernet interfaces are blocked. Table 21 lists the default settings for each
management service.
TABLE 21 Default Management Access
Management
Service
SSH
Telnet
HTTP
HTTPS
SNMP
Ping
Ethernet
Management
Interface
Enabled
Disabled
Enabled
Enabled
Enabled
Enabled
Ethernet and VE
Data Interfaces
Disabled
Disabled
Disabled
Disabled
Disabled
Enabled
You can enable or disable management access, for individual access types
and interfaces. You also can use an Access Control List (ACL) to permit or
deny management access through the interface by specific hosts or subnets.
To set management access through Ethernet interfaces, use either of the following methods.
Notes Regarding Use of ACLs
If you use an ACL to secure management access, the action in the ACL rule
that matches the management traffics source address is used to permit or
deny access, regardless of other management access settings.
For example, if you disable Telnet access to a data interface, but you also
enable access to the interface using an ACL with permit rules, the ACL permits Telnet (and all other) access to the interface, for traffic that matches the
permit rules in the ACL.
If you want certain types of management access to be disabled on an interface, do not use a permit ACL to control management access to the interface.
Each ACL has an implicit deny any any rule at the end. If the management
traffics source address does not match a permit rule in the ACL, the
implicit deny any any rule is used to deny access.
On data interfaces, you can disable or enable access to specific services and
also use an ACL to control access. However, on the management interface,
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
677 of 950

you can disable or enable access to specific services or control access using
an ACL, but you can not do both.
USING THE GUI

To change management access settings for interfaces:
1. Select Config > System > Access Control.
2. For each interface (each row), select or de-select the checkboxes for the
access types.
3. To use an ACL to control access, select the ACL from the ACL dropdown list in the row for the interface.
4. After selecting the settings for all the interfaces, click OK.
To reset the access settings to the defaults listed in Table 21, click Reset to
Default.
USING THE CLI

Disabling Management Access
To disable management access, use either of the following commands at the
disable-management service
{all | ssh | telnet | http | https | snmp | ping}
{management | ethernet port-num [to port-num] |
ve ve-num [to ve-num]}
or
disable-management service acl acl-num
In both commands, the following options specify the interfaces to protect:
management The out-of-band Ethernet management interface
(MGMT)
ve ve-num [to ve-num] A VE data interface or range of VE data inter-
faces
ethernet port-num [to port-num] An Ethernet data interface or range
of Ethernet data interfaces

In the first command, the following options specify the type of management
access you are configuring:
678 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

all Disables access to all the management services listed below.
ssh Disables SSH access to the CLI.
telnet Disables Telnet access to the CLI.
http Disables HTTP access to the management GUI.
https Disables HTTPS access to the management GUI.
snmp Disables SNMP access to the AX devices SNMP agent.
ping Disables ping replies from AX interfaces. This option does not
affect the AX devices ability to ping other devices.

Disabling ping replies from being sent by the AX device does not affect
the devices ability to ping other devices.
Note:
In the second command, the acl acl-id option specifies an ACL. Management access from any host address that matches the ACL is either permitted
or denied, depending on the action (permit or deny) used in the ACL.
CLI Examples:
The following command disables HTTP access to the out-of-band management interface:
AX(config)#disable-management service http management
You may lose connection by disabling the http service.
Continue? [yes/no]:yes
Enabling Management Access

To enable management access, use either of the following commands at the
enable-management service
{all | ssh | telnet | http | https | snmp | ping}
or
enable-management service acl acl-num
The options are the same as those for the disable-management command.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
679 of 950

CLI Example:
The following command enables Telnet access to data interface 6:
AX(config)#enable-management service telnet ethernet 6
Displaying the Current Management Access Settings

To display the management access settings that are currently in effect, enter
the following command at any level of the CLI:
show management
CLI EXAMPLES
Here is an example for an AX device that has 10 Ethernet data ports. In this
example, all the access settings are set to their default values.
AX#show management
PING
SSH
Telnet HTTP
HTTPS
SNMP
ACL
-----------------------------------------------------mgmt on
on
off
on
on
on
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
10
on
off
off
off
off
off
ve1
on
off
off
off
off
off
680 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Changing Web Access Settings
Here is an example after entering the commands used in the configuration
examples above.
AX#show management
PING
SSH
Telnet HTTP
HTTPS
SNMP
ACL
-----------------------------------------------------mgmt on
on
off
off
on
on
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
on
off
on
off
off
off
on
off
off
off
off
off
on
off
off
off
off
off
10
on
off
off
off
off
off
ve1
on
off
off
off
off
off
Regaining Access if You Accidentally Block All Access

If you disable the type of access you are using on the interface you are using
at the time you enter a disable-management command, your management
session will end. If you accidentally lock yourself out of the device altogether (for example, if you use the all option for all interfaces), you can still
access the CLI by connecting a PC to the AX devices serial port.
Changing Web Access Settings

By default, access to the AX management GUI is enabled and is secure. A
valid admin username and password are required to log in.
Table 22 lists the default settings for Web access.
TABLE 22 Default Web Access Settings
Parameter
Auto-redirect
HTTP server
HTTP port
HTTPS server
b y
Description
Automatically redirects requests for the unsecured port (HTTP) to the secure port
(HTTPS).
HTTP server on the AX device.
Protocol port number for the unsecured
(HTTP) port.
HTTPS server on the AX device.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Default
Enabled
Enabled
80
Enabled
681 of 950

TABLE 22 Default Web Access Settings (Continued)
Parameter
HTTPS port
Description
Protocol port number for the secure (HTTPS)
port.
Number of minutes a Web management session can remain idle before it times out and is
terminated by the AX device.
Timeout
aXAPI Timeout
Number of minutes an aXAPI session can

remain idle before being terminated.
Once the aXAPI session is terminated, the
session ID generated by the AX device
for the session is no longer valid.
Note: For information about aXAPI, see the
AX Series aXAPI Reference.
Note:
Default
443
Range: 0-60
minutes
To disable
the timeout,
specify 0.
Default: 10
minutes
0-60 minutes. f you
specify 0,
sessions
never time
out.
Default: 10
minutes
If you disable HTTP or HTTPS access, any sessions on the management

GUI are immediately terminated.
USING THE GUI

2. On the menu bar, select Web.
3. Edit the settings you want to change.
4. Click OK.
Note:
682 of 950
The Preference section sets the default IP address type (IPv4 or IPv6) for
GUI configuration fields that require an IP address. The Preference section does not affect access to the GUI itself.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring AAA for Admin Access
USING THE CLI

At the global configuration level of the CLI, use the following command:
[no] web-service
{
axapi-timeout-policy idle minutes |
auto-redir |
port protocol-port |
secure-port protocol-port |
server |
secure-server |
timeout-policy idle minutes
}
To view Web access settings, use the following command:
show web-service
CLI EXAMPLE
The following command disables management access on HTTP and verifies
the change:
AX(config)#no web-service server
AX(config)#show web-service
AX Web server:
Idle time:
Http port:
Https port:
Auto redirect:
Https:
Http:
10 minutes
80
443
Enabled
Enabled
Disabled

You can configure the AX device to use remote servers for Authentication,
Authorization, and Accounting (AAA) for admin sessions. The AX device
supports RADIUS and TACACS+ servers.
Note:
b y
RADIUS authorization is supported only for admin login through the

GUI.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
683 of 950
Authentication
Authentication grants or denies access based on the credentials presented by
the person who is attempting access. Authentication for management access
to the AX device grants or denies access based on the admin username and
password.
By default, when someone attempts to log into the AX device, the device
checks its local admin database for the username and password entered by
the person attempting to gain access.
Without additional configuration, the authentication process stops at this
point. If the admin username and password are in the local database, the
person is granted access. Otherwise, they are denied.
You can configure the AX device to also use external RADIUS or
TACACS+ servers for authentication.
You can use TACACS+ or RADIUS for external authentication. Only one
external authentication method can be used.
Authentication Process
You can specify whether to check the local database or the remote server
first. Figure 173 and Figure 174 show the authentication processes used if
the AX device is configured to check RADIUS or TACACS+ before checking the local database.
684 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 173 Authentication Process When Remote Authentication Is First
(2 remote servers configured) Example shown is for RADIUS
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
685 of 950

FIGURE 174 Authentication Process When Remote Authentication Is First
(1 remote server configured) Example shown is for TACACS+
Local Authentication Type Always Required

The local database must be included as one of the authentication sources,
regardless of the order is which the sources are used. Authentication using
only a remote server is not supported.
If the same username is configured in the local database and on the remote
server but the passwords do not match, the order in which the authentication
sources are used determines whether the admin is granted access.
686 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 175 Authentication Process When Username and Password On
Server Do Not Match the Local Database
Username admin Always Authenticated Locally

Unlike other admin accounts, the username admin has Root privileges. To
ensure against accidental lockout from the AX device, admin is always
authenticated using the local database only, regardless of the authentication
order used for other admin usernames.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
687 of 950
Authorization for GUI Access

Admins who log in through the GUI and who are authenticated by a
RADIUS or TACACS+ server, can be authorized for either read-only or
read-write access in the GUI:
If authorization is set on the RADIUS server, that setting is used. The
setting can be read-only or read-write.

If authorization is set on the TACACS+ server, the command level set
on the server determines whether the admin is granted read-only or readwrite access:
If the command level is 14 or 15, the admin is granted read-write
access in the GUI.
If the command level is 0-13, the admin is granted read-only access
in the GUI.
This authorization process does not apply to admins who log in through
the CLI. (See Authorization for CLI Access on page 688.)
Note:
Authorization for CLI Access

You can configure the AX device to use external RADIUS or TACACS+
servers to authorize commands entered by admins who log in using the CLI.
Following successful Authentication, the authenticated party is granted
access to specific system resources by Authorization. For an AX admin,
authorization specifies the CLI levels they can access.
RADIUS CLI Authorization

To configure RADIUS CLI Authorization, use the following settings on the
RADIUS server:
VALUE A10-Admin-Privilege Read-only-Admin 1
VALUE A10-Admin-Privilege Read-write-Admin 2
The first line grants access to the User EXEC level and Privileged EXEC
level. The admins CLI session begins at the User EXEC level. The admin
can access the Privileged EXEC level, without entering an enable password.
Access to the configuration level is not allowed.
688 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

login as: admin3
Password: ********
Last login: Fri Mar 26 20:03:39 2010 from 192.168.1.140
[type ? for help]
AX>enable
AX#
The second line grants access to all levels. The admins CLI session begins
at the Privileged EXEC level.
login as: admin4
Password: ********
Last login: Fri Mar 26 20:03:39 2010 from 192.168.1.140
[type ? for help]
AX#
TACACS+ CLI Authorization

To configure TACACS+ CLI Authorization:
Configure the TACACS+ server to authorize or deny execution of spe-
cific commands or command groups.

Configure the AX device to send commands to the TACACS+ server for
authorization before executing those commands.

This authorization process does not apply to admins who log in through
the GUI. (See Authorization for GUI Access on page 688.)
Note:
CLI Access Levels

You can use TACACS+ to authorize an admin to execute commands at one
of the following CLI access levels:
15(admin) This is the most extensive level of authorization. Com-
mands at all CLI levels, including those used to configure admin

accounts, are sent to TACACS+ for authorization.
14(config) Commands at all CLI levels except those used to configure
admin accounts are sent to TACACS+ for authorization. Commands for

configuring admin accounts are automatically allowed.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
689 of 950

1(priv EXEC) Commands at the Privileged EXEC and User EXEC
levels are sent to TACACS+ for authorization. Commands at other levels are automatically allowed.
0 (user EXEC) Commands at the User EXEC level are sent to
TACACS+ for authorization. Commands at other levels are automatically allowed.

Access levels 1-15 grant access to the Privileged EXEC level or higher,
without challenging the admin for the enable password. Access level 0
grants access to the User EXEC level only.
Note:
Command levels 2-13 are equivalent to command level 1.
Caution:
The most secure option is 15(admin). If you select a lower option, for
example, 1(priv EXEC), make sure to configure the TACACS+ server
to deny any unmatched commands (commands that are not explicitly
allowed by the server). Otherwise, unmatched commands, including
commands at higher levels, will automatically be authorized to execute.
TACACS+ Authorization Debug Options
You can enable the following TACACS+ debug levels for troubleshooting:
0x1 Common system events such as trying to connect with
TACACS+ servers and getting response from TACACS+ servers.

These events are recorded in the syslog.
0x2 Packet fields sent out and received by the AX Series device, not
including the length fields. These events are written to the terminal.
0x4 Length fields of the TACACS+ packets will also be displayed on
the terminal.
0x8 Information about TACACS+ MD5 encryption will be sent to the
syslog.
Accounting
You can configure the AX device to use external RADIUS or TACACS+
servers for Accounting.
Accounting keeps track of user activities while the user is logged on. For
AX admins, you can configure Accounting for the following:
Login/logoff activity (start/stop accounting)
Commands
690 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Command Accounting (TACACS+ only)

You can use TACACS+ servers to track attempts to execute commands at
one of the following CLI access levels:
15(admin) This is the most extensive level of accounting. Commands
at all CLI levels, including those used to configure admin accounts, are
tracked.
14(config) Commands at all CLI levels except those used to configure
admin accounts are tracked. Commands for configuring admin accounts

are not tracked.
1(priv EXEC) Commands at the Privileged EXEC and User EXEC
levels are tracked. Commands at other levels are not tracked.

0 (user EXEC) Commands at the User EXEC level are tracked. Com-
mands at other levels are not tracked.

Command levels 2-13 are equivalent to command level 1.
Note:
TACACS+ Accounting Debug Options

The same debug levels that are available for TACACS+ Authorization are
also available for TACACS+ Accounting. (See TACACS+ Authorization
Debug Options on page 690.)

To configure AAA for admin access:
1. Prepare the AAA servers:
Add admin accounts (usernames and passwords).
Add the AX device as a client. For the client IP address, specify the
AX IP address.
For authorization, configure the following settings for the admin
accounts:
If using TACACS+, specify the CLI commands or command
groups that are to be allowed or denied execution.
If using RADIUS, specify the access level for the GUI (readwrite or read-only).
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
691 of 950

2. To use RADIUS or TACACS+ for Authentication:
a. Add the RADIUS or TACACS+ server(s) to the AX device.
b. Add RADIUS or TACACS+ as an authentication method to use
along with the local database.
3. Configure Authorization:
a. Add the TACACS+ or RADIUS servers, if not already added for
authentication.
b. Specify the access level:
If using TACACS+, specify the CLI command levels to be
authorized.
If using RADIUS, specify the GUI access to be authorized.
4. Configure Accounting:
a. Add the TACACS+ or RADIUS servers, if not already added for
Authorization.
b. Specify whether to track logon/logoff activity. You can track both
logons and logoffs, logoffs only, or neither.
c. Optionally, is using TACACS+, specify the command levels to
track.
Configuring Authentication
To configure remote authentication, use either of the following methods.
USING THE GUI

2. On the menu bar, select one of the following options:
External Authentication > RADIUS
External Authentication > TACACS+
3. To add the primary server, click Server 1 to display the configuration

fields for the server.
4. Enter the hostname or IP address of the server in the Hostname field.
5. In the Secret and Confirm Secret fields, enter the shared secret (password) expected by the server when it receives requests.
692 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

6. To add a backup server to use if the primary server can not be reached,
click Server 2 and enter the configuration information for the server.
7. Click OK.
USING THE CLI

The command syntax shown in this section is simplified to show the
required or more frequently used options. For complete syntax information, see the AX Series CLI Reference.
Note:
1. Use one of the following commands at the global configuration level of

the CLI to add the primary server:
[no] radius-server host {hostname | ipaddr}
secret secret-string
[no] tacacs-server host {hostname | ipaddr}
The secret-string is the shared secret (password) expected by the server
when it receives requests.
2. To add a backup server to use if the primary server can not be reached,
repeat the command, using the backup servers information.
3. Use one of the following commands to specify the order in which to use
the authentication methods:
[no] authentication type
{
local [radius | tacplus] |
[radius | tacplus] local
}
(For more information, see Authentication Process on page 684.)
Configuring Authorization
Note:

Note:
The configuration options described in this section are available only in

the CLI.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
693 of 950

1. Add the RADIUS or TACACS+ server(s), if not already added.
2. Optionally, if using TACACS+, specify the command levels the
TACACS+ server will be used to authorize:
authorization commands cmd-level method tacplus
[none]
The cmd-level can be one of the following: 15, 14, 1, or 0.
The none option allows a command to execute if Authorization cannot
be performed (for example, if all TACACS+ servers are down).
(For descriptions, see Authorization for CLI Access on page 688.)
Note:
If using RADIUS, you can set the GUI access levels on the RADIUS
server itself. See Authorization for GUI Access on page 688.
3. Optionally, if using TACACS+, enable Authorization debugging:
authorization debug debug-level
The debug-level can be one of the following: 0x1, 0x2, 0x4, or 0x8.
(See TACACS+ Authorization Debug Options on page 690.)
Configuring Accounting
Note:

Note:
The configuration options described in this section are available only in

the CLI.
1. Add the RADIUS or TACACS+ server(s), if not already added.
2. To configure Accounting for logon/logoff activity, use the following
command:
[no] accounting exec {start-stop | stop-only}
{radius | tacplus}
694 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

3. Optionally, if using TACACS+, configure accounting for command execution:
accounting commands cmd-level stop-only tacplus
4. Optionally, if using TACACS+, enable Accounting debugging:
accounting debug debug-level
CLI EXAMPLES
RADIUS Authentication
The following commands configure a pair of RADIUS servers and configure the AX device to use them first, before using the local database. Since
10.10.10.12 is added first, this server will be used as the primary server.
Server 10.10.10.13 will be used only if the primary server is unavailable.
AX(config)#radius-server host 10.10.10.12 secret radp1
AX(config)#radius-server host 10.10.10.13 secret radp2
AX(config)#authentication type radius local
TACACS+ Authorization
The following commands configure the AX device to use TACACS+ server
10.10.10.13 to authorize commands at all CLI levels. In this example, the
none option is not used. As a result, if TACACS+ authorization cannot be
performed (for example, due to server unavailability), the command is
denied.
AX(config)#tacacs-server host 10.10.10.13 secret SharedSecret
AX(config)#authorization commands 15 method tacplus
TACACS+ Accounting
The following commands configure the AX device to use the same
TACACS+ server for accounting of logon/logoff activity and of all command activity:
AX(config)#accounting exec start-stop tacplus
AX(config)#accounting commands 15 stop-only tacplus
EXAMPLE INCLUDING RADIUS SERVER SETUP

This example shows the AX commands to configure an AX device to use a
RADIUS server, and also shows the changes to make on the RADIUS
server itself.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
695 of 950

The RADIUS server in this example is freeRADIUS. The IP address is
192.168.1.157, and the shared secret is a10rad.
To implement the solution, the following steps are required:
1. On the AX device:
a. Add the RADIUS server.
b. Enable RADIUS authentication.
2. On the freeRADIUS server:
a. In the clients.conf file, add the AX device as a client.
b. Add a dictionary file for vendor a10networks, and add the file to
the dictionary.
c. In the users file, add each AX admin as a user.
Configuration on the AX Device
Enter the following commands at the global configuration level of the CLI:
AX(config)#radius-server host 192.168.1.157 secret a10rad
AX(config)#authentication type local radius
Configuration on the freeRADIUS Server
Changes in clients.conf File
The AX device is added to the clients.conf file as a RADIUS client:
vi /usr/local/etc/raddb/clients.conf
client 192.168.1.0/24 {
secret
= a10rad
shortname
= private-network-1
Note:
In this example, the AX devices subnet is added as the client.

Creation of dictionary.a10networks File
In the dictionary file, specify the following:
Vendor name A10-Networks
Vendor code 22610
After authenticating an admin, the RADIUS server must return the

A10-Admin-Privilege attribute, with one of the following values:
696 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Read-only-Admin The admin can access User EXEC and Privileged
EXEC commands only. These are commands at the > and # prompts.
Read-write-Admin The admin can access User EXEC, Privileged
EXEC, and configuration commands. These are commands at the >, #,

(config)# and sub-config prompts.
vi /usr/local/share/freeradius/dictionary.a10networks
#
#
The FreeRADIUS Vendor-Specific dictionary.
#
# Version:
$Id: dictionary.a10networks,v 1.4 2009/05/05 11:03:56 a10user Exp $
#
#
For a complete list of Private Enterprise Codes, see:
#
#
http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers
#
VENDOR
A10-Networks
22610
BEGIN-VENDOR A10-Networks
ATTRIBUTE A10-App-Name
String
ATTRIBUTE A10-Admin-Privilege
integer
VALUE
A10-Admin-Privilege Read-only-Admin
VALUE
A10-Admin-Privilege Read-write-Admin
ATTRIBUTE A10-Single-1
51 String
52 String
53 String
54 String
55 String
ATTRIBUTE A10-Multi-1
56 String
57 String
58 String
59 String
60 String
END-VENDOR A10-Networks
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
697 of 950

vi /usr/local/share/freeradius/dictionary
add
$INCLUDE dictionary.a10networks
#new added for a10networks
Changes in users File

vi /usr/local/etc/raddb/users
read
Auth-Type := Local, User-Password == "test"

A10-Admin-Privilege = 1
write
Auth-Type := Local, User-Password == "test"

A10-Admin-Privilege = 2
Configuring Windows IAS for AX RADIUS Authentication

This section describes how to configure Windows Server 2003 Internet
Authentication Service (IAS) for use with AX RADIUS authentication.
These steps assume that IAS and Active Directory (AD) are already
installed on the Windows 2003 server.
Procedure Overview
To configure Windows IAS for AX RADIUS authentication:
1. On the IAS server, create the following access groups:
AX-Admin-Read-Only
AX-Admin-Read-Write
2. On the IAS server, configure a RADIUS client for the AX device.
3. On the IAS server, configure the following remote access policies:
AX-Admin-Read-Only-Policy
AX-Admin-Read-Write-Policy).
4. On the IAS server, add AD users to appropriate AX device access

groups, either AX-Admin-Read-Only or AX-Admin-Read-Write.
5. Register the IAS server in AD.
698 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

6. On the AX device, configure RADIUS.
7. Test the configuration by attempting to log onto the AX device with AD
users added in step 4.
The following sections provide detailed steps for each of these tasks.
Configure Access Groups

1. Select Start > All programs > Administrator tools > Active directory
user and computers.
If Active Directory Is Not Installed
If AD is not installed on the IAS server, you can use the following steps to
add the users and groups. However, the rest of this section assumes that AD
will be used.
1. Open the Computer Management tool by selecting Start > Programs >
Administrative Tools > Computer Management.
2. Open the System Tools and Local Users and Groups items, if they are
not already open.
3. Right click on Group and select New Group.
4. Enter the following information for the first group:
Group Name AX-Admin-Read-Only
Group Description Read-Only Access to AX devices
Members Add the members using the Add button.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
699 of 950
5. Click Create.
6. Enter the following information for the second group:
Group Name AX-Admin-Read-Write
Group Description Read-Write to AX devices
Members Add members as desired using the Add button
7. Click Create.
8. Click Close.
Configure RADIUS Client for AX Device

1. Open Internet Authentication Service, by selecting Start > Programs >
Administrative Tools > Internet Authentication Service.
2. Right-click on Client and select New Client.
3. Enter the following information in the Add Client dialog box:
Friendly name Useful name for the AX device; for example,
ax2000_slb1
Protocol RADIUS
700 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

192.168.1.238 is the IP address of the AX device that will use the IAS
server for external RADIUS authentication.
Note:
4. Click Next.
5. Enter the following information in the Add RADIUS Client dialog box:
Client address IP address or domain name for the client (AX
device)
Client-Vendor RADIUS Standard
Shared secret Secret to be shared between IAS and AX. You also
will need to enter this in the RADIUS configuration on the AX
device.
Confirm shared secret Same as above
Note:
b y
Do not select Request must contain the Message Authenticator attribute. AX RADIUS authentication does not support this option.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
701 of 950
6. Click Next.
Configure Remote Access Policies

1. Open the Internet Authentication Service, if not already open.
2. To create the first remote access policy, right-click on Remote Access
Policies, select New Remote Access Policy, and enter the following
information:
Policy Friendly name AX-Admin-Read-Only-Policy
702 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

3. Click Next.
4. In the Add Remote Access Policy dialog box, click Add.
5. In the Select Attribute dialog box, double-click Client Friendly Name.
6. In the Client-Friendly-Name dialog box, enter the friendly name used to
define the AX device (for example, AX-Admin-Read-Only-Policy) and
click OK.
7. In the same Add Remote Access Policy dialog box as before, click Add
again.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
703 of 950

8. In the Select Attribute dialog box, double-click Windows-Groups.
704 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

9. In the Groups dialog box, click Add, then double-click AX-AdminRead-Only group, Click OK to add the group, then click OK once more
to confirm the groups.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
705 of 950

10. In the same Add Remote Access Policy dialog box as before, click Next.
11. Select Grant remote access permission, and click Next.
706 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

12. Click Edit Profile.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
707 of 950

13. In the Edit Dial-in Profile dialog box, select the Authentication tab.
Select the type of authentication you are using: CHAP and PAP.
708 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

14. Select the Advanced tab, and click Add.
15. In the RADIUS attributes list, find and double-click the line beginning
with Vendor-Specific.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
709 of 950

16. In the Multivalued Attribute Information dialog box, click Add and
enter the following:
Enter vendor code 22610 (for A10 Networks)
Conforms to RADIUS RFC Yes
710 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

17. Click Configure Attribute, and enter the following information:
Vendor-assigned attribute number 2
Attribute format Decimal
Attribute value 1
Attribute value 1 is read-only. Attribute value 2 is read-write.
Note:
18. Click OK for the Configure VSA, Vendor-Specific Attribute Information, and Multivalued Attribute Information dialog boxes.
19. Click Close in the Add Attributes dialog box.
20. Click OK in the Edit Dial-In Profile dialog box. Optionally, read the
suggested help by clicking OK.
21. Click Finish in the Add Remote Access Policy dialog box.
22. To create the second Remote Access Policy, repeat the above steps with
the following changes:
Policy Friendly name AX-Admin-Read-Write-Policy
Group to add AX-Admin-Read-Write
Attribute value 2
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
711 of 950
Add AD Users to AX Access Groups

1. In the Active Directory management console, add the AX access group
to the user, tester1:
712 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

2. Make sure Remote Access Permission is enabled:
Register the IAS Server in Active Directory

The IAS RADIUS server must be registered with AD. Otherwise, RADIUS
will use compatibility mode instead of AD to authenticate users.
1. Open the IAS main window.
2. Click Action on the menu bar, and click register server on active directory.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
713 of 950
Configure RADIUS in the AX Device

Add the RADIUS server (IAS server) to the AX device. Make sure the
shared secret is the same as the one specified for the RADIUS client configured for the AX server on the IAS server.
AX(config)#radius server 192.168.230.10 secret shared-secret
AX(config)#authentication type local radius
Note:
192.168.230.10 is the IP address of w2003-10.com, and shared-secret is

the secret entered in the step 5 in Configure RADIUS Client for AX
Device on page 700.
Test the Configuration

1. Access the AX CLI command prompt.
2. Enter the login name, in the following format:
user-name@AD-domain-name
In this example, use tester1@w2003-10.com.
3. Enter the password.
4. Press Enter.
714 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

DDoS Protection
Traffic Security Features

AX Series devices support the following advanced security features:
DDoS protection
SYN Cookies
ICMP rate limiting
Source-IP based connection rate limiting
DNS security
Policy-based SLB (PBSLB)
Geo-location-based access control for virtual IPs (VIPs)
The following sections describe these features and show how to configure
them.
IP limiting provides a more robust version of the source-IP based connection rate limiting feature. For information, see IP Limiting on page 777.
Note:
DDoS Protection
AX Series devices provide enhanced protection against distributed denialof-service (DDoS) attacks, with IP anomaly filters. The IP anomaly filters
drop packets that contain common signatures of DDoS attacks.
On models AX 2200, AX 3100, AX 3200, AX 5100, and AX 5200,
DDoS protection is hardware-based. On other models, DDoS protection is
software-based.
Note:
DDoS detection applies only to Layer 3, Layer 4, and Layer 7 traffic.

Layer 2 traffic is not affected by the feature.
All IP anomaly filters except IP-option apply to IPv4 and IPv6. The
IP-option filter applies only to IPv4.
You can enable the following DDoS filters. All filters are supported for
IPv4. All filters except IP-option are supported for IPv6.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
715 of 950

DDoS Protection
Frag Drops all IP fragments, which can be used to attack hosts running
IP stacks that have known vulnerabilities in their fragment reassembly

code
IP-option Drops all packets that contain any IP options
Land-attack Drops spoofed SYN packets containing the same IP
address as the source and destination, which can be used to launch an

IP land attack
Ping-of-death Drops all jumbo IP packets, known as ping of death
packets
Note:
On models AX 1000, AX 2000, AX 2100, AX 2500, AX 2600, and

AX 3000, the ping-of-death option drops all IP packets longer than
32000 bytes. On models AX 2200, AX 3100, AX 3200, AX 5100, and
AX 5200, the option drops IP packets longer than 65535 bytes.
TCP-no-flag Drops all TCP packets that do not have any TCP flags set
TCP-SYN-FIN Drops all TCP packets in which both the SYN and FIN
flags are set

TCP-SYN-frag Drops incomplete (fragmented) TCP Syn packets,
which can be used to launch TCP Syn flood attacks

IP Anomaly Filters for System-Wide PBSLB
The following IP anomaly filters are supported specifically for system-wide
PBSLB:
Invalid HTTP or SSL payload
Zero-length TCP window
Out-of-sequence packet
When these filters are enabled, the AX device checks for these anomalies in
new HTTP or HTTPS connection requests from clients.
Filtering for these anomalies is disabled by default. However, if you configure a system-wide PBSLB policy, the filters are automatically enabled. You
also can configure the filters on an individual basis.
Note:
In the current release, these filters are supported only for HTTP and
HTTPS traffic.
(For information about system-wide PBLSB, see Configuring SystemWide PBSLB on page 754.)
716 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

DDoS Protection
Enabling DDoS Protection

To enable DDoS protection, use either of the following methods.
USING THE GUI

2. On the menu bar, select Global > DDoS Protection.
3. Select each type of DDoS protection filter to enable.
To enable all of them, select Drop All.
4. Click OK.
USING THE CLI

Use the following command at the global Config level of the CLI:
ip anomaly-drop {drop-all | frag | ip-option |
land-attack | ping-of-death | tcp-no-flag | tcpsyn-fin | tcp-syn-frag}
You can enable the following options individually or specify drop-all to
enable all the options:
As an example, the following command enables DDoS protection against
ping-of-death attacks:
AX(config)#ip anomaly-drop ping-of-death
Configuring IP Anomaly Filters for System-Wide PBSLB

To configure the IP anomaly filters for system-wide PBSLB, use the following commands at the global configuration level of the CLI:
[no] ip anomaly-drop out-of-sequence [threshold]
[no] ip anomaly-drop zero-window [threshold]
[no] ip anomaly-drop bad-content [threshold]
The threshold option is valid only for the new anomaly filters described in
this section. The option does not apply to other IP anomaly filters.
Note:
Threshold
Each of these IP anomaly filters has a configurable threshold. The threshold
specifies the number of times the anomaly is allowed to occur in a clients
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
717 of 950

SYN Cookies
connection requests. If a client exceeds the threshold, the AX device applies
the system-wide PBSLB policys over-limit action to the client.
The threshold can be set to 1-127 occurrences of the anomaly. The default is
10.
Note:
The thresholds are not tracked by PBSLB policies bound to individual

virtual ports.
SOCKSTRESS_CHECK Session State
While the AX device is checking a data packet against the new IP anomaly
filters, the clients session is in the SOCKSTRESS_CHECK state. You
might see this state if you are viewing debug output for the clients session.
Displaying and Clearing IP Anomaly Statistics

USING THE CLI\
Select Monitor > Service > Application > Switch.
USING THE CLI

To display IP anomaly statistics, use the following command:
show slb l4
For system-wide PBSLB, you also can use the following command:
show pbslb client [ipaddr]
In the output of this command, the counters for a dynamic client are reset to
0 when a clients dynamic entry ages out.
To clear all Layer 4 SLB statistics, including the IP anomaly counters, use
clear slb l4
SYN Cookies
AX Series devices provide enhanced protection against TCP SYN flood
attacks, with SYN cookies. SYN cookies enable the AX to continue to serve
legitimate clients during a TCP SYN flood attack, without allowing illegitimate traffic to consume system resources.
718 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SYN Cookies
The AX device supports SYN cookies for Layer 4-7 SLB traffic and for
Layer 2/3 traffic.
Layer 4-7 SYN cookies protect against TCP SYN flood attacks directed
at SLB service ports.

Layer 2/3 SYN cookies protect against TCP SYN flood attacks
attempted in traffic passing through the AX device.
The Service Provided By SYN Cookies

SYN cookies enable the AX device to continue to serve legitimate clients
during a TCP SYN flood attack, without allowing illegitimate traffic to consume system resources.
During a TCP SYN flood attack, an attacker sends a large series of TCP
SYN Requests but does not acknowledge the SYN ACKs that the AX sends
in reply. Normally, these half-completed connections can eventually cause
the AX device's TCP connection queue to become full, which prevents the
AX from establishing new connections for legitimate clients.
When SYN cookies are enabled, the feature prevents the AX devices TCP
connection queue from filling up during TCP SYN flood attacks. Instead of
leaving a half-completed TCP connection in the queue, the AX replies to
each SYN Request with a SYN cookie, which is a special type of SYN
ACK, and does not leave a connection in the queue. If the SYN Request is
from a legitimate client, the client sends an ACK in response to the SYN
cookie. The AX reconstructs the clients connection information based on
information in the SYN ACK, and establishes a connection for the client.
However, if the SYN Request is part of an attack, the attacker does not send
an ACK, and the AX therefore does not establish a connection.
Dynamic SYN Cookies
You can configure the on and off thresholds for SYN cookie use by the AX
device. The benefit of this feature is that when there is no TCP SYN attack,
TCP options are preserved.
You can configure the following dynamic SYN cookie options:
On-threshold specifies the maximum number of concurrent half-
open TCP connections allowed on the AX device, before SYN

cookies are enabled. If the number of half-open TCP connections
exceeds the on-threshold, the AX device enables SYN cookies. You
can specify 0-2147483647 half-open connections.
Off-threshold option specifies the minimum number of concurrent
half-open TCP connections for which to keep SYN cookies enabled.
If the number of half-open TCP connections falls below this level,
SYN cookies are disabled. You can specify 0-2147483647 halfopen connections.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
719 of 950

SYN Cookies
Hardware-based SYN cookies are disabled by default. When the feature is
enabled, there are no default settings for the on and off thresholds. If you
omit the on-threshold and off-threshold options, SYN cookies are enabled
and are always on regardless of the number of half-open TCP connections
present on the AX device.
Note:
It may take up to 10 milliseconds for the AX device to detect and respond

to crossover of either threshold.
Hardware-Based or Software-Based
Depending on the AX model, you can use hardware-based SYN cookies or
software-based SYN cookies:
Hardware-based SYN cookies can be globally enabled and apply to all
virtual server ports configured on the device. Hardware-based SYN

cookies are available on the AX 2200, AX 3100, AX 3200, AX 5100,
and AX 5200.
Software-based SYN cookies can be enabled on individual virtual ports.
This version of the feature is available on all AX models.

Note:
Hardware-based SYN cookies are a faster, easier-to-configure alternative

to the software-based SYN cookie feature available on all AX platforms.
If your AX model supports hardware-based SYN cookies, A10 Networks
recommends that you use the hardware-based version of the feature
instead of the software-based version of the feature.
If both hardware-based and software-based SYN cookies are enabled,
only hardware-based SYN cookies are used. You can leave softwarebased SYN cookies enabled but they are not used.
Note:
If the target VIP is in a different subnet from the client-side router, use of
hardware-based SYN cookies requires some additional configuration. See
Configuration when Target VIP and Client-side Router Are in Different
Subnets on page 721.
Enabling Hardware-Based SYN Cookies

To enable hardware-based SYN cookies, use following CLI method.
USING THE GUI

2. On the menu bar, select Global > Settings.
720 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SYN Cookies
3. Select Enabled next to SYN Cookie.
4. In the On Threshold field, enter the maximum number of concurrent
half-open TCP connections allowed on the AX device, before SYN
cookies are enabled.
5. In the Off Threshold field, enter the minimum number of concurrent
half-open TCP connections for which to keep SYN cookies enabled.
6. Click OK.
USING THE CLI

To enable hardware-based SYN cookies, use the following command at the
[no] syn-cookie
[on-threshold num off-threshold num]
The command in the following example enables dynamic-based SYN cookies when the number of concurrent half-open TCP connections exceeds
50000, and disables SYN cookies when the number falls below 30000:
AX(config)#syn-cookie on-threshold 50000 off-threshold 30000
Configuration when Target VIP and Client-side Router Are in Different Subnets
Usually, the target VIP in an SLB configuration is in the same subnet as the
client-side router. However, if the target VIP is in a different subnet from the
client-side router, use of hardware-based SYN cookies requires some additional configuration:
On the AX device, configure a dummy VIP that is in the same subnet
as the client-side router.

On the client-side router, configure a static route to the VIP, using the
dummy VIP as the next hop.

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
721 of 950

SYN Cookies
FIGURE 176 Hardware-based SYN Cookies Target VIP and Client-side
Router in Different Subnets
The following commands configure hardware-based SYN cookies on the

AX device in this example:
AX(config)#slb virtual-server dummyvip 10.10.10.154
AX(config-slb virtual server)#exit
AX(config)#syn-cookie
Note:
If HA is configured, add both the target VIP and the dummy VIP to the
same HA group, so they will fail over to the HA peer as a unit.
Enabling Software-Based SYN Cookies

If you are using an AX model that does not support hardware-based SYN
cookies, you can still enable the software-based version of the feature, for
individual virtual ports.
USING THE GUI

1. Select Config> Service > Server.
722 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SYN Cookies
3. Click on an existing virtual server name or click Add.
4. Enter or edit the information in the General section.
5. In the Port section, select the TCP port and click Edit, or click Add.
6. If you are configuring a new port, select TCP in the Type drop-down
list.
7. Select Enabled next to SYN Cookie.
8. Enter or edit other values as needed for your configuration.
9. Click OK.
10. Click OK again to save the new or changed virtual server.
USING THE CLI

To enable software-based SYN cookies, use the following command at the
configuration level for the virtual port on the virtual server:
syn-cookie [sack]
For information about the sack feature, see the AX Series CLI Reference.
Configuring Layer 2/3 SYN Cookie Support

To configure Layer 2/3 SYN cookie support:
1. Enable Layer 2/3 SYN cookies on individual interfaces.
2. Optionally, modify the threshold for TCP handshake completion.
USING THE CLI

1. To enable Layer 2/3 SYN cookies on an interface, use the following
command at the configuration level for the interface:
[no] ip tcp syn-cookie
The feature is disabled by default.
2. Optionally, to modify the threshold for TCP handshake completion, use
[no] ip tcp syn-cookie threshold seconds
You can specify 1-100 seconds. The default is 4 seconds.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
723 of 950

ICMP Rate Limiting
CLI Example
The following commands globally enable SYN cookie support, then enable
Layer 2/3 SYN cookies on Ethernet interfaces 4 and 5:
AX(config)#syn-cookie on-threshold 50000 off-threshold 30000
AX(config-if: ethernet4)#ip tcp syn-cookie
AX(config-if: ethernet4)#interface ethernet 5
AX(config-if: ethernet5)#ip tcp syn-cookie
ICMP Rate Limiting

ICMP rate limiting protects the AX device against denial-of-service (DoS)
attacks such as Smurf attacks, which consist of floods of spoofed broadcast
ping messages.
ICMP rate limiting monitors the rate of ICMP traffic and drops ICMP packets when the configured thresholds are exceeded.
You can configure ICMP rate limiting filters globally, on individual Ethernet interfaces, and in virtual server templates. If you configure ICMP rate
limiting filters at more than one of these levels, all filters are applicable.
ICMP Rate Limiting Parameters
IMCP rate limiting filters consist of the following parameters:
Normal rate The ICMP normal rate is the maximum number of ICMP
packets allowed per second. If the AX device receives more than the
normal rate of ICMP packets, the excess packets are dropped until the
next one-second interval begins. The normal rate can be 1-65535 packets per second.
Maximum rate The IMCP maximum rate is the maximum number of
ICMP packets allowed per second before the AX device locks up ICMP
traffic. When ICMP traffic is locked up, all ICMP packets are dropped
until the lockup expires. The maximum rate can be 1-65535 packets per
second.
Lockup time The lockup time is the number of seconds for which the
AX device drops all ICMP traffic, after the maximum rate is exceeded.
The lockup time can be 1-16383 seconds.
Specifying a maximum rate (lockup rate) and lockup time is optional. If you
do not specify them, lockup does not occur.
Note:
724 of 950
The maximum rate must be larger than the normal rate.

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

ICMP Rate Limiting
USING THE GUI

To globally configure ICMP rate limiting:
1. Select Config > Network > ICMP Rate Limiting.
2. Select the ICMP Rate Limiting checkbox to activate the configuration
fields.
3. Enter the normal rate in the Normal Rate field.
4. Enter the maximum rate in the Lockup Rate field.
5. Enter the lockup time in the Lockup Period field.
6. Click OK.
To configure ICMP rate limiting on an individual Ethernet interface:
2. Click on the interface name to display the configuration sections for it.
3. Select the ICMP Rate Limiting checkbox to activate the configuration
fields.
7. Click OK.
To configure ICMP rate limiting in a virtual server template:
2. On the menu bar, select Template > Virtual Server.
The Virtual Server section appears.
4. Select the ICMP Rate Limit Status checkbox to enable the configuration
fields.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
725 of 950

Source-IP Based Connection Rate Limiting
6. To configure the lockup time, click Lockup Status.
9. Click OK.
USING THE CLI

To configure an ICMP rate-limiting filter, use the following command. You
can enter this command at the global configuration level, the configuration
level for a physical or virtual Ethernet interface, or the configuration level
for a virtual server template.
[no] icmp-rate-limit normal-rate lockup max-rate
lockup-time
For descriptions of the parameters, see ICMP Rate Limiting Parameters
on page 724.
To display ICMP rate limiting information, use the following commands:
show icmp
show interfaces
show slb virtual-server server-name detail
CLI Example
The following commands configure a virtual server template that sets ICMP
rate limiting:
AX(config)#slb template virtual-server vip-tmplt
AX(config-vserver)#icmp-rate-limit 25000 lock 30000 60

Source-IP based connection rate limiting protects the system from excessive
connection requests from individual clients. This feature can be enabled on
a global basis. The feature applies only to SLB virtual ports.
Note:
726 of 950
IP limiting provides a more robust version of the source-IP based connection rate limiting feature. For information, see IP Limiting on page 777.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameters
Source-IP based connection rate limiting is configured using the following
parameters:
TCP or UDP Layer 4 protocol for the connections.
Connection limit Maximum number of connection requests allowed
from a client, within the limit period. The connection limit can be
1-1000000.
Limit period Interval to which the connection limit is applied. A client
is conforming to the rate limit if the number of new connection requests

within the limit period does not exceed the connection limit.
The limit period can be one of the following:
100 milliseconds (one tenth of a second)
1000 milliseconds (one second)
Scope Specifies whether the connection limit applies separately to
each virtual port, or is applied as an aggregate to all virtual ports. By

default, the connection limit applies separately to each individual virtual
port. (See Deployment Considerations on page 728 for more information.)
Exceed actions Actions to take when the connection limit is exceeded.
All connection requests in excess of the connection limit that are

received from a client within the limit period are dropped. This action is
enabled by default when you enable the feature, and can not be disabled.
You can enable one or both of the following additional exceed actions:
Logging Generates a log message when a client exceeds the connection limit.
Lockout Locks out the client for a specified number of seconds.
During the lockout period, all connection requests from the client
are dropped. The lockout period can be 1-3600 seconds (1 hour).
By default, logging and lockout are both disabled.
Log Messages
The AX device generates two log messages per offending client, per client
activity.
The first message is generated the first time a client exceeds the connection
limit. The message indicates the source (client) address and the destination
address of the session. If lockout is configured, the message also indicates
that the client is locked out.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
727 of 950

The second message is generated after the client activity for that period.
This message indicates the number of times the client exceeded the connection limit. If lockout is enabled, the message also indicates the number of
requests that were dropped during lockout.
Message Examples No Lockout Configured
Here is an example of the pair of log messages generated by this feature for
an offending client, if lockout is not configured.
Mar 05 2009 14:55:59 Notice [AX]: UDP 53.12.3.82 > 51.1.1.2:53
nection rate limit dropped this packet
Mar 05 2009 14:37:00 Notice [AX]: UDP 51.2.1.81 > 51.1.1.2:53
exceeded Connection rate limit in all (8654 times)
Source IP ConSource IP
In this example, the session is between client 53.12.3.82 and destination

51.1.1.2:53. During this period of activity, 8654 of the requests from the client were sent after a connection limit had been exceeded, and were dropped.
Message Examples With Lockout Configured
Here is an example of how the messages look if lockout is configured.
Mar 05 2009 14:34:57 Notice [AX]: UDP 53.12.3.82 > 51.1.1.2:53
nection rate limit dropped this packet (locked out)
Source IP Con-
Mar 05 2009 14:37:00 Notice [AX]: UDP 51.2.1.81 > 51.1.1.2:53 Source IP
exceeded Connection rate limit in all (897 times, 2342 times in lockout)
In this example, the session is between the same client and destination as the
previous example. During this period of activity, 897 of the requests from
the client were sent after a connection limit had been exceeded, and were
dropped. An additional 2342 requests were dropped because they were
received during the lockout.
Deployment Considerations
The AX device internally uses a session to keep track of user activity. Currently, the AX device has a capacity of up to 16 million sessions. Up to 8
million of these sessions are available for tracking user activity.
Depending on client profile and activity, as well as the number of virtual
ports configured on the device, you might need to use the shared option to
apply the connection limit to all virtual ports, instead of each individual
port. The default is to apply the connection limit to each individual virtual
port, which uses proportionally more sessions than the shared option.
728 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Recommendation for Logging
If you plan to enable logging for this feature, A10 Networks recommends
using an external log server. Log traffic can be heavy during an attack.
Recommendations for DNS Load Balancing
If you plan to use this feature with DNS load balancing, A10 Networks recommends the following:
Increase the maximum number of Layer 4 sessions. To increase the
maximum number of Layer 4 sessions the system can have, use the following CLI command at the global configuration level of the CLI:
system resource-usage l4-session-count num
The num option specifies the number of Layer 4 sessions.
Use a short UDP aging time. To set a short UDP aging time, use the fol-
lowing command at the configuration level for the UDP template to

which you plan to bind the DNS virtual port(s):
aging short [seconds]
The seconds option specifies the number of seconds to wait before terminating UDP sessions. If you omit the seconds option, sessions are terminated after the SLB maximum session life (MSL) time expires, after a
request is received and sent out to the server. (The MSL timer is a globally configurable SLB option. For more information, see the AX Series
CLI Reference or AX Series GUI Reference.)
Configuration
The current release does not support configuration or monitoring of this
feature using the GUI.
Note:
To configure source-IP based connection rate limiting, use the following

slb conn-rate-limit src-ip {tcp | udp}
conn-limit per {100 | 1000}
[shared]
[exceed-action [log] [lock-out lockout-period]]
The tcp | udp option specifies the Layer 4 protocol.
The conn-limit option specifies the connection limit and can be 1-1000000.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
729 of 950

The per {100 | 1000} option specifies the limit period, either 100 milliseconds or 1000 milliseconds.
The shared option specifies that the connection limit applies in aggregate to
all virtual ports. If you omit this option, the limit applies separately to each
virtual port.
The exceed-action options enable optional exceed actions:
The log option enables logging.
The lock-out lockout-period option enables lockout. The lockout period
can be 1-3600 seconds (1 hour).

To display statistics for this feature, use the following command:
show slb conn-rate-limit src-ip statistics
To clear statistics for this feature, use the following command:
clear slb conn-rate-limit src-ip statistics
CLI Example 1
The following command allows up to 1000 TCP connection requests per
one-second interval from any individual client. If a client sends more than
1000 requests within a given limit period, the client is locked out for 3 seconds. The limit applies separately to each individual virtual port. Logging is
not enabled.
AX(config)#slb conn-rate-limit src-ip tcp 1000 per 1000 exceed-action lock-out
3
CLI Example 2
The following command allows up to 2000 UDP connection requests per
100-millisecond interval. The limit applies to all virtual ports together. Logging is enabled but lockout is not enabled.
AX(config)#slb conn-rate-limit src-ip udp 2000 per 100 shared exceed-action log
CLI Example 3
The following command allows up to 2000 UDP connection requests per
100-millisecond interval. The limit applies to all virtual ports together. Logging is enabled and lockout is enabled. If a client sends a total of more than
730 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

DNS Security
2000 requests within a given limit period, to one or more virtual ports, the
client is locked out for 3 seconds.
AX(config)#slb conn-rate-limit src-ip udp 2000 per 100 shared exceed-action log
lock-out 3
Statistics
The following commands display statistics for this feature, then reset the
counters to 0 and verify that they have been reset:
AX(config)#show slb conn-rate-limit src-ip statistics
Threshold check count 1022000
Honor threshold
count 20532
Threshold exceeded count 1001408

Lockout drops 60
Log messages sent 20532
DNS requests re-transmitted
1000
No DNS response for request 1021000

AX(config)#clear slb conn-rate-limit src-ip statistics
AX(config)#show slb conn-rate-limit src-ip statistics
Threshold check count 0
Honor threshold
count 0
Threshold exceeded count 0

Lockout drops 0
Log messages sent 0
DNS requests re-transmitted
No DNS response for request
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
731 of 950

DNS Security
This feature parses DNS queries based on following RFCs:
RFC 1034: Domain Names Concepts and Facilities
RFC 1035: Domain Names Implementation and Specification
RFC 2671 Extension Mechanisms for DNS (EDNS0)
To configure DNS security for a DNS virtual port:

1. Create a DNS template and specify the DNS security action in the template.
2. Bind the DNS template to the DNS virtual port.
Note:
DNS templates are a new type of template in AX Release 2.4.
USING THE GUI

2. On the menu bar, select Application > DNS.
4. If creating a new template, enter the name.
5. Select Malformed Query.
6. 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.

7. Click OK.
USING THE CLI

To configure DNS security, use the following command at the global configuration level of the CLI:
[no] slb template dns template-name
This command creates the UDP template and changes the CLI to the configuration 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}
732 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The drop option drops malformed queries. The forward option sends the
queries to the specified service group. With either option, the malformed
queries are not sent to the DNS virtual port.
CLI Example
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
AX(config)#slb virtual-server dnsvip1 192.168.1.53
AX(config-slb vserver)#port 53 udp
AX(config-slb vserver-vport)#template dns dns-sec
Since the drop action is specified, malformed DNS queries sent to the virtual DNS server are dropped by the AX device.

You can use Access Control Lists (ACLs) to permit or deny packets based
on address and protocol information in the packets. AX devices support the
following types of ACLs:
Standard IPv4 ACL Standard IPv4 ACLs filter based on source IPv4
address.
Extended IPv4 ACL Extended IPv4 ACLs filter based on source and
destination IPv4 addresses, IP protocol, and TCP/UDP port numbers.

Extended IPv6 ACL Extended IPv6 ACLs filter based on source and
destination IPv6 addresses, IP protocol, and TCP/UDP port numbers.
How ACLs Are Used

You can use ACLs for the following tasks:
Permit or block through traffic.
Permit or block management access.
Specify the internal host or subnet addresses to which to provide Net-
work Address Translation (NAT).
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
733 of 950

An ACL can contain multiple rules. Each rule contains a single permit or
deny statement. Rules are added to the ACL in the order you configure
them. The first rule you add appears at the top of the ACL.
Rules are applied to the traffic in the order they appear in the ACL (from the
top, which is the first rule, downward). The first rule that matches traffic is
used to permit or deny that traffic. After the first rule match, no additional
rules are compared against the traffic.
Access lists do not take effect until you apply them.
To permit or block through traffic on an interface, apply the ACL to the
interface. (See Applying an ACL to an Interface on page 746.)

To permit or block through traffic on a virtual server port, apply the
ACL to the virtual port. (See Applying an ACL to a Virtual Server

Port on page 747.)
To permit or block management access, use the ACL with the enable-
management command. (See Securing Admin Access by Ethernet on

page 677.)
To specify the internal host or subnet addresses to which to provide
NAT, use the ACL when configuring the pool. (See Network Address
Translation on page 607.)
Configuring Standard IPv4 ACLs

To configure a standard IPv4 ACL, use either of the following methods.
USING THE GUI

1. Select Config > Network > ACL.
2. Select Standard on the menu bar.
3. Click Add.
4. Enter or select the values to filter. (For descriptions, see the CLI syntax
below.)
5. Click OK. The new ACL appears in the Standard ACL table.
6. Click OK to commit the change.
734 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

To configure a standard ACL, use the following command:
access-list acl-num [seq-num]
{permit | deny | remark string}
[log [transparent-session-only]]
The acl-num specifies the ACL number, from 1-99.
The seq-num option specifies the sequence number of this rule in the ACL.
(See Resequencing ACL Rules on page 748.)
The deny | permit option specifies the action to perform on traffic that
matches the ACL:
deny Drops the traffic.
permit Allows the traffic.
The remark option adds a remark to the ACL. (For more information, see
Adding a Remark to an ACL on page 743.)
The source address to match on is specified by one of the following:
any The ACL matches on all source IP addresses.
host host-src-ipaddr The ACL matches only on the specified host IP
address.
net-src-ipaddr {filter-mask | /mask-length} The ACL matches on any
host in the specified subnet. The filter-mask specifies the portion of the
address to filter:
Use 0 to match.
Use 255 to ignore.
For example, the following filter-mask filters on a 24-bit subnet: 0.0.0.255
Alternatively, you can use mask-length to specify the portion of the address
to filter. For example, you can specify /24 instead 0.0.0.255 to filter on
a 24-bit subnet.
The log option configures the AX device to generate log messages when
traffic matches the ACL. This option is disabled by default. The transparent-session-only option limits logging for an ACL rule to creation and deletion of transparent sessions for traffic that matches the ACL rule. (See
Transparent Session Logging on page 744.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
735 of 950

When ACL logging is enabled, the AX device writes the log messages to
the local logging buffer. If you configure an external log server, the AX
device also sends the messages to the server. For more information, see
Log Rate Limiting on page 48.
Note:
If you plan to use an external log server, the server must be attached to an
AX data port in order for ACL logging messages to reach the server. They
will not reach the server if the server is attached to the AX management
port.
CLI EXAMPLE
The following commands configure a standard ACL to deny traffic sent
from subnet 10.10.10.x, and apply the ACL to inbound traffic received on
Ethernet interface 4:
AX(config)#access-list 1 deny 10.10.10.0 0.0.0.255
AX(config-if:ethernet4)#access-list 1 in
Configuring Extended IPv4 ACLs

To configure an extended IPv4 ACL, use either of the following methods.
USING THE GUI

2. Select Extended on the menu bar.
3. Click Add.
below.)
5. Click OK. The new ACL appears in the Extended ACL table.
736 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

To configure an extended ACL, use the following commands.
Syntax for Filtering on Source and Destination IP Addresses
[no] access-list acl-num [seq-num]
{permit | deny | remark string} ip
The acl-num specifies the ACL number, from 100-199.
The seq-num option specifies the sequence number of this rule in the ACL.
(See Resequencing ACL Rules on page 748.)
The deny | permit option specifies the action to perform on traffic that
matches the ACL:
The remark option adds a remark to the ACL. (For more information, see
Adding a Remark to an ACL on page 743.)
The source address to match on is specified by one of the following:
any The ACL matches on all source IP addresses.
host host-src-ipaddr The ACL matches only on the specified host IP
address.
net-src-ipaddr {filter-mask | /mask-length} The ACL matches on any
host in the specified subnet. The filter-mask specifies the portion of the
address to filter:
Use 0 to match.
Use 255 to ignore.
For example, the following filter-mask filters on a 24-bit subnet: 0.0.0.255
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
737 of 950

Alternatively, you can use mask-length to specify the portion of the address
to filter. For example, you can specify /24 instead 0.0.0.255 to filter on
a 24-bit subnet.
The options for specifying the destination address are the same as those for
specifying the source address.
The log option configures the AX device to generate log messages when
traffic matches the ACL. This option is disabled by default. The transparent-session-only option limits logging for an ACL rule to creation and deletion of transparent sessions for traffic that matches the ACL rule. (See
Transparent Session Logging on page 744.)
When ACL logging is enabled, the AX device writes the log messages to
the local logging buffer. If you configure an external log server, the AX
device also sends the messages to the server. For more information, see
Log Rate Limiting on page 48.
Note:
If you plan to use an external log server, the server must be attached to an
AX data port in order for ACL logging messages to reach the server. They
will not reach the server if the server is attached to the AX management
port.
Syntax for Filtering on ICMP Traffic
{permit | deny | remark string} icmp
[type icmp-type [code icmp-code]]
The type and code options enable you to filter on ICMP traffic.
The type type-option option matches based on the specified ICMP type.
You can specify one of the following. Enter the type name or the type number (for example, dest-unreachable or 3). The type-option can be one of the
following:
any-type Matches on any ICMP type.
dest-unreachable | 3 Type 3, destination unreachable
738 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

echo-reply | 0 Type 0, echo reply
echo-request | 8 Type 8, echo request
info-reply | 16 Type 16, information reply
info-request | 15 Type 15, information request
mask-reply | 18 Type 18, address mask reply
mask-request | 17 Type 17, address mask request
parameter-problem | 12 Type 12, parameter problem
redirect | 5 Type 5, redirect message
source-quench | 4 Type 4, source quench
time-exceeded | 11 Type 11, time exceeded
timestamp | 13 Type 13, timestamp
timestamp-reply | 14 Type 14, timestamp reply
type-num ICMP type number, 0-254
The code code-num option matches based on the specified ICMP code. To
match on any ICMP code, specify any-code. To match on a specific ICMP
code, specify the code, 0-254.
Syntax for Filtering on Source and Destination IP Addresses and
on TCP or UDP Protocol Port Numbers
{permit | deny | remark string} {tcp | udp}
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
739 of 950

The tcp and udp options enable you to filter on protocol port numbers. Use
one of the following options to specify the source port(s) on which to filter:
eq src-port The ACL matches on traffic from the specified source
port.
gt src-port The ACL matches on traffic from any source port with a
higher number than the specified port.

lt src-port The ACL matches on traffic from any source port with a
lower number than the specified port.

range start-src-port end-src-port The ACL matches on traffic from
any source port within the specified range.

The same options can be used to specify the destination port(s) on which to
filter.
CLI EXAMPLE
The following commands configure an extended IPv4 ACL to deny traffic
sent from subnet 10.10.10.x to 10.10.20.5:80, and apply the ACL to
inbound traffic received on Ethernet interface 7:
AX(config)#access-list 100 deny tcp 10.10.10.0 0.0.0.255 10.10.20.5 /32 eq 80
Configuring Extended IPv6 ACLs

To configure an extended IPv4 ACL, use either of the following methods.
USING THE GUI

2. Select IPv6 on the menu bar.
3. Click Add.
below.)
5. Click OK. The new ACL appears in the IPv6 ACL table.
740 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

To configure an IPv6 ACL, use the following commands:
[no] ipv6 access-list acl-id
Enter this command at the global configuration level of the CLI. The acl-id
can be a string up to 16 characters long. This command changes the CLI to
the configuration level for the ACL, where the following ACL-related commands are available.
The permit | deny Command
This command specifies the action to take for traffic that matches the ACL,
specifies the source and destination addresses upon which to perform the
action, and optionally, enables logging.
[no] [seq-num] {permit | deny} {ipv6 | icmp}
{any | host host-src-ipv6addr |
net-src-ipv6addr /mask-length}
{any | host host-dst-ipv6addr |
net-dst-ipv6addr /mask-length}
or
[no] {permit | deny} {tcp | udp}
{any | host host-src-ipv6addr |
net-src-ipv6addr /mask-length}
{any | host host-dst-ipv6addr |
net-dst-ipv6addr /mask-length}
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
741 of 950

Parameter
Description
seq-num
Sequence number of this rule in the ACL. You

can use this option to resequence the rules in the
ACL.
deny | permit
Action to take for traffic that matches the ACL.

ipv6 | icmp
Filters on IPv6 or ICMP packets.
tcp | udp
Filters on TCP or UDP packets. The tcp and udp

options enable you to filter on protocol port numbers.
any |
host host-srcipv6addr |
net-srcipv6addr /masklength
Source IP address(es) to filter.
any The ACL matches on all source IP
addresses.
host host-src-ipv6addr The ACL
matches only on the specified host IPv6 address.
net-src-ipv6addr /mask-length The
ACL matches on any host in the specified subnet.
The mask-length specifies the portion of the
address to filter.
eq src-port |
gt src-port |
lt src-port |
range startsrc-port
end-src-port
For tcp or udp, the source protocol ports to filter.

eq src-port The ACL matches on traffic
from the specified source port.
gt src-port The ACL matches on traffic
from any source port with a higher number than
the specified port.
lt src-port The ACL matches on traffic
from any source port with a lower number than
the specified port.
742 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

range start-src-port end-src-port
The ACL matches on traffic from any source
port within the specified range.
any |
host host-dstipv6addr |
net-dstipv6addr /masklength
Destination IP address(es) to filter.
eq dst-port |
gt dst-port |
lt dst-port |
range startdst-port
end-dst-port
log
[transparentsession-only]
For tcp or udp, the destination protocol ports to

filter.
Configures the AX device to generate log messages when traffic matches the ACL.
The transparent-session-only option limits logging for an ACL rule to creation and deletion of
transparent sessions for traffic that matches the
ACL rule. (See Transparent Session Logging
on page 744.)
The remark Command

The remark command adds a remark to the ACL. The remark appears at
the top of the ACL when you display it in the CLI. Here is the syntax:
[no] remark string
The string can be 1-63 characters. To use blank spaces in the remark,
enclose the entire remark string in double quotes.
Adding a Remark to an ACL

You can add a remark to an ACL. The remark appears at the top of the ACL
when you display it in the CLI, or next to the ACL in the ACL tables displayed in the GUI.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
743 of 950

Here is a CLI example:
AX(config)#access-list 42 permit host 192.168.1.42
AX(config)#access-list 42 deny 192.168.1.0 /24
AX(config)#access-list 42 remark "The meaning of life"
AX(config)#show access-list ipv4 42
Access List 42 "The meaning of life"
access-list 42 10 permit host 192.168.1.42
Hits: 0
access-list 42 20 deny 192.168.1.0 0.0.0.255
Hits: 0
As shown in this example, the remark appears at the top of the ACL, above
the first rule.
To use blank spaces in the remark, enclose the entire remark string in double
quotes, as shown in the example. The ACL must already exist before you
can configure a remark for it.
Transparent Session Logging

The transparent-session-only option limits logging for an ACL rule to creation and deletion of transparent sessions for traffic that matches the ACL
rule.
A transparent session is a non-SLB Layer 2 or Layer 3 session that the AX
device sets up for traffic that is transiting through the AX device, but is not
initiated or terminated on the device.
Sample Log Messages for Transparent Sessions

The following sections show examples of the log messages generated for
transparent sessions.
IPv4 Sessions
The following example shows the log messages for creation and deletion of
an IPv4 transparent session:
Oct 29 2009 12:00:55 Notice [AX]:[eth 1] TCP 200.200.200.100:32548 >
1.1.1.100:80 ACL rule transparent session expired (ACL 150)
Oct 29 2009 12:00:55 Notice [AX]:[eth 1] TCP 200.200.200.100:32548 >
1.1.1.100:80 ACL rule transparent session created (ACL 150)
The interface on which the ACL matched traffic is indicated in brackets (in
this example, eth 1). The addresses are shown as src-ip:port > dst-ip:port.
The ACL number or ACL name is shown at the end of the message.
744 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IPv6 Sessions
For successfully created TCP or UDP sessions, a separate message is generated when the session is created and when it expires:
Feb 24 2010 02:18:27 Notice [AX]:[ve 21] UDP 2001:10::100:50213 >
2001:7::40:53 ACL rule transparent session expired (IPV6_LIST)
Feb 24 2010 02:18:12 Notice [AX]:[ve 21] UDP 2001:10::100:50213 >
2001:7::40:53 ACL rule transparent session created (IPV6_LIST)
Feb 24 2010 02:15:12 Notice [AX]:[ve 21] TCP 2001:10::100:4401 > 2001:7::40:22
ACL rule transparent session expired (IPV6_LIST)
ACL rule transparent session created (IPV6_LIST)
For all other types of transparent IPv6 sessions, a message is generated if

the packet is forwarded:
Feb 24 2010 02:18:07 Notice [AX]:[ve 21] IP 2001:10::100 > 2001:7::40
rule permitted this packet (IPV6_LIST)
ACL
If a TCP or UDP packet is denied, a message such as the following is generated:

ACL rule transparent session denied (IPV6_LIST)
For all other types of transparent IPv6 sessions, a message such as the following is generated:
Feb 24 2010 02:18:07 Notice [AX]:[ve 21] IP 2001:10::100 > 2001:7::40
rule denied this packet (IPV6_LIST)
ACL
Configuration
To configure session filtering for transparent IPv6 sessions on an interface:
1. Configure an IPv6 ACL that uses the log transparent-session-only
option.
2. Apply the ACL to the interface that receives incoming traffic for the sessions.
3. For the following AX models only, enable the cpu-process option on
the interface that receives incoming traffic for the sessions: AX 2200,
AX 3100, AX 3200, AX 5100, and AX 5200.
CLI Example
The following commands configure an IPv6 ACL for transparent session
logging, and apply it to an IPv6 interface:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
745 of 950

AX(config)#ipv6 access-list tran_sess_log1
AX(config-access-list:trans_sess_log1)#permit tcp any any log transparent-session-only
AX(config-access-list:trans_sess_log1)#exit
AX(config-if:ve21)#ipv6 access-list tran_sess_log1 in
Applying an ACL to an Interface

To apply a configured ACL to an interface, use either of the following methods.
USING THE GUI

To apply an ACL to an Ethernet port:
2. Select LAN on the menu bar.
3. Click on the port number.
4. In the IPv4 section, select the ACL from the Access List field.
5. Click OK.
To apply an ACL to a Virtual Ethernet (VE) interface:
2. Select Virtual on the menu bar.
3. Click on the VE name.
4. Select IPv4.
5. Select the ACL from the Access List field.
6. Click OK.
USING THE CLI

Access the configuration level for the interface and use the following command:
access-list acl-num in
746 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The following commands configure a standard ACL to deny traffic from
subnet 10.10.10.x, and apply the ACL to the inbound traffic direction on
Ethernet interface 4:
AX(config)#access-list 1 deny 10.10.10.0 0.0.0.255
Applying an ACL to a Virtual Server Port

You can apply an ACL to a virtual server port. An ACL applied to a virtual
server port permits or denies traffic just as an ACL applied to a physical
port or Virtual Ethernet (VE) interface does.
To apply a configured ACL to a virtual server port, use either of the following methods.
USING THE GUI

3. Click Add or click on the name of a configured virtual server.
4. Enter or change information in the General section, if you are configuring a new virtual server.
5. In the Port section, click Add or select a port and click Edit.
6. In the Virtual Server Port section, select the ACL from the Access List
drop-down list.
7. Click OK.
8. Click OK again to return to the virtual server table.
USING THE CLI

To apply an ACL to a virtual port in the CLI, use the following command at
the configuration level for the virtual port:
access-list acl-id
The acl-id specifies the ACL number.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
747 of 950

Using an ACL to Control Management Access

To use an ACL to control management access, see Securing Admin Access
by Ethernet on page 677.
Using an ACL for NAT

To use an ACL for NAT, configure the ACL, then use either of the following
methods to bind the ACL to a NAT pool.
USING THE GUI

To bind an ACL to an IP source NAT pool:
1. Select Config > Service > IP Source NAT.
2. Select Binding on the menu bar.
3. Select the ACL number from the ACL drop-down list.
4. Select the pool ID from the NAT Pool drop-down list.
5. Click Add. The new binding appears in the ACL section.
6. Click OK.
USING THE CLI

To use a configured ACL in an IPv4 NAT pool, use the following command:
[no] ip nat inside source
{list acl-name
{pool pool-name | pool-group pool-group-name}
static local-ipaddr global-ipaddr}
The list acl-name option specifies the ACL.
Resequencing ACL Rules

An ACL can contain multiple rules. Each access-list command configures
one rule. Rules are added to the ACL in the order you configure them. The
first rule you add appears at the top of the ACL.
748 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Rules are applied to the traffic in the order they appear in the ACL (from the
top rule, which is the first, downward). The first rule that matches traffic is
used to permit or deny that traffic. After the first rule match, no additional
rules are compared against the traffic.
Each ACL has an implicit deny any rule at the end of the ACL. This rule is
applied to any traffic that does not match any of the configured rules in the
ACL. The deny any rule at the end of the ACL is not displayed and cannot
be removed.
You can resequence the rules in an ACL. When you create an ACL rule, the
AX device assigns a sequence number to the rule and places the rule at the
bottom of the ACL. Here is an example:
AX(config)#access-list 86 deny 10.10.10.0 /24
access-list 86 10 permit host 10.10.10.12 log Hits: 0
access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0
In this example, two rules are configured for ACL 86. The default sequence
numbers are used. The first rule has sequence number 10, and each rule
after that has a sequence number that is higher by 10.
The intent of this ACL is to deny all access from the 10.10.10.x subnet,
except for access from specific host addresses. In this example, the permit
rule for the host appears before the deny rule for the subnet the host is in, so
the host will be permitted. However, suppose another permit rule is added
for another host in the same subnet.
By default, since no sequence number was specified when the rule was configured, the rule is placed at the end of the ACL. Because the deny rule
comes before the permit rule, host 10.10.10.13 will never be permitted.
To resequence the ACL to work as intended, the deny rule can be deleted,
then re-added. Alternatively, either the deny rule or the second permit rule
can be resequenced to appear in the right place. To change the sequence
number of an ACL rule, delete the rule, then re-add it with the sequence
number.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
749 of 950

AX(config)#no access-list 86 30
AX(config)#access-list 86 11 permit host 10.10.10.13 log
In this example, rule 30 is deleted, then re-added with sequence number 11.
The ACL will now work as intended, and permit hosts 10.10.10.12 and
10.10.10.13 while denying all other hosts in the 10.10.10.x subnet. To permit another host, another rule can be added, sequenced to come before the
deny rule.
AX(config)#access-list 86 12 permit host 10.10.10.14 log
USING THE GUI

Each row in the Standard ACL and Extended ACL tables is a separate ACL
rule. You can configure multiple rules in the same ACL. In this case, they
still appear as separate rows, with the same ACL number.
The AX device applies the ACL rules in the order they are listed, starting at
the top of the table. The first rule that matches traffic is used to permit or
deny that traffic. After the first rule match, no additional rules are compared
against the traffic.
If you need to re-order the ACL rules, you can do so by clicking the up or
down arrows at the ends of the rows containing the ACL rules.
Click OK to commit the changes.
USING THE CLI

See the description above.
750 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Policy-Based SLB (PBSLB)

AX Series devices allow you to black list or white list individual clients
or client subnets. Based on actions you specify on the AX device, the AX
will allow (white list) or drop (black list) traffic from specific client hosts or
subnets in the list.
IPv6 addresses are not supported in black/white lists.
Note:
For traffic that is allowed, you can specify the service group to use. You also
can specify the action to perform (drop or reset) on new connections that
exceed the configured connection threshold for the client address. For
example, you can configure the AX to respond to DDoS attacks from a client by dropping excessive connection attempts from the client.
You can apply PBSLB on a system-wide basis or on individual virtual ports.
Configuring a Black/White List

Client IP lists (black/white lists) can be configured on an external device
and imported onto the AX device, or can be entered directly into the GUI.
The actions to take on the addresses in the list are specified on the AX
device. A black/white list can contain up to 8 million individual host
addresses and up to 32,000 subnet addresses.
For each IP address (host or subnet) in a black/white list, add a row using
the following syntax:
ipaddr [/network-mask] [group-id] [#conn-limit] [;comment-string]
The ipaddr is the host or subnet address of the client.
The network-mask is optional. The default is 32, which means the
address is a host address.

The group-id is a number from 1 to 31 in a black/white list that identi-
fies a group of IP host or subnet addresses contained in the list. In a

PBSLB policy template on the AX device, you can map the group to one
of the following actions:
Drop the traffic
Reset the connection
Send the traffic to a specific service group
The default group ID is 0, which means no group is assigned.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
751 of 950

The #conn-limit specifies the maximum number of concurrent connec-
tions allowed from the client. By default, there is no connection limit. If

you set it, the valid range is from 1 to 32767. On the AX, you can specify whether to reset or drop new connections that exceed this limit.
The # is required only if you do not specify a group-id.
Note:
The conn-limit is a coarse limit. The larger the number you specify, the
coarser the limit will be. For example, if you specify 100, the AX device
limits the total connections to exactly 100; however, if you specify 1000,
the device limits the connections to not exceed 992.
If the number in the file is larger than the supported maximum (32767),
the parser will use the longest set of digits in the number you enter that
makes a valid value. For example, if the file contains 32768, the parser
will use 3276 as the value. As another example, if the file contains
111111, the parser will use 11111 as the value.
The ;comment-string is a comment. Everything to the right of the ; is
ignored by the AX device when it parses the file.

Example Black/White List
Here is an example black/white list:
10.10.1.3 4; blocking a single host. 4 is the drop group
10.10.2.0/24 4; blocking the entire 10.10.2.x subnet
192.168.1.1/32 #20 ; 20 concurrent connections max, any group ok
192.168.4.69 2 20 ; assign to service group 2, and allow 20 max
The first row assigns a specific host to group 4. On the AX device, the drop
action will be assigned to this group, thus black listing the client. The second row black lists an entire subnet, by assigning it to the same group (4).
The third row sets the maximum number of concurrent connections for a
specific host to 20. The fourth row assigns a specific host to group 2 and
specifies a maximum of 20 concurrent connections.
Note:
The AX device allows up to three parser errors when reading the file.
However, after the third parser error, the device stops reading the file.
Dynamic Black/White-list Client Entries

AX Release 2.4.1 supports dynamic client entries. To configure this feature,
add client address 0.0.0.0/0 (wildcard address) to the black/white list used
by the system-wide PBSLB policy.
When a client sends an HTTP or HTTPS connection request, the AX device
checks the system-wide PBSLB policys black/white list for the clients IP
address.
752 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

If the list does not already have an entry for the client, the AX device
creates a dynamic entry for the clients host address.

If the list already has a dynamic entry for the client, the AX device
resets the timeout value for the entry. (Dynamic entry aging is described
below.)
If the list contains a static entry for the clients host or subnet address,
the static entry is used instead.

Here is an example of a wildcard address in a black/white list:
0.0.0.0/0 1 #20
In this example, all clients who do not match a static entry in the list will be
assigned to group 1, and will be limited to 20 concurrent connections.
The AX device supports up to 8 million dynamic client entries for systemwide PBSLB. Once this limit is reached, the AX device does not track connections or anomaly counters for additional clients.
Connection Limit for Dynamic Entries
For dynamic entries in a system-wide PBSLB policys black/white list, the
connection limit in the list applies to each individual client. In the example
above, each client that has a dynamic entry in the black/white list will be
allowed to have a maximum of 20 concurrent connections.
Aging of Dynamic Entries
When the AX device creates a dynamic black/white list entry for a client,
the device also sets the timeout for the entry. The timeout value for the
dynamic entry decrements until the timeout reaches 0 or the client sends a
new HTTP or HTTPS connection request.
If the client sends a new HTTP or HTTPS connection request, the time-
out is reset to its full value.

If the timeout reaches 0 and the client does not have any active connec-
tions, the dynamic entry is removed. However, if the client has an active
connection, the dynamic entry is not removed until the clients connection ends.
You can set the timeout to 1-127 minutes. The default is 5 minutes.
If client-lockup is enabled, the timeout for a locked up client does not begin
decrementing until the lockup expires. (See Client Lockup on page 755.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
753 of 950

Wildcard Address Support in PBSLB Policies Bound to Virtual
Ports
Dynamic client entries are supported only for system-wide PBSLB policies.
You can add a wildcard address (0.0.0.0/0) to a black/white list that is used
by a virtual ports PBSLB policy. The group ID and connection limit specified for the wildcard address will be applied to clients that do not match a
static entry in the list. However, there are a few limitations:
The AX device does not create any dynamic entries in the list.
The connection limit applies collectively to all clients that do not have a
static entry in the list.
Configuring System-Wide PBSLB

System-wide PBSLB policies provide options that are not available in policies applied to individual virtual ports:
Dynamic black/white-list client entries
Client lockup
IP anomaly checking and tracking, using new IP anomaly filters
To configure a system-wide PBLSB policy, use the following commands at

[no] system pbslb bw-list name
This command specifies the name of the black/white list to use for the policy.
[no] system pbslb id id {drop | reset}
[logging minutes]
This command specifies the action to take for clients in a given group configured in the black/white list.
drop Drops the connections.
reset Resets the connections.
The logging option enables logging. The minutes option specifies how often
messages can be generated.
754 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

[no] system pbslb over-limit
[reset]
[lockup minutes]
[logging minutes]
This command specifies the action to take for clients who either exceed the
connection limit specified in the black/white list, or exceed the threshold of
any of the new IP anomaly filters. You can use one or both of the following
options:
reset Resets all new connection attempts from the client. If you omit
this option, new connection attempts are dropped instead.

lockup Continues to apply the over-limit action to all new connection
attempts from the client, for the specified number of minutes.

messages can be generated.
[no] system pbslb timeout minutes
This command sets the timeout for dynamic black/white-list entries. You
can specify 1-127 minutes. The default is 5 minutes.
If the lockup option is used with the system pbslb over-limit command,
aging of the dynamic entry for a locked up client begins only after the
lockup expires.
Note:
Client Lockup
The over-limit rule in a system-wide PBSLB policy includes an optional
lockup period. If the lockup period is configured, the AX device continues
to enforce the over-limit action for the duration of the lockup.
For example, if the over-limit action is drop and a client exceeds the connection limit specified in the black/white list, the AX device continues to
drop all connection attempts from the client until the lockup expires.
The lockup option is disabled by default. You can enable it by specifying a
lockup period of 1-127 minutes.
The dynamic black/white-list entry for a client does not age while the client
is locked up. After the lockup ends, the timeout for the entry is reset to its
full value and begins decrementing normally as described in Aging of
Dynamic Entries on page 753.
Displaying and Clearing System-Wide PBSLB Information
To display information for system-wide PBSLB, use the following commands:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
755 of 950

show pbslb system
show pbslb client [ipaddr]
To clear PBSLB information, use the following commands:
clear pbslb system
clear pbslb client [entry]
If you omit the entry option, the statistics counters are cleared but the client
entries themselves are not cleared. To also clear the client entries, use the
entry option.
Configuring PBSLB for Individual Virtual Ports

You can configure PBSLB parameters for virtual ports by configuring the
settings directly on individual ports, or by configuring a PBSLB policy template and binding the template to individual virtual ports.
To configure PBSLB:
1. Configure a black/white list, either remotely or on the AX device itself.
2. If you configure the list remotely, import the list onto the AX device.
3. Optionally, modify the sync interval for the list. The AX regularly synchronizes with the list to make sure the AX version is current.
4. Configure PBSLB settings. You can configure the following settings
directly on individual virtual ports, or configure a policy template and
bind the template to virtual ports.
Specify the black/white list.
Optionally, map each group ID used in the list to one of the follow-
ing actions:
Send the traffic to a specific service group.
Reset the traffic.
Drop the traffic.
Optionally, change the action (drop or reset) the AX will perform on
connections that exceed the limit specified in the list.
Optionally, if needed for your configuration, change client address
matching from source IP matching to destination IP matching.
Note:
756 of 950
These steps assume that the real servers, service groups, and virtual servers have already been configured.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

To Configure PBSLB Settings Using a Policy Template:
2. On the menu bar, select Application > PBSLB Policy.
3. Click Add.
4. In the Name field, enter a name for the template.
5. From the drop-down list below the Name field, select the black/white
list or click create to create or import one.
6. If you clicked create, the PBSLB section appears.
a. Enter or select the following information in the fields of the PBSLB
section:
Name that will be used for the imported black/white list.
Location of the black/white list (Local or Remote).
b. To create the list using a text entry field in the GUI, click Local. The
Definition field appears. Copy-and-paste or type the black/white
list.
c. To import a list from a remote server, select Remote. Enter values
for the following parameters:
Interval at which the AX device re-imports the list. This option
ensures that changes to the list are automatically replicated on
the AX device.
File transfer protocol to use.
IP address or hostname of the device where the list is located.
Path and filename of the list on the remote device.
d. Click OK. The Policy section reappears.
7. To configure group options:
a. Select the group from the Group ID drop-down list.
b. Select one of the following from the Action drop-down list.
Drop Drops new connections until the number of concurrent
connections on the virtual port falls below the ports connection
limit. (The connection limit is set in the black/white list.)
Reset Resets new connections until the number of concurrent
connections on the virtual port falls below the connection limit.
service group name Each of the service groups configured on
the AX device is listed.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
757 of 950

create This option displays the configuration sections for creat-
ing a new service group.

c. Optionally, enable logging. To change the logging interval, edit the
number in the Period field. Logging generates messages to indicate
that traffic matched the group ID.
To generate log messages only when there is a failed attempt to
reach a service group, select Log Failures only.
Note:
If the Use default server selection when preferred method fails option
is enabled on the virtual port, log messages will never be generated for
server-selection failures. To ensure that messages are generated to log
server-selection failures, disable the Use default server selection when
preferred method fails option on the virtual port. This limitation does
not affect failures that occur because a client is over their PBSLB connection limit. These failures are still logged.
d. Click Add. The group settings appear in the PBSLB list.
e. Repeat the steps above for each group.
8. Select the action to take when traffic exceeds the limit: Drop or Reset.
9. Optionally, to match destination traffic against the black/white list,
instead of source traffic, select Use Destination IP.
10. Click OK. The new policy appears in the PBSLB policy list.
11. To bind the PBSLB policy template to a virtual port:
b. On the menu bar, select Virtual Server.
c. Click on the virtual server name or click Add to create a new one.
d. In the Port section, click Add, or select a virtual port and click Edit.
e. In the Virtual Server Port section, select the PBSLB template from
the Policy Template drop-down list.
f. Click OK.
g. Click OK again.
758 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 177
b y
PBSLB Policy section
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
759 of 950

FIGURE 178
section
USING THE CLI

To Import a Black/White List:
bw-list name url [period seconds] [load]
The name can be up to 31 alphanumeric characters long.
The url specifies the file transfer protocol, directory path, and filename. The
following URL format is supported:
tftp://host/file
760 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The period seconds option specifies how often the AX device re-imports
the list to ensure that changes to the list are automatically replicated on the
AX. You can specify 60 86400 seconds. The default is 300 seconds.
The load option immediately re-imports the list to get the latest changes.
Use this option if you change the list and want to immediately replicate the
changes on the AX device, without waiting for the update period.
Note:
A TFTP server is required on the PC and the TFTP server must be running when you enter the bw-list command.
Note:
If you use the load option, the CLI cannot accept any new commands
until the load is completely finished. For large black/white lists, loading
can take a while. Do not abort the load process; doing so can also interrupt
periodic black/white-list updates. If you do accidentally abort the load
process, repeat the command with the load option and allow the load to
complete.
To Configure PBSLB Settings Using a Policy Template:
To configure a PBSLB template, use the following commands:
[no] slb template policy template-name
Enter this command at the global configuration level of the CLI. The command creates the template and changes the CLI to the configuration for the
template, where the following PBSLB-related commands are available.
[no] bw-list name file-name
This command binds a black/white list to the virtual ports that use this template.
[no] bw-list id id
service {service-group-name | drop | reset}
[logging [minutes] [fail]]
This command specifies the action to take for clients in the black/white list:
id Group ID in the black/white list.
service-group-name Sends clients to the SLB service group
associated with this group ID on the AX device.

drop Drops connections for IP addresses that are in the specified
group.
reset Resets connections for IP addresses that are in the specified
group.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
761 of 950

logging [minutes] [fail] Enables logging. The minutes
option specifies how often messages can be generated. This option

reduces overhead caused by frequent recurring messages.
For example, if the logging interval is set to 5 minutes, and the PBSLB
rule is used 100 times within a five-minute period, the AX device generates only a single message. The message indicates the number of times
the rule was applied since the last message. You can specify a logging
interval from 0 to 60 minutes. To send a separate message for each
event, set the interval to 0.
PBSLB rules that use the service service-group-name option also have a
fail option for logging. The fail option configures the AX device to generate log messages only when there is a failed attempt to reach a service
group. Messages are not generated for successful connections to the service group. The fail option is disabled by default. The option is available
only for PBSLB rules that use the service service-group-name option,
not for rules with the drop or reset option, since any time a drop or reset
rule affects traffic, this indicates a failure condition.
Logging is disabled by default. If you enable it, the default for minutes
is 3.
The AX device uses the same log rate limiting and load balancing features for PBSLB logging as those used for ACL logging. See Log Rate
Limiting on page 48.
Note:
If the def-selection-if-pref-failed option is enabled on the virtual port, log

messages will never be generated for server-selection failures. To ensure
that messages are generated to log server-selection failures, disable the
def-selection-if-pref-failed option on the virtual port. This limitation does
[no] bw-list over-limit
{lockup min | logging min | reset}
This command specifies the action to take for traffic that is over the limit.
You can specify one or more of the following options:
lockup min Continues to apply the over-limit action to all new con-
nection attempts from the client, for the specified number of minutes
(1-127).
logging min Generates a log message when traffic goes over the
limit. The min option specifies the log interval and can be 1-255 minutes.
reset Resets new connections until the number of concurrent con-
nections on the virtual port falls below the connection limit.
762 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

[no] bw-list use-destination-ip
This command matches black/white list entries based on the clients destination IP address. By default, matching is based on the clients source IP
address. This option is applicable if you are using a wildcard VIP. (See
Wildcard VIPs on page 271.)
To bind the template to a virtual port, use the following command at the
configuration level for the port:
[no] template policy template-name
To Configure PBSLB Settings Directly on a Virtual Port:
To bind a black/white list to a virtual port, use the following command at the
configuration level for the virtual port:
pbslb bw-list name
The name is the name you assign to the list when you import it.
To map client IP addresses in a black/white list to specific service groups,
use the following command at the configuration level for the virtual port:
pbslb id id
{service service-group-name | drop | reset}
[logging [minutes] [fail]]]
The id is a group ID in the black/white list and can be from 1 to 31.
The service-group-name is the name of an SLB service group on the AX.
The drop option immediately drops all connections between the clients in
the list and any servers in the service group. The reset option resets the connections between the clients in the list and any servers in the service group.
messages can be generated. This option reduces overhead caused by frequent recurring messages. For example, if the logging interval is set to 5
minutes, and the PBSLB rule is used 100 times within a five-minute period,
the AX device generates only a single message. The message indicates the
number of times the rule was applied since the last message. You can specify a logging interval from 0 to 60 minutes. To send a separate message for
each event, set the interval to 0. The default is 3 minutes.
PBSLB rules that use the service service-group-name option also have a
fail option for logging. The fail option configures the AX device to generate
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
763 of 950

log messages only when there is a failed attempt to reach a service group.
Messages are not generated for successful connections to the service group.
The fail option is disabled by default. The option is available only for
PBSLB rules that use the service service-group-name option, not for rules
with the drop or reset option, since any time a drop or reset rule affects traffic, this indicates a failure condition.
The AX device uses the same log rate limiting and load balancing features
for PBSLB logging as those used for ACL logging. See Log Rate Limiting on page 48.
Note:
If the def-selection-if-pref-failed option is enabled on the virtual port, log

messages will never be generated for server-selection failures. To ensure
that messages are generated to log server-selection failures, disable the
def-selection-if-pref-failed option on the virtual port. This limitation does
To specify the action to take if the virtual ports connection threshold is
exceeded, use the following command at the configuration level for the virtual port:
[no] bw-list over-limit {drop | reset}
This command specifies the action to take for traffic that is over the limit.
drop Drops new connections until the number of concurrent connec-
tions on the virtual port falls below the ports connection limit. (The
connection limit is set in the black/white list.)
reset Resets new connections until the number of concurrent connec-
tions on the virtual port falls below the connection limit.The connection
threshold is set in the black/white list.
Displaying PBSLB Information

To show the configuration of a PBSLB policy template, use the following
command:
show slb template policy template-name
To show client IP addresses contained in a black/white list, use the following command:
show bw-list [name [detail | ipaddr]]
The name is the name you assign to the list when you import it. The ipaddr
is the client IP address.
764 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

To show policy-based SLB statistics, use the following command:
show pbslb [name]
The name option specifies a virtual server name. If you use this option, statistics are displayed only for that virtual server. Otherwise, statistics are
shown for all virtual servers.
CLI CONFIGURATION EXAMPLES

The following commands import black/white list sample-bwlist.txt onto
the AX device:
AX(config)#bw-list sample-bwlist tftp://myhost/TFTP-Root/AX_bwlists/samplebwlist.txt
AX(config)#show bw-list
Name
Url
Size(Byte)
Date
-----------------------------------------------------------------------------sample-bwlist
tftp://myhost/TFTP-Root/AX_
N/A
N/A
bwlists/sample-bwlist.txt
Total: 1
The following commands configure a PBSLB template and bind it to a virtual port:
AX(config)#slb template policy bw1
AX(config-policy)#bw-list name bw1
AX(config-policy)#bw-list id 2 service srvcgroup2
AX(config-policy)#bw-list id 4 drop
AX(config-policy)#exit
AX(config)#slb virtual-server PBSLB_VS1 10.10.10.69
AX(config-slb virtual server-slb virtua...)#template policy bw1
The following commands configure the same PBSLB settings directly on a

virtual port:
AX(config)#slb virtual-server PBSLB_VS2 10.10.10.70
AX(config-slb virtual server-slb virtua...)#pbslb bw-list sample-bwlist
AX(config-slb virtual server-slb virtua...)#pbslb id 4 drop
AX(config-slb virtual server-slb virtua...)#pbslb id 2 service srvcgroup2
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
765 of 950

The following commands shows PBSLB information:
AX(config-slb virtual server-slb virtua...)#show pbslb
Total number of PBSLB configured: 1
Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop)
-----------------------------------------------------------------------------PBSLB_VS1
PBSLB_VS2
80
80
sample-bwlist
sample-bwlist
Configuration ExampleSockstress Attack Protection

You can use system-wide PBSLB in combination with IP anomaly filters to
protect against Sockstress attacks, a type of DDoS attack.
In this example, the AX device drops all new connection attempts from a
client if either of the following occurs:
The client already has 20 active connections and attempts to open a new
HTTP or HTTPS connection.

The client exceeds any of the IP anomaly thresholds.
The lockup period is set to 5 minutes, to continue enforcing the over-limit

action for 5 minutes after the over-limit action is triggered.
The timeout for dynamic black/white list entries is set to 2 minutes.
This example uses the following black/white list:
0.0.0.0/0 1 #20
System-wide PBSLB Policy Configuration
The following commands configure the system-wide PBSLB policy:
AX(config)#system pbslb bw-list bwlist-wc
AX(config)#system pbslb over-limit lockup 5
AX(config)#system pbslb timeout 2
Configuring the system-wide PBSLB policy also automatically enables the

new IP anomaly filters.
Statistics Display
The following command shows system-wide statistics for the new IP anomaly filters:
766 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX(config)#show slb l4
Total
-----------------------------------------------------------------IP out noroute
20061
TCP out RST
TCP out RST no SYN
...
Anomaly out of sequence 225408
Anomaly zero window
225361
Anomaly bad content
224639
The following command shows statistics for the system-wide PBSLB policy:
AX(config)#show pbslb system
System
B/W list: bwlist-wc
Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop)
-------------------------------------------------------------------------------System
bwlist-wc
1
12
0
0
2
0
0
0
The following command shows summary statistics for individual black/

white-list clients:
AX#show pbslb client
GID = Group ID, S/D = Static or dynamic entry
Out-s = Out of sequence, Zero-w = Zero window, Bad-c = Bad content
IP
S/D GID Conn-limit Curr-conn Age
Lockup Out-s Zero-w Bad-c
------------------+---+---+----------+---------+-----+------+-----+------+---40.40.40.168
/32
20
120
40.40.40.169
/32
20
40.40.40.170
/32
20
40.40.40.171
/32
20
40.40.40.172
/32
20
40.40.40.173
/32
20
120
40.40.40.174
/32
20
120
40.40.40.175
/32
20
120
40.40.40.160
/32
20
120
40.40.40.161
/32
20
120
40.40.40.162
/32
20
40.40.40.163
/32
20
40.40.40.164
/32
20
40.40.40.165
/32
20
120
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
767 of 950

Geo-location-based Access Control for VIPs
The Age column indicates how many seconds are left before a dynamic
entry ages out. For clients who are currently locked out of the system, the
value in the Lockup column indicates how many minutes the lockup will
continue. For locked up clients, the age value is 0 until the lockup expires.
After the lockup expires, the age is set to its full value (120 seconds in this
example).
The following command shows detailed statistics for a specific black/whitelist client:
AX#show pbslb client 40.40.40.168
IP address:
40.40.40.168
Netmask length:
32
Type:
Dynamic
Group ID:
Connection limit (0 = no limit):
1984
Current connection:
Age:
0 second
Lockup time:
5 minute
Out of sequence:
Zero window:
Bad content:

You can control access to a VIP based on the geo-location of the client.
Using Policy-based SLB (PBSLB), 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
The AX device determines a clients location by looking up the clients subnet in the geo-location database used by Global Server Load Balancing
(GSLB).
Note:
768 of 950
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuration
To configure geo-location-based access control for a VIP:
1. Configure a black/white list. You can configure the list using a text editor 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 control 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 clients location will be determined using information in the geo-location database.
The geo-location is the string in the geo-location database that is mapped to
the clients 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 (geolocations) 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
769 of 950

Here is a simple example of a black/white list for this feature:
L "US"
L "US.CA"
L "JP"
USING THE GUI

To configure or import a black/white list using the GUI:
1. Select Config > 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:
3. Click Add.
4. In the Name field, enter a name for the template.
5. From the drop-down list below the Name field, select the black/white
list.
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 ports connection limit.
(The connection limit is set in the black/white list.)
Reset Resets new connections until the number of concurrent connections on the virtual port falls below the connection limit.
770 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 limiting and load balancing features for PBSLB logging as those used for
ACL logging. See Log Rate Limiting on page 48.)
9. Click Add.
10. Repeat step 6 through step 9 for each group ID.
11. Click OK.
To load the IANA geo-location database:
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.
If preferred, you can import a custom geo-location database instead. For
information, see Loading or Configuring Geo-Location Mappings on
page 459.
Note:
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
771 of 950

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 command at the global configuration level of the CLI:
bw-list name url [period seconds] [load]
The name can be up to 31 alphanumeric characters long. The url specifies the file transfer protocol, directory path, and filename. The following URL format is supported: tftp://host/file
2. To configure a PBSLB template, use the following commands:
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.
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}
This command specifies the action to take for clients in the black/white
list:
id Group ID in the black/white list.
service-group-name Sends clients to the SLB service group associated with this group ID on the AX device.
drop Drops connections for IP addresses that are in the specified
group.
reset Resets connections for IP addresses that are in the specified
group.
3. To load a geo-location database, use the following command at the global configuration level of the CLI:
[no] gslb geo-location load
{iana | file-name csv-template-name}
772 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

4. To apply the policy template to a virtual port, use the following command 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 content.
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-location; for example US.CA.
Clearing SLB Geo-Location Statistics
To clear SLB geo-location statistics, use the following command at the Privileged EXEC level of the CLI:
clear slb geo-location
[
virtual-server name [...]
virtual-port-num |
location {all | string}
]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
773 of 950

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
Enabling PBSLB Statistics Counter Sharing

You can enable sharing of statistics counters for all virtual servers and virtual 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

USING THE CLI

To enable the share option, use the following command at the configuration
level for the PBSLB policy template:
geo-location share
774 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
Note:
Enabling Full-Domain Checking for Connection Limits

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,
the clients connection is permitted. Likewise, the permit counter is incremented only for that specific geo-location level.
Table 23 shows an example set of geo-location connection limits and current connections.
TABLE 23 Geo-location connection limit example
Geo-location
US
US.CA
US.CA.SanJose
Connection Limit
100
50
20
Current
Connections
100
37
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.
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 clients 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 clients 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:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
775 of 950

US Deny counter is incremented by 1.
US.CA Deny counter is incremented by 1.
USING THE GUI

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 template:
geo-location full-domain-tree
Note:
776 of 950
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
IP Limiting
IP limiting provides a greatly enhanced implementation of the source IP
connection limiting and connection-rate limiting feature available in previous releases. This chapter describes the IP limiting options and how to configure 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 clients 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
In the current release, Layer 7 request limiting applies only to the HTTP,
HTTPS, and fast-HTTP virtual port types.
Note:
The following sections describe the IP limiting options and how to configure and apply them.
Class Lists
A class list is a set of IP host or subnet addresses that are mapped to IP limiting 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
777 of 950

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] [; comment-string]
Each entry consists of the following:
ipaddr Specifies the host or subnet address of the client. The network-
mask specifies the network mask.

To configure a wildcard IP address, specify 0.0.0.0 /0. The wildcard
address matches on all addresses that do not match any entry in the class
list.
glid num | 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 PBSLB 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
PBSLB 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 limiting rule.
; 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.
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 following 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.
778 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Example Class Lists

Here is an example of a very simple class list. This list matches on all clients 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 PBSLB policy template. (A PBSLB policy template can be applied

globally for system-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 PBSLB 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 PBSLB 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.
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 1-1048575. 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 connections. The limit period can be 100-6553500 milliseconds (ms), specified in increments of 100 ms. There is no default.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
779 of 950

Overview
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 connections. 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 activated 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).
Match IP Address
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.
780 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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
PBSLB policy template or in standalone IP limiting rules.

For IP limiting on an individual virtual server or virtual port, configure the rules in a PBSLB policy template.
3. Apply the IP limiting rules.
You can configure multiple PBSLB policy templates with different IP limiting rules. You can use a given class list in one or more PBSLB policy templates.
For system-wide source IP limiting, apply the PBSLB policy template
globally.
For source IP limiting on an individual virtual server or virtual port,
apply the PBSLB policy template to the virtual server or virtual port.
Clients must comply with all IP limiting rules that are applicable to the client. For example, if you configure system-wide IP limiting and also configure 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 777.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
781 of 950

USING THE GUI

Importing a Class List onto the AX Device
2. On the menu bar, select Class List.
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 connection to the remote device, select Use Management Port. Otherwise, the
AX device will attempt to reach the remote server through a data interface.
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 Create.
4. In the Name field, enter a name for the class list.
782 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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.
If the class list contains 100 or more entries, it is recommended to use the
File option.
Note:
A class list can be exported only if you use the File option.
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 PBSLB 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.
LSN This option applies only to the Large-Scale NAT feature.
Do not use this option with IP limiting.
Enter the rule number, 1-31.
Make sure to use the same number when you configure the IP limiting
rule.
Note:
c. Click Add.
d. Repeat for each entry.
7. Click OK.
USING THE CLI

Importing a Class List onto the AX Device
After the class list is configured, import it onto the AX device, using the following command at the Privileged EXEC or global configuration level of
the CLI:.
import class-list file-name url
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
783 of 950

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.
entire URL:
tftp://host/file
You also can export class lists to a remote server, using the following command:
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.
784 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Applying a Class List to a PBSLB Policy
To apply a class list, use the following command at the configuration level
for the PBSLB policy that contains the IP limiting rules used by the class
list.
[no] class-list name name
After you configure the IP limiting rules and class list, and add the class list
to the PBSLB policy, you can activate the IP limits. See Applying Source
IP Limits on page 788.
Configuring the IP Limiting Rules

You can configure IP limiting rules in PBSLB policy templates (applied to
individual 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 PBSLB 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 PBSLB Policy Template
3. Click Add to create a new template (or click on the name of an existing
template). The PBSLB 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 779.)
6. Leave the Destination IP and Overlap options disabled.
7. Click OK.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
785 of 950

Configuring Standalone IP Limiting Rules for System-Wide IP
Limiting
2. On the menu bar, select LID.
3. Configure the IP limiting rules. (For parameter information, see IP
Limiting Rules on page 779.)
4. Click OK.
USING THE CLI

Configuring IP Limiting Rules in a PBSLB Policy Template
To configure IP limiting rules in a PBSLB policy template, use the following commands:
Enter this command at the global configuration level of the CLI. The command creates the template and changes the CLI to the configuration level
for the template, where the following commands are available. For information about the valid values and defaults, see IP Limiting Rules on
page 779.
[no] class-list lid num
This command creates an IP limiting rule and changes the CLI to the configuration 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.
786 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

[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.
[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 logging.
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 following commands.
[no] lid 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 PBSLB policy templates. (See Configuring IP Limiting Rules in a PBSLB Policy Template on page 786.)
Specifying the Match IP Address
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]}
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
787 of 950

The l3-dest option matches based on the destination IP address in packets
from clients.
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 782
Configuring Standalone IP Limiting Rules for System-Wide IP Limit-
ing on page 786

Applying Source IP Limiting to a 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 PBSLB policy template from the PBSLB Policy Template
drop-down list.
6. If you are creating a new virtual server, configure the virtual port settings as applicable to your deployment.
7. When the virtual server configuration is complete, click OK.
788 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 788.)
2. On the Virtual Server Port configuration page, select the PBSLB policy
template from the PBSLB 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 lid 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.
The AX device does not support using the system template policy command and the system pbslb command in the same configuration.
Note:
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:
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:
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
789 of 950

Displaying IP Limiting Information

USING THE GUI
To view configuration information for the feature, navigate to the configuration 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 commands:
show class-list [name [ipaddr]]
show lid [num]
show system policy
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]]
790 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

CLI ExamplesConfiguration
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)#lid 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-global lid)#exit
AX(config)#system lid 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
AX(config-class list)#exit
Configure System-Wide IP Limiting With Multiple Classes

The commands in this example configure system-wide IP limiting using a
PBSLB policy template.
AX(config)#slb template policy global_policy
AX(config-policy)#class-list name global_list
AX(config-policy)#class-list lid 1
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
AX(config-policy-policy lid)#exit
The following command imports the class list used by the policy:
AX(config)#import class-list global_list ftp:
Password []?*********
File name [/]?global_list
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
791 of 950

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 PBSLB 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)#conn-limit 50000
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
792 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configure IP Limiting on a Virtual Port

The commands in this example configure IP limiting for a virtual port.
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.
Note:
The following commands configure a PBSLB 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
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
CLI ExamplesDisplay
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
file
user-limit
14
config
Total: 2
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
793 of 950

Table 24 describes the fields in the command output.
TABLE 24 show class-list fields
Field
Name
IP
Subnet
Location
Description
Name of the class list.
Number of host IP addresses in the class list.
Number of subnets in the class list.
Indicates whether the class list is in the startup-config or in a
standalone file:
config Class list is located in the startup-config.
Total
file Class list is located in a standalone file.

Total number of class lists on the AX device.
The following command shows details for a class list:

AX#show class-list test
Name:
test
Total single IP:
Total IP subnet:
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.
794 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

IP Limiting Rules
The following command the configuration of each standalone IP limiting
rule:
AX#show lid
lid 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
lid 2
conn-limit 20000
request-limit 200
lid 30
conn-limit 10000
over-limit-action forward log
The following command shows the configuration of IP limiting rule 1:

AX#show lid 1
lid 1
conn-limit 100
request-limit 1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
795 of 950

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:
Current connection rate:
Total over connection limit number:
Total over connection rate limit number:
1
0/s
0
0
System class list statistics:

F = Flag (C-Connection, R-Request), Over-RL = Over rate limit
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:
Source
Destination
F Current
Rate
Over-limit Over-RL
---------------+---------------------+-+---------+---------+----------+---------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
The following command shows IP limiting statistics for clients:

AX#show pbslb client
Client class list statistics:
Source
Destination
F Current
Rate
Over-limit Over-RL
---------------+---------------------+-+---------+---------+----------+---------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
796 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
The AX Series provides Virtualized Management, through Role-Based
Administration (RBA). RBA allows administrators (admins) to configure
and view SLB resources based on administrative domains (partitions).
RBA supports separate partitions for these types of resources. Partitioning
allows the AX device to be logically segmented to support separate configurations for different customers; for example, separate companies or separate
departments within an enterprise. Admins assigned to a partition can manage only the resources inside that partition.
Note:
b y
RBA is backwards compatible with configurations saved under earlier

AX releases. All resources are automatically migrated to a single, shared
partition.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
797 of 950

Overview
Overview
Figure 179 shows an example of an AX device with multiple partitions.
FIGURE 179
In this example, a service provider hosts an AX device shared by two companies: A.com and B.com. Each company has its own dedicated servers that
they want to manage in entirety. The partition for A.com contains A.com's
SLB resources. Likewise, the partition for B.com contains B.com's SLB
resources.
Admins assigned to the partition for A.com can add, modify, delete and save
only those resources contained in A.com's partition. Likewise, B.com's
admins can add, modify, delete and save only the resources in B.com's partition.
The following sections describe RBA in more detail.
798 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
Resource Partitions
AX system resources are contained in partitions. The AX device has a single shared partition and can have multiple private partitions.
Shared partition The shared partition contains resources that can be
configured only by admins with Root or Read Write privileges. By

default, all resources are in the shared partition. There is one shared partition for the device and it is the default partition. The shared partition
cannot be deleted.
Private partitions A private partition can be accessed only by the
admins who are assigned to it, and by admins with Root, Read Write, or
Read Only privileges. The AX device does not have any private partitions by default.
Private partitions can be created or deleted only by admins who have Root
or Read Write privileges. A maximum of 128 partitions are supported.
(For descriptions of admin privileges, see Table 25 on page 801.)
Types of Resources That Can Be Contained in Private Partitions
Only certain types of resources can be contained in private partitions. In the
current release, a private partition can contain SLB resources only:
Real servers
Virtual servers
Service groups
Templates
Health monitors
Certificates and keys
aFleX policies
All other types of resources can reside only in the shared partition and are
not configurable by admins assigned to private partitions.
Resource names must be unique within a partition. However, the same name
can be used for resources in different partitions. For example, partitions
A.com and B.com can each have a real server named rs1. The AX
device is able to distinguish between them.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
799 of 950

Overview
Use of Shared Resources by Private Resources
SLB resources in private partitions can use SLB resources in the shared partition, but cannot use resources in other private partitions. For example, a
virtual service port in a private partition can be configured to bind to a service group in the shared partition, as shown in the following GUI example.
FIGURE 180
Shared SLB Resource Used by Private SLB Resource
Resources in a private partition cannot be used by resources in any other

partition, whether private or shared.
aFleX Policies
By default, aFleX policies act upon resources within the partition that contains the aFleX policy. Some aFleX commands have an option to act upon
service groups in the shared partition instead. (For more information, see
the AX Series aFleX Reference.)
Partition Logos
Each private partition has a logo file associated with it. The logo appears in
the upper left corner of the Web GUI. By default, the A10 Networks logo is
used. Partition admins can replace the A10 Networks logo with a company
logo. The recommended logo size is 180x60 pixels.
The following examples show Web GUI pages for two private partitions. A
company-specific logo has been uploaded for each partition.
800 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
FIGURE 181
Configurable Partition Logos
Administrator Roles
The type of access (read-only or read-write) allowed to an admin, and the
partitions where the access applies, depend on that admins privilege level
(role). An admin account can have one of the privilege levels listed in
Table 25 on page 801.
The Partition privilege levels apply specifically to admins who are
assigned to private partitions.
Note:
Table 25 describes the admin roles.

TABLE 25 Admin Privilege Levels
Privilege
Level (Role)
Root
Access to
Shared
Partition
Read-write
Read Write
Read Only
Partition Write
Read-write
Read-only
Read-only
Access to Private Partition

Read-write
Read-write
Read-only
Read-write, for the partition to which
the admin is assigned
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Can configure
other admin
accounts
Can Change
Own
Password?
Yes1
No
No
No
Yes2
Yes
No
Yes
801 of 950

Overview
TABLE 25 Admin Privilege Levels (Continued)
Privilege
Level (Role)
Partition Read
Partition Real
Server Operator
Access to
Shared
Partition
Read-only
None
Access to Private Partition

Read-only, for the partition to which the
admin is assigned
Read-only for real servers, with permission to view service port statistics, and
to disable or enable real servers and real
server ports.
Can configure
other admin
accounts
No
Can Change
Own
Password?
No
No
No
No other read-only or read-write privileges are granted.

All access is restricted to the partition to
which the admin is assigned.
1. Only the admin account named admin is allowed to configure other admin accounts, and cannot be deleted. Otherwise,
the Root and Read-write privilege levels are the same.
2. The Root privilege level can also change the passwords of other admins.
Types of Resources That Can Be Viewed and Saved By Private

Partition Admins
All admins can view resources in the shared partition. However, the only
admins who can add, modify, or delete resources in the shared partition are
admins with Root or Read Write privileges. Admins who are assigned to a
partition can view but not modify resources in the shared partition. Admins
assigned to a partition cannot view the resources in any other private partition.
Each partition has its own running-config and startup-config. When an
admin assigned to a partition displays the running-config or startup-config,
only the resources within the partition are listed.
Likewise, when an admin assigned to a private partition saves the configuration, only the startup-config for that partition is modified. The configuration changes in the partitions running-config are copied to the partitions
startup-config.
Only admins with Root or Read Write privileges can select the partition(s)
for which to save changes.
Admins with Real Server Operator privileges can view real servers within
the private partition and can disable or re-enable the real servers and their
individual service ports. These admins have no other privileges.
802 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Configuring Role-Based Administration

To configure role-based administration, log in using an admin account with
Root privileges, and perform the following steps:
1. Configure partitions.
2. Configure admin accounts and assign them to partitions.
3. Configure any SLB shared resources that you want to make available to
multiple private partitions. (For information about configuring SLB
resources, see the SLB configuration chapters in this guide.)
Configuration of SLB resources within a private partition can be performed
by an admin with Partition-write privileges who is assigned to the partition.
Note:
This document shows how to set up partitions and assign admins to them.
The partition admins will be able to configure their own SLB resources.
However, you will need to configure connectivity resources such as interfaces, VLANs, routing, and so on. You also will need to configure any
additional admin accounts for the partition.
Note:
To configure admin accounts, you must be logged in with Root privileges.
Configuring Private Partitions

To configure a private partition, use either of the following methods.
USING THE GUI

2. On the menu bar, select Partition.
3. Click New. The Partition section appears.
4. Enter a name for the partition.
5. To upload a logo for the partition, click Browse and navigate to the logo
file.
6. If a partition logo is not uploaded, the A10 Networks logo is used by
default.
7. Click OK. The new partition appears in the partition list.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
803 of 950

FIGURE 182
Config > System > Admin > Partition
FIGURE 183
Config > System > Admin > Partition - List
USING THE CLI

To configure a private partition, use the following command at the global
partition partition-name [max-aflex-file num]
The partition-name can be 1-14 characters. (For information about the maxaflex-file option, see Changing the Maximum Number of aFleX Policies
Allowed in a Partition on page 804.)
Changing the Maximum Number of aFleX Policies Allowed in a Partition

By default, each partition is allowed to have a maximum of 32 aFleX policies. If a partition admin attempts to add more aFleX policies than are
allowed for the partition, an error message is displayed to the admin.
You can specify a maximum of 1-128 aFleX policies, on an individual partition basis.
804 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE GUI

3. Select the partition. (Click the checkbox next to the partition name.)
4. Edit the number in the Max aFleX File field. You can specify 1-128.
USING THE CLI

The max-aflex-file option of the partition command specifies the maximum number of aFleX policies that can belong to the partition. You can
Migrating Resources Between Partitions

Resources cannot be moved directly from one partition to another. To move
resources, an admin must delete the resources from the partition they are in,
then recreate the resources in the new partition.
Deleting a Partition
Only an admin with Root or Read Write privileges can delete a partition.
When a partition is deleted, all resources within the partition also are
deleted.
USING THE GUI

3. Select the partition. (Click the checkbox next to the partition name.)
4. Click Delete.
USING THE CLI

To delete a partition, use the following command at the global configuration
level of the CLI:
no partition [partition-name]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
805 of 950

If you do not specify a partition name, the CLI displays a prompt to verify
whether you want to delete all partitions and the resources within them.
Enter y to confirm or n to cancel the request.
Configuring Partition Admin Accounts

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

page 674.
USING THE GUI

To configure an admin account for a private partition:
1. Select Config > System > Admin (if not already selected).
2. On the menu bar, select Admin Management.
3. Click New. The Admin section appears.
4. Enter a name and password for the admin.
5. From the Role drop-down list, select one of the following:
Partition Write Admin Gives read-write privileges within the par-
tition you select below.

Partition Read Admin Gives read-only privileges within the partition you select below.
Partition RS Operator Allows the admin to view, disable, or reenable real servers and service ports in the partition. No other read
or write privileges are granted.
6. From the Partition drop-down list, select the partition to which you are
assigning the admin.
7. Click OK. The new admin appears in the admin list with their respective
partition logos.
806 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

FIGURE 184
Config > System > Admin > Admin Management
USING THE CLI

To configure an admin account for a private partition, use the following
commands:
[no] admin admin-username password string
[no] privilege
{partition-write | partition-read |
partition-enable-disable}
partition-name
The admin command creates the admin account and changes the CLI to the
configuration level for the account. The command syntax shown here
includes the password option. You can specify the password with the
admin command, or with the separate password command at the configuration level for the account. The default password is a10.
The privilege command specifies the privilege level for the account and
assigns the account to a partition. (The partition-enable-disable option
gives Partition Real Server Operator privileges.)
Note:
b y
The other admin configuration commands do not apply specifically to

role-based administration. For information about these other commands,
see Configuring Additional Admin Accounts on page 669.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
807 of 950

CLI Example
The following commands configure two private partitions, companyA
and companyB, and verify that they have been created.
AX(config)#partition companyA
AX(config)#partition companyB
AX(config)#show partition
Max Number allowed: 128
Total Number of partitions configured: 2
Partition Name
Max. aFleX File Allowed
# of Admins
-----------------------------------------------------companyA
32
companyB
32
The following commands configure an admin account for each partition:

AX(config)#admin compAadmin password compApwd
AX(config-admin:compAadmin)#privilege partition-write companyA
Modify Admin User successful !
AX(config-admin:compAadmin)#exit
AX(config)#admin compBadmin password compBpwd
AX(config-admin:compBadmin)#privilege partition-write companyB
Modify Admin User successful !
AX(config-admin:compBadmin)#exit
The following command displays the admin accounts:

AX(config)#show admin
UserName
Status
Privilege Partition
------------------------------------------------------admin
Enabled
Root
compAadmin
Enabled
P.R/W
companyA
compBadmin
Enabled
P.R/W
companyB
The show admin command shows privilege information as follows:

Root The admin has Root privileges.
R/W The admin has Read Write privileges.
R The admin has Read Only privileges.
P.R/W The admin is assigned to a private partition and has Partition-
write (read-write) privileges within that partition.
808 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Viewing and Saving the Configuration
P.R The admin is assigned to a private partition and has Partition-read
(read-only) privileges within that partition.

P.RS Op The admin is assigned to a private partition but has permis-
sion only to view service port statistics for real servers in the partition,
and to disable or re-enable the real servers.

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

To view configuration information on an AX device configured with private
partitions, use either of the following methods.
USING THE GUI

See Switching To Another Partition on page 811.
USING THE CLI

To view the configuration, use the following commands:
show running-config
show startup-config
If you enter the command without either option, the command shows only
the resources that are in the shared partition.
The all-partitions option shows all resources in all partitions. In this case,
the resources in the shared partition are listed first. Then the resources in
each private partition are listed, organized by partition.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
809 of 950

If you specify a private partition-name, only the resources in that partition
are listed.
Note:
If an admin assigned to a private partition uses the all-partitions option,

the option does not list resources in any other private partitions. Similarly,
if a partition admin enters the name of another private partition for partition-name, an Insufficient privilege warning message appears. The
resources of the other partition are not displayed.
Saving the Configuration

To save the configuration on an AX device configured with private partitions, use either of the following methods.
USING THE GUI

To save the configuration in the GUI, click the Save button on the title bar.
The GUI automatically saves only the resources that are in the current partition view. For example, if the partition view is set to the companyB private partition, only the resources in that partition are saved.
USING THE CLI

To save the configuration, use the following command:
write memory
If you enter the command without either option, the command saves only
the changes for resources that are in the current partition.
The all-partitions option saves changes for all resources in all partitions.
If you specify a private partition-name, only the changes for the resources
in that partition are saved.
810 of 950
Caution:
Before saving all partitions or before a reload, reboot, or shutdown

operation, a Root or Read Write admin should notify all partition
admins to save their configurations if they wish to. Saving all partitions without consent from the partition admins is not recommended.
Note:
The all-partitions and partition partition-name options are not applicable for admins with Partition-write privileges. Partition admins can only
save their respective partitions. For these admins, the command syntax is
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Switching To Another Partition
the same as in previous releases. The options are available only to admins
with Root or Read Write privileges.
A configuration can be saved to a different configuration profile name
(rather than being written to startup-config), as supported in previous
releases. In this case, the resources that are saved depend on the partition(s) to which the write memory command is applied. Unless the
resources in the shared partition are being saved, the configuration profile
name used with the write memory command must already exist. The
command does not create new configuration profiles for private partitions.
Note:
Switching To Another Partition

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

1. On the title bar, select the partition from the Partition drop-down list.
A dialog appears, asking you to confirm your partition selection.

2. Click Yes.
3. Click the Refresh button next to the Partition drop-down list. You must
refresh the page in order for the view change to take effect.
USING THE CLI

Use the following command at the Privileged EXEC level of the CLI:
active-partition {partition-name | shared}
To change the view to a private partition, specify the partition name. To
change the view to the shared partition, specify shared.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
811 of 950

Synchronizing the Configuration
The following command changes the view to private partition companyA:
AX#active-partition companyA
Currently active partition: companyA
To display the currently active partition, use the following command:

show active-partition

When an admin assigned to a private partition synchronizes the configuration to the other AX device in a High-Availability (HA) pair, the resources
in the private partition are synchronized for that partition. No other
resources are synchronized.
An admin with Root or Read Write privileges can specify any partitions(s)
to synchronize.
Note:
If you plan to synchronize the Active AX devices running-config to the

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

Active-Standby HA configurations.
USING THE GUI

In the GUI, the synchronization applies only to the current partition.
812 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

USING THE CLI

The ha sync commands have new options that enable you to specify the
partition. For admins with Root or Read Write privileges, here is the new
syntax for the ha sync commands:
ha sync all
to-running-config}
ha sync startup-config
to-running-config}
ha sync running-config
to-running-config}
ha sync data-files
To synchronize the configuration for all partitions, use the all-partitions
option. To synchronize only a specific private partition, use the partition
partition-name option. By default, the synchronization applies only to the
current partition.
If you plan to use the ha sync running-config to-running-config command, see the note at the beginning of this section first.
For admins logged on with Partition Write privileges, the following syntax
is available:
ha sync all to-startup-config
ha sync startup-config to-startup-config
ha sync running-config to-startup-config
ha sync data-files
Admins with Partition Write privileges are not allowed to synchronize to the
running-config or to reload the other AX device.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
813 of 950

Operator Management of Real Servers

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

This section describes how to enable or disable real servers and service
ports using the GUI.
To Disable or Re-Enable Servers
1. Log in with your Partition-enable-disable account.
2. Select the checkbox next to each server you want to disable or re-enable,
or click Select All to select all of the servers.
3. Click Disable or Enable.
FIGURE 185
Note:
Real Server Management in Operator Mode
Although the GUI displays the Delete and New buttons, these buttons are
not supported for admins with Partition Real Server Operator privileges.
To Disable or Re-Enable Individual Real Server Ports
1. Log in with your Partition Real Server Operator account.
2. Select the checkbox next to each server for which you want to disable or
re-enable service ports, or click Select All to select all of the servers.
3. Click Edit.
4. A list of all the service ports on the selected servers is displayed.
814 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

To View Service Statistics
To view configuration information and statistics for real servers used by the
partition, log in with your Partition-enable-disable account and use the following command:
show slb server [server-name] [config]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
815 of 950

CLI Example
login as:compAoper
Welcome to AX
Password:********
Last login: Wed Aug 20 08:58:45 2008 from 192.168.1.130
[type ? for help]
AX>show slb server
Service
Current
Total
Fwd-pkt Rev-pkt
State
-----------------------------------------------------------------------------compArs1:80/tcp
23
320543
1732383
1263164
compArs1: Total
23
321024
1732383
1263164
Up /60 ms
Up
AX>show slb server config

H-check = Health check
Service
Max conn = Max. Connection
Address
H-check
Wgt = Weight
Status
Max conn Wgt
-----------------------------------------------------------------------------compArs1:80/tcp
7.7.7.7
Default
Enable
1000000
compArs1
7.7.7.7
Default
Disable
1000000
compArs2:80/tcp
8.8.8.8
Default
Enable
1000000
compArs2
8.8.8.8
Default
Enable
1000000
To Disable or Re-Enable Servers

Use the following commands to access the configuration level of the CLI:
enable
config
The enable command accesses the Privileged EXEC level. The end of the
command prompt changes from > to #. If you are prompted for a password,
enter the enable password assigned by the root administrator. The config
command accesses the configuration level.
At the configuration level, use the following command to access the operation level for the real server:
slb server server-name [ipaddr]
816 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Use one of the following commands to change the state of the server:
{disable | enable}
To verify the state change, use the show slb server command.
To Disable or Re-Enable Real Service Ports
Access the configuration level, then use the following command to access
the operation level for the server:
slb server server-name [ipaddr]
Use the following command to access the operation level for the service
port:
Use one of the following commands to change the state of the service port:
{disable | enable}
To verify the state change, use the show slb server command.
CLI Example
The following commands access the configuration level and disable real
server compArs1 and verify the change:
AX>enable
Password:********
AX#config
AX(config)#slb server compArs1
AX(config-real server)#disable
AX(config)#show slb server compArs1
Total Number of Services configured on Server compArs1: 1
Service
Current
Total
Req-pkt
Rev-pkt
State/Rsp Time
-----------------------------------------------------------------------------compArs1:80/tcp
0
0
0
0
Down 0.00 ms
compArs1: Total
0
0
0
0
Disabled
AX(config)#show slb server compArs1 config

Total Number of Services configured on Server compArs1: 1
H-check = Health check
Service
Max conn = Max. Connection
Address
H-check
Wgt = Weight
Status
Max conn Wgt
-----------------------------------------------------------------------------compArs1:80/tcp
7.7.7.7
Default
Enable
1000000
compArs1
7.7.7.7
Default
Disable
1000000
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
817 of 950

818 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Service Template Parameters
SLB Parameters
This chapter lists the parameters you can configure for Server Load Balancing (SLB).
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.
Note:
For information about health monitoring parameters, see Health Monitoring on page 373.
For information about GSLB parameters, see Global Server Load Balancing on page 427.
For information about FWLB parameters, see Firewall Load Balancing
on page 327.

The tables in this section list the template types that are valid for each service type, and the configurable settings in each type of template.
For information about server and port configuration templates, see
Server and Port Templates on page 353.
Note:
Table 28 lists the types of templates that are valid for each service type.
When you configure a virtual port, the AX device automatically adds any
default templates that are applicable to the service type. To override a
default template, you can configure another template of the same type and
bind that template to the virtual port instead.
For example, when you configure a virtual port that has the service type
Fast-HTTP, the following templates are automatically applied to the service
port:
TCP
HTTP
Connection Reuse (The parameters in this default template are all
unset.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
819 of 950

For information about the default settings in a template, see the section in
this chapter that describes the template. For the template types listed above,
see the following sections:
Connection Reuse Template Parameters on page 826
HTTP Template Parameters on page 832
TCP Template Parameters on page 854
To override the settings in a default template, you must configure another

template of the same type and apply that template to the service port instead.
For example, to override the settings that will be applied from the HTTP
template, configure another HTTP template and assign that one to the virtual port instead.
A virtual port can have only one of each type of template that is valid for the
ports 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 26 Template Types Valid for Service Types
Service Type
Template Type
FastHTTP
Cache
H
T
T
P
H
T
T
P
S
Client SSL
F
T
P
M
M
S
R
T
S
P
S
I
P
SIPTCP
Connection
Reuse
Cookie
Persistence
Destination-IP
Persistence
HTTP
Policy
S
I
P
S
S
M
T
P
SSLProxy
T
C
P
Server SSL
V
V
SIP
V
V
SMTP
V
V
SSL Session-ID
Persistence
Streamingmedia
TCP
Others
DNS
Source-IP
Persistence
U
D
P
V
V
TCP-Proxy
UDP
820 of 950
V
V
V
V
V
V
V
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Cache Template Parameters

Table 27 lists the parameters you can configure in RAM caching templates.
TABLE 27 Cache Template Parameters
Parameter
Template name
Age time

Name of the template.
Supported Values
String of 1-31 characters
[no] slb template cache

template-name
Default: default. The default template has the default values listed
below.
Config > Service > Template > Application >

RAM Caching
Number of seconds a cached object can remain in
the AX RAM cache without being requested.
1-999999 seconds (about 11-1/2 days)

Default: 3600 seconds (1 hour)
[no] age seconds
Default cache
action

RAM Caching
Controls whether the default action is to cache
cacheable objects, or not cache them. If you change
the default action to nocache, the AX device can
cache only those objects that match a dynamic policy rule that has the cache action.
Enabled or disabled
Default: disabled (Cacheable objects
are cached by default.)
[no] default-policy-nocache
Reload header
support

RAM Caching
Enables support for the following Cache-Control
headers:
Enabled or disabled
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
Cache size

RAM Caching
Size of the AX RAM cache.
The total size of all RAM caches combined can be
512 Mbytes on systems with 2 GBytes of memory
and 1024 Mbytes on systems with 4 GBytes of
memory. (To display the amount of memory your
system has, enter the show version command.)
1-512 Mbytes
Default: 80 Mbytes
[no] max-cache-size Mbytes

RAM Caching
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
821 of 950

TABLE 27 Cache Template Parameters (Continued)
Parameter
Maximum object
size

Maximum object size that can be cached. The AX
device will not cache objects larger than this size.
Minimum object
size

RAM Caching
minimum object size that can be cached. The AX
device will not cache objects smaller than this size.
Supported Values
1-8000000 bytes
Default: 81920 bytes (80 Kbytes)
[no] max-content-size bytes
1-8000000 bytes
Default: 500 bytes (1/2 Kbytes)
[no] min-content-size bytes
Dynamic
caching policy

RAM Caching
Configures dynamic caching.
[no] policy uri pattern
{cache [seconds] | nocache |
invalidate inv-pattern}
Valid URI pattern.

Default: Not set
The pattern option specifies the portion of the URI

string to match on.
The other options specify the action to take for URIs
that match the pattern:
cache [seconds] Caches the content. By default,
the content is cached for the number of seconds
configured in the template (set by the age command). To override the aging period set in the
template, specify the number of seconds with the
cache command.
nocache Does not cache the content.
invalidate inv-pattern Invalidates the content
that has been cached for inv-pattern.
RAM Caching
Verify host
822 of 950
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.
Enables the AX device to cache the host name in
addition to the URI for cached content. Use this
option if a real server that contains cacheable content will host more than one host name (for example, www.abc.com and www.xyz.com).
[no] verify-host
RAM Caching
Default: Disabled
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 27 Cache Template Parameters (Continued)
Parameter
Age header
insertion
Via header
insertion
Cookie removal

Disables insertion of Age headers into cached
responses.
[no] disable-insert-age
RAM Caching
Enables insertion of Via headers into cached
responses.
[no] disable-insert-via
RAM Caching
Removes cookies from server replies so the replies
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.)
Supported Values
Default: Disabled (Age header insertion is enabled.)
Default: Disabled (Age header insertion is enabled.)
Default: Disabled
[no] remove-cookies
Replacement
policy
Policy used to make room for new objects when the
RAM cache is full.
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.
The policy supported in the current

release is Least Frequently Used
(LFU).
Default: LFU
[no] replacement-policy LFU

RAM Caching
Client SSL Template Parameters

Table 28 lists the parameters you can configure in client SSL templates.
TABLE 28 Client SSL Template Parameters
Parameter
Template name

Supported Values
[no] slb template client-ssl

template-name
below.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
823 of 950

TABLE 28 Client SSL Template Parameters (Continued)
Parameter
Certificate
Authority (CA)
certificate name

Name of the Certificate Authority (CA) certificate
to use for validating client certificates.
Supported Values
Name of a CA certificate imported
onto the AX device
[no] ca-cert cert-name

Certificate name
Note: To use the certificate, you must import it onto

the AX device. (See Importing SSL Certificates
on page 467.)
Certificate to use for terminating or initiating SSL
connections with clients.
Name of a certificate imported onto

the AX device
[no] cert cert-name

Certificate
key-chain name

on page 467.)
Chain of certificates to use for terminating or initiating SSL connections with clients.
[no] chain-cert chain-cert-name

Certificate key
Key for the certificate, and the passphrase used to
encrypt the key.
Key name: string of 1-31 characters
[no] key key-name

[passphrase passphrase-string]
Passphrase: string of 1-16 characters
824 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
AX response to
connection
request from client

Action that the AX device takes in response to a clients connection request.
[no] client-certificate
{ignore | request | require}
Supported Values
One of the following:
ignore 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 handshake
does not proceed (it fails) if the client sends a NULL certificate or the
certificate is invalid.
Certificate
Revocation List
(CRL)
CRL to use for verifying that client certificates have

not been revoked.
Default: ignore
Name of a CRL imported onto the AX
device
When you add a CRL to a client SSL template, the

AX device checks the CRL to ensure that the certificates presented by clients have not been revoked by
the issuing CA.
[no] crl filename
Note: If you plan to use a CRL, you must set the
Mode to Require.
Session cache
size
Note: To use the CRL, you must import it onto the

AX device. (See Importing SSL Certificates on
page 467.)
Maximum number of cached sessions for SSL session ID reuse.
[no] session-cache-size number
0-131072
Default: 0 (session ID reuse is disabled)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
825 of 950

Parameter
Ciphers

Cipher suite to support for decrypting certificates
from clients.
Supported Values
One or more of the following:
[no] cipher
SSL3_RSA_DES_40_CBC_SHA
Config > Service > Template > SSL > Client SSL Cipher
SSL3_RSA_DES_192_CBC3_SHA
SSL3_RSA_RC4_128_MD5
SSL3_RSA_RC4_128_SHA
SSL3_RSA_RC4_40_MD5
TLS1_RSA_AES_128_SHA
TLS1_RSA_EXPORT1024_RC4_56
_MD5
_SHA
Close
notification
Closure alerts for SSL sessions. When this option is

enabled, 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
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 client.
Default: All the above are enabled.

Enabled or disabled
Default: disabled
[no] close-notify
Config > Service > Template > SSL > Client SSL Cipher
Connection Reuse Template Parameters

Table 29 lists the parameters you can configure in connection reuse templates.
TABLE 29 Connection Reuse Template Parameters
Parameter
Template name

Supported Values
[no] slb template

connection-reuse template-name
below.
826 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 29 Connection Reuse Template Parameters (Continued)
Parameter
Connection limit

Maximum number of reusable connections per
server port.
Supported Values
Limit-per-server 0-65535. For
unlimited connections, specify 0.
The smart flow control option queues HTTP packets

from clients when a server port reaches its configured connection limit, instead of dropping the packets.
Queue-depth for smart flow control

1-32000
Defaults:
[no] limit-per-server number

[smart-flow-control queue-depth]
Smart flow control: disabled. If this

option is enabled, the default queue
depth is 1000.
1-1024 connections
Default: 100

Connection
keepalive
Number of new reusable connections to open before

beginning to reuse existing connections. You can
specify 1-1024 connections.
Limit-per-server: 1000
[no] keep-alive-conn number

Connection idle
timeout

Maximum number of seconds a connection can
remain idle before it times out.
[no] timeout seconds
0-3600 seconds
To disable timeout, specify 0.
Default: 2400 seconds (40 minutes)
Cookie Persistence Template Parameters

Table 30 lists the parameters you can configure in cookie persistence templates.
TABLE 30 Cookie Persistence Template Parameters
Parameter
Template name
Cookie
expiration

Supported Values
[no] slb template persist cookie

template-name
below.
Config > Service > Template > Persistent > Cookie

Persistence
Number of seconds a cookie persists on a clients
PC before being deleted by the clients browser.
[no] expire expire-seconds
Persistence
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
0 to 31,536,000 seconds (one year)

If you specify 0, cookies persist only
for the current session.
Default: 10 years
Note: Although the default is 10 years
(essentially, unlimited), the maximum
configurable expiration is one year.
827 of 950

TABLE 30 Cookie Persistence Template Parameters (Continued)
Parameter
Domain
Path
Insert always

Adds the specified domain name to the cookie.
Supported Values
Valid domain name
[no] domain domain-name
Default: Not set

Persistence
Adds path information to the cookie.
1-31 characters
[no] path path-name
Default: /

Persistence
Specifies whether to insert a new persistence cookie
in every reply, even if the request already had an
AX cookie.
Enabled or disabled
Changes the granularity of cookie persistence:
Default: Disabled. The AX device

inserts a persistence cookie only if the
client request does not contain a persistence cookie inserted by the AX
device, or if the server referenced by
the cookie is unavailable.
Port The cookie inserted into the HTTP header

of the server reply to a client ensures that subse-
Port (selectable in the GUI but not

in the CLI)
[no] insert-always
Persistence
Match type
quent requests from the client will be sent to

the same real port on the same real server.
Server The cookie inserted into the HTTP
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 matchtype set to Server.)
Server
Service-group
Default: Port
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 initial request, subsequent requests are always
sent to the same service group.
Note: To use URL switching or host switching,
you also must configure an HTTP template
with the Host Switching or URL Switching
option.
[no] match-type
{server | service-group}
Persistence
828 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 30 Cookie Persistence Template Parameters (Continued)
Parameter
Cookie name

Specifies the name of the persistence cookie.
The format of the cookie depends on the match
type.
Supported Values
Default: sto-id
[no] name cookie-name
Ignore
connection limits

Persistence
Ignores connection limit settings configured on real
servers and real ports. This option is useful for
applications in which multiple sessions (connections) are likely to be used for the same persistent
cookie.
Enabled or Disabled
Default: Disabled. By default, the connection limit set on real servers and
real ports is used.
[no] dont-honor-conn-rules
Persistence
Destination-IP Persistence Template Parameters

Table 31 lists the parameters you can configure in destination-IP persistence
templates.
TABLE 31 Destination-IP Persistence Template Parameters
Parameter
Template name

Supported Values
[no] slb template persist

destination-ip template-name
below.
Config > Service > Template > Persistent >

Destination IP Persistence
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
829 of 950

TABLE 31 Destination-IP Persistence Template Parameters (Continued)
Parameter
Match type

Granularity of persistence:
Supported Values
Port Traffic from a given client to the same virtual port is always sent to the same real port. This
is the most granular setting.

in the CLI)
Server Traffic from a given client to the same

VIP is always sent to the same real server, for any
service port requested by the client.
Service-group
Server
Default: Port
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 service 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 service group. The next time URL or host switching
selects the same service group, the same real port
is used. Thus, service group selection is performed for every request, but once a service
group is selected for a request, the request goes to
the same real port that was selected the first time
that service group was selected.
Note: To use URL switching or host switching, you
also must configure an HTTP template with the
Host Switching or URL Switching option.
[no] match-type
830 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 31 Destination-IP Persistence Template Parameters (Continued)
Parameter
Netmask

Granularity of IP address hashing for initial server
port selection.
You can specify an IPv4 network mask in dotted
decimal notation.
Supported Values
Valid IPv4 network mask
Default: 255.255.255.255
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
Timeout

Number of minutes the mapping of a client source
IP to a real server persists after the last time traffic
from the client is sent to the server.
1-2000 minutes (about 33 hours)

Default: 5 minutes
[no] timeout timeout-minutes
Ignore
connection limits

client source IP address.
Enabled or Disabled
real ports is used.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
831 of 950

DNS Template Parameters

Table 32 lists the parameters you can configure in DNS templates.
TABLE 32 DNS Template Parameters
Parameter
Template name
Action for
malformed DNS
queries
(DNS security)

Supported Values
Default: None.
Config > Service > Template > Application > DNS

Action to take if the AX device detects a malformed
DNS query:
Drop or forward
Drop Drops the query

Forward to service group 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. You must specify the service group.
To use the forward option, you also

must specify the service group name.
Default: drop

Config > Service > Template > Application > DNS
HTTP Template Parameters

Table 33 lists the parameters you can configure in HTTP templates.
TABLE 33 HTTP Template Parameters
Parameter
Template name
Failover URL

Supported Values
[no] slb template http templatename
below.
Config > Service > Template > Application > HTTP

Fallback URL to send in an HTTP 302 response
when all real servers are down.
Valid URL
Default: Not set
[no] failover-url url-string

832 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 33 HTTP Template Parameters (Continued)
Parameter
Retry and
reassignment
when server
replies with 5xx
status code

Configures the AX device to retry sending a clients
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.
Supported Values
1-3
Default: Disabled. The AX device
sends the 5xx status code to the client.
When you enable this option, the
default number of retries is 3.
The first command shown below stops using a service port for 30 seconds after reassignment. The
second command does not.
[no] retry-on-5xx num
[no] retry-on-5xx-per-req num
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
Note: The current release does not support configuration of the log-retry option using the GUI.
Logging of
retries
Note: This option is supported only for virtual port

types HTTP and HTTPS. It is not supported for fastHTTP or any other virtual port type.
Logs HTTP retries. An HTTP retry occurs when the
AX device resends a clients HTTP request to a
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Enabled or disabled
Default: disabled
833 of 950

Parameter
Compression

Offloads Web servers from CPU-intensive HTTP
compression operations.
[no] compression {enable |
content-type content-string |
exclude-content-type contentstring | exclude-uri uri-string |
keep-accept-encoding enable |
level number |
minimum-content-length number}
Note: Compression is supported only for HTTP and
HTTPS virtual ports. Compression is not supported
of fast-HTTP virtual ports.
Supported Values
Any of the following:
enable Enables compression.
content-type Specifies the types
of content to compress, based on a
string in the content-type header of
the HTTP response. The contentstring can be 1-64 characters long.
exclude-content-type Specifies the
types of content to exclude from
compression.
exclude-uri Specifies URI strings
(up to 31 characters) to exclude
from compression.
keep-accept-encoding enable
Leaves the Accept-Encoding header
in HTTP requests from clients
instead of removing the header.
level Specifies the compression
level, 1-9. Each level provides a
higher compression ratio, 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.
minimum-content-length Specifies 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.
834 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Compression
(cont.)
Supported Values
Compression is disabled by default.
When it is enabled, the compression
options have the following defaults:
content-type text and application included by default
exclude-content-type not set
exclude-content not set
keep-accept-encoding disabled
level 1
Header insert /
replace
Inserts the specified header into an HTTP request or

reply.
minimum-content-length 120
bytes
Default: Not set
[no] request-header-insert
field:value [insert-always |
insert-if-not-exist]
[no] response-header-insert
field:value [insert-always |
insert-if-not-exist]
Header erase
Note: These options are not supported with the fasthttp 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 virtual 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.
Erases the specified header from an HTTP request
or reply.

Default: Not set
[no] request-header-erase field

[no] response-header-erase field
Note: These options are not supported with the fasthttp 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 virtual 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
835 of 950

Parameter
Host switching

Selects a service group based on the value in the
Host field of the HTTP header. The selection overrides the service group configured on the virtual
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:
Supported Values
Each host string can be all or part of an
IP address or host name.
Default: Not set
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 hostname 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 filter of the same type, the most specific match is used.
[no] host-switching
{starts-with |contains | ends-with}
host-string service-group servicegroup-name
Client IP insert

Inserts the clients source IP address into HTTP
headers.
[no] insert-client-ip
[http-fieldname] [replace]
Redirect rewrite
Modifies redirects sent by servers by rewriting the

matching URL string to the specified value before
sending the redirects to clients.

Default: Not set
When you enable this option, the client
IP address is inserted into the
X-ClientIP field by default, without
replacing any client IP addresses
already in the field.
Strings of 1-256 characters
Default: Not set
[no] redirect-rewrite
match url-string
rewrite-to url-string
836 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Redirect rewrite
secure
Strict
transaction
switching

Changes HTTP redirects sent by servers into
HTTPS redirects before sending the redirects to clients.
[no] redirect-rewrite secure
{port tcp-portnum}
Forces the AX device to perform the server selection process anew for every HTTP request. Without
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.
Supported Values
Default: Not set
Enabled or disabled
Default: Disabled
[no] strict-transaction-switch
URL switching

Selects a service group based on the URL string
requested by the client. The selection overrides the
service group configured on the virtual port.

Default: Not set
[no] url-switching
{starts-with | contains |
ends-with} url-string
If the URL-string does not match, the service group
configured on the virtual port is used.
filters:
starts-with url-string matches only if the URL
starts with url-string.
contains url-string matches if the url-string
appears anywhere within the URL.
ends-with url-string matches only if the URL
ends with url-string.
If a URL matches on more than one match filter of
the same type, the most specific match is used.
Note: You can configure a maximum of 16 URL
switching rules in a template. If you need to use
more, use aFleX policies.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
837 of 950

Parameter
URL hash
persistence
(also called URL
hash switching)

Selects a service group based on the hash value of
the first or last bytes of the URL string. The bytes
option specifies how many bytes to use to calculate
the hash value.
Supported Values
First or last
4-128 bytes
Default: Not set
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 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 130.)
[no] url-hash-persist
{first | last} bytes
[use-server-status}
Session
termination for
non-compliant
HTTP 1.1 clients

Enables the AX device to terminate HTTP 1.1 client
connections when the Connection: close header
exists in the HTTP request. This option is applicable
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-compliant HTTP 1.1. clients are not terminated.
Enabled or disabled
Default: disabled
[no] term-11client-hdr-conn-close
838 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Policy Template Parameters

Table 34 lists the parameters you can configure in Policy-Based SLB
(PBSLB) templates.
TABLE 34 Policy Template Parameters
Parameter
Template name
Black/white list
name
Action for overlimit traffic

Supported Values
[no] slb template policy templatename
Default: None.

Policy
Binds a black/white list to the virtual ports that use
this template.
Policy
Specifies the action to take for traffic that is over the
limit. You can specify one or more of the following
options:
Lockup Stops accepting new connection
requests for the specified number of minutes,
1-127.
Name of a configured black/white list.

Default: None.
You can specify the following:

Over-limit action reset
Lockup 1-127 minutes
Logging 1-255 minutes
Logging Generates a log message when traffic

goes over the limit. The min option specifies the
log interval and can be 1-255 minutes.
Default:
Reset Resets new connections until the number

of concurrent connections on the virtual port falls
below the connection limit.
Logging not set
Over-limit action drop

Lockup not set
[no] bw-list over-limit

{lockup min | logging min | reset}
Timeout for
dynamic clients

Policy
Specifies the number of minutes dynamic black/
white-list client entries can remain idle before aging
out.
1-127 minutes
Default: 5
[no] bw-list timeout minutes

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
839 of 950

TABLE 34 Policy Template Parameters (Continued)
Parameter
Action

Specifies the action to take for clients in the black/
white list.
Supported Values
The following settings are configurable:
[no] bw-list id id
{service service-group-name |
drop | reset}
List ID ID of the black/white list.

Policy
Group ID Group ID in the black/

white list.
Service-group name Name of an
SLB service group on the AX Series
device.
Action:
Note: If the option to use default selection if preferred 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, disable 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.
Drop Drops new connections

until the number of concurrent
connections on the virtual port
falls below the ports connection
limit. (The connection limit is set
in the black/white list.)
Reset Resets new connections
until the number of concurrent
connections on the virtual port
falls below the connection limit.
Logging Enables logging. You can
specify the number of minutes
between log messages. This option
reduces overhead caused by frequent recurring messages. You can
specify a logging interval from 0 to
60 minutes. To send a separate message for each event, set the interval
to 0.
Defaults:
List ID None
Group ID None
Action Not set
Overlap
Matches black/white list entries based on the clients destination IP address.

[no] overlap
Policy
840 of 950
Logging Disabled. If you enable

logging, the default for minutes is 3.
Enabled or Disabled
Default: Disabled. Matching is based
on the clients source IP address.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Matching based
on destination IP
address
Class list IP
address
matching

Matches black/white list entries based on the clients destination IP address.
[no] bw-list use-destination-ip
Policy
Specifies the IP address to use for matching entries
in an IP class list.
Destination IP address Matches based on the
destination IP address instead of the source IP
address.
Supported Values
Enabled or Disabled
Default: Disabled. Matching is based
on the clients source IP address.
Client IP address, destination IP

address, or request header.
Default: Matching is based on the clients 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.
Class list name
[no] class-list client-ip

{l3-dest |
l7-header [header-name]}
Policy
Applies an IP class list to the template.
[no] class-list name name
Policy
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Name of a configured class list

Default: not set
841 of 950

Parameter
Class list IP
limiting rule

Configures an IP limiting rule for the IP limiting
feature. IP limiting rules have the following parameters:
Limit ID (LID) Number from 1-31 that identifies the rule.
Connection limit Maximum number of concurrent connections allowed for a client.
Connection-rate limit Maximum number of
new connections allowed for a client within the
limit period.
Request limit Maximum number of concurrent
Layer 7 requests allowed for a client.
Request-rate limit Maximum number of Layer
7 requests allowed for a client within the limit
period.
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.
Supported Values
Valid values:
Limit ID (LID) 1-31
Connection limit 1-1048575
Connection-rate limit
1-4294967295 connections. The
limit period can be 100-6553500
milliseconds (ms), specified in
increments of 100 ms.
Request limit 1-1048575
Request-rate limit 1-4294967295
connections. The limit period can be
100-6553500 milliseconds (ms),
specified in increments of 100 ms.
Over-limit action Drop, Forward,
or Reset
Lockout period 1-1023 minutes
Logging Enabled or disabled. The
logging period can be 0-255 minutes.
Forward The AX device forwards the traffic.

If logging is enabled, the AX device also generates a log message.
Default:
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.
Connection-rate limit None
Lockout period Number of minutes during

which to apply the over-limit action after the client exceeds a limit. The lockout period is activated when a client exceeds any limit.
Logging Generates log messages when clients
exceed a limit. 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.
Limit ID (LID) None

Connection limit None
Request limit None
Request-rate limit None
Over-limit action Drop
Lockout period None
Logging Disabled. When logging
is enabled, the default logging
period is 0 (no wait period).
[no] class-list lid num

Policy
842 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Geo-location
statistics sharing

Enables sharing of PBLSB statistics counters for all
virtual servers and virtual ports that use the template. This option causes the following counters to
be shared:
Supported Values
Disabled
Permit
Deny
Connection number
Connection limit
[no] 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
Server SSL Template Parameters

Table 39 lists the parameters you can configure in Server SSL templates.
TABLE 35 Server SSL Template Parameters
Parameter
Template name
Certificate
Authority (CA)
certificate name

Supported Values
[no] slb template server-ssl

template-name
below.
Config > Service > Template > SSL > Server SSL
Name of the Certificate Authority (CA) certificate
to use for validating server certificates.
[no] ca-cert cert-name
Name of a CA certificate imported

onto the AX device
Default: None
on page 467.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
843 of 950

TABLE 35 Server SSL Template Parameters (Continued)
Parameter
Ciphers

Cipher suite to support for decrypting certificates
from servers.
Supported Values
One or more of the following:
[no] cipher
SSL3_RSA_RC4_40_MD5
_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.
SIP Template Parameters (SIP over TCP/TLS)

Table 36 lists the parameters you can configure in SIP templates for SIP
over TCP/TLS.
TABLE 36 SIP Template Parameters for SIP over TCP/TLS
Parameter
Template name

Supported Values
[no] slb template sip template-name
Default: None.
844 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 36 SIP Template Parameters for SIP over TCP/TLS (Continued)
Parameter
Client
Keep-Alive

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.
Supported Values
Enabled or disabled
Default: Disabled
[no] client-keep-alive
Server
Keep-Alive

For configurations that use a connection-reuse template, this option specifies how often the AX device
sends a SIP ping on each persistent connection. The
AX device silently drops the servers reply.
5-300 seconds
Default: 30
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 timeout is configured in the connection-reuse template.
See Connection Reuse Template Parameters on
page 826.)
Note: This option is applicable only if the configuration includes a connection-reuse template.
[no] server-keep-alive seconds
Insert Client IP

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.
Name of an IP header that inserts a client IP address.

Default: Disabled
[no] insert-client-ip
Select Client Fail
Action

Specifies the AX response when selection of a SIP
client fails. You can specify one of the following:
String Message string to send to the server; for
example: 480 Temporarily Unavailable. If the
message string contains a blank, use double quotation marks around the string.
The action can be one of the following:

Reset
Drop
Send message
Default: Reset
Drop Drops the traffic.

[no] select-client-fail {string |
drop}
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
845 of 950

TABLE 36 SIP Template Parameters for SIP over TCP/TLS (Continued)
Parameter
Select Server
Fail Action

Specifies the AX response when selection of a SIP
server fails. You can specify one of the following:
Supported Values
The action can be one of the following:
String Message string to send to the client; for

example: 504 Server Time-out. If the message
string contains a blank, use double quotation
marks around the string.
Drop
Reset
Send message
Default: Reset
Drop Drops the traffic.

[no] select-server-fail
{string | drop}
Exclude
Translation Body

Disables translation of the virtual IP address and
virtual port in specific portions of SIP messages:
Enabled or disabled
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}
Call timeout

Number of minutes a call can remain idle before the
AX Series terminates it.
1-250 minutes
Default: 30 minutes
[no] timeout minutes

846 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SIP Template Parameters (SIP over UDP)

Table 37 lists the parameters you can configure in SIP templates for SIP
over UDP.
TABLE 37 SIP Template Parameters for SIP over UDP
Parameter
Template name
Registrar service
group

Supported Values
[no] slb template sip template-name
Default: None.

Name of a configured service group of SIP Registrar servers.
Name of a configured service group
[no] registrar service-group

group-name
Header erase

Erases the specified SIP header from the SIP request
before sending it to a SIP Registrar.

Default: None
[no] header-erase string

Header insert

Inserts the specified SIP header into the SIP request

Default: None
[no] header-insert string

Header replace

Replaces the specified SIP header in the SIP request

Default: None
[no] header-replace string

new-string
Reverse NAT
disable
Disables reverse NAT based on the IP

addresses in an extended ACL. This option is
useful in cases where a SIP server needs to
reach another server, and the traffic must pass
through the AX device.
ID of a configured extended ACL.

Default: Not set. Reverse NAT is
enabled for all traffic from the server.
Configure the extended ACL to match on the SIP

server IP address or subnet as the source address,
and matches on the destination servers IP address
or subnet as the destination address.
[no] pass-real-server-ip-for-acl
acl-id
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
847 of 950

TABLE 37 SIP Template Parameters for SIP over UDP (Continued)
Parameter
Call timeout

Number of minutes a call can remain idle before the
AX Series terminates it.
Supported Values
1-250 minutes
Default: 30 minutes
[no] timeout minutes

SMTP Template Parameters

Table 38 lists the parameters you can configure in SMTP templates.
TABLE 38 SMTP Template Parameters
Parameter
Template name
Domain name
switching

Supported Values
[no] slb template smtp

template-name
below.

SMTP
Selects a service group based on the domain of the
client. You can specify all or part of the client
domain name.
This option is applicable when you have multiple
SMTP service groups.
If the client domain does not match, the service
group configured on the virtual port is used.
filters:
Strings
Default: Not set. All client domains
match, and any service group can be
used.
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.
(cont.)
848 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 38 SMTP Template Parameters (Continued)
Parameter
Domain name
switching
(cont.)

Supported Values
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 | endswith}
string service-group group-name
STARTTLS
command disable

SMTP
Disables support of certain SMTP commands. If a
client tries to issue a disabled SMTP command, the
AX sends the following message to the client: 502
- Command not implemented
Any of the following: VRFY, EXPN,

TURN
Default: VRFY, EXPN, and TURN are
enabled
[no] command-disable [vrfy] [expn]

[turn]
Note: To disable all three commands, simply enter
the following: command-disable
Email server
domain

SMTP
Email server domain. This is the domain for which
the AX Series device provides SMTP load balancing.
String
Default: mail-server-domain
[no] server-domain name
Service ready
message

SMTP
Text of the SMTP service-ready message sent to clients. The complete message sent to the client is constructed as follows:
String
Default: ESMTP mail service ready
200 - smtp-domain service-ready-string

[no] service-ready-message string
SMTP
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
849 of 950

TABLE 38 SMTP Template Parameters (Continued)
Parameter
STARTTLS
requirement

Specifies whether use of STARTTLS by clients is
required.
starttls
{disable | optional | enforced}
SMTP
Supported Values
Disabled Clients cannot use
STARTTLS. Use this option if you
need to disable STARTTLS support
but you do not want to remove the
configuration.
Optional Clients can use STARTTLS but are not required to do so.
Enforced 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 command
first
Default: Disabled
Source-IP Persistence Template Parameters

Table 39 lists the parameters you can configure in source-IP persistence
templates.
TABLE 39 Source-IP Persistence Template Parameters
Parameter
Template name

Supported Values
[no] slb template persist source-ip

template-name
below.
Config > Service > Template > Persistent > Source

IP Persistence
850 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 39 Source-IP Persistence Template Parameters (Continued)
Parameter
Match type

Granularity of persistence:
Supported Values
Port Traffic from a given client to the same virtual port is always sent to the same real port. This
is the most granular setting.

in the CLI)
Server Traffic from a given client to the same

VIP is always sent to the same real server, for any
service port requested by the client.
Service-group
Server
Default: Port
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 service 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 service group. The next time URL or host switching
selects the same service group, the same real port
is used. Thus, service group selection is performed 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-Members Option in Persistence Templates on
page 901.)
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
IP Persistence
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
851 of 950

TABLE 39 Source-IP Persistence Template Parameters (Continued)
Parameter
Netmask

Granularity of IP address hashing for server port
selection.
Supported Values
Valid IPv4 network mask
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 subnet 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
Timeout

IP Persistence
Number of minutes the mapping of a client source
IP to a real server persists after the last time traffic
from the client is sent to the server.
1-2000 minutes (about 33 hours)

Default: 5 minutes
Note: The timeout for a source-IP persistent session

will not be reset if the timeout in the source-IP persistence 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.
Ignore
connection limits

IP Persistence
client source IP address.
Enabled or Disabled
real ports is used.
IP Persistence
852 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

SSL Session-ID Persistence Template Parameters

Table 40 lists the parameters you can configure in SSL session-ID persistence templates.
TABLE 40 SSL Session-ID Persistence Template Parameters
Parameter
Template name
Timeout

Supported Values
[no] slb template persist ssl-sid

template-name
below.

SSL Session ID Persistence
Number of minutes the mapping of an SSL session
ID to a real server and real server port persists after
the last time traffic using the session ID is sent to
the server.
1-250 minutes
Default: 5 minutes
Ignore
connection limits

SSL session ID.
Enabled or Disabled
real ports is used.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
853 of 950

Streaming-Media Template Parameters

Table 41 lists the parameters you can configure in streaming-media templates.
TABLE 41 Streaming-media Template Parameters
Parameter
Template name
URI switching

Supported Values
[no] slb template streaming-media

template-name
below.
Config > Service > Template > Application > RTSP

Service group to which to send requests for a specific URI.
[no] uri-switching stream
uri-string

Default: Requests are sent to the service group that is bound to the virtual
port.
Config > Service > Template > Application > RTSP

Note: This option is supported only for Windows
Media Server.
TCP Template Parameters

Table 42 lists the parameters you can configure in TCP templates.
TABLE 42 TCP Template Parameters
Parameter
Template name

Supported Values
[no] slb template tcp template-name
below.
60-120000 seconds (about 33 hours)

Idle timeout
Number of seconds a connection can remain idle

before the AX Series device terminates it.
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 multiple
of 60. For example, if you enter 70, the actual timeout is 60 seconds.
854 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 42 TCP Template Parameters (Continued)
Parameter
Aging of halfclosed sessions
Server reset

Enables aging of half-closed TCP sessions. A halfclosed TCP session is a session in which the server
sends a FIN but the client does not reply with an
ACK.
[no] half-close-idle-timeout
seconds
Sends a TCP RST to the real server after a session
times out.
Supported Values
60-15000 seconds
Default: Not set. The AX device keeps
half-closed sessions open indefinitely.
Enabled or disabled
Default: Disabled
[no] reset-fwd
Client reset
Initial window
size

Sends a TCP RST to the client after a session times
out.
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
Sets the initial TCP window size in SYN ACK
packets to clients. The TCP window size in a SYN
ACK or ACK packet specifies the amount of data
that a client can send before it needs to receive an
ACK.
Enabled or disabled
Default: Disabled
1-65535 bytes
Default: The AX device uses the TCP
window size set by the client or server.
[no] initial-window-size bytes

TCP-Proxy Template Parameters

Table 42 lists the parameters you can configure in TCP-proxy templates.
TABLE 43 TCP-Proxy Template Parameters
Parameter
Template name
FIN timeout

Supported Values
[no] slb template tcp-proxy

template-name
below.
Config > Service > Template > TCP Proxy

Number of seconds that a connection can be in the
FIN-WAIT or CLOSING state before the AX Series
terminates the connection.
[no] fin-timeout seconds
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
1-60 seconds
Default: 5 seconds
855 of 950

TABLE 43 TCP-Proxy Template Parameters (Continued)
Parameter
Aging of halfclosed sessions
Idle timeout
Nagle algorithm
Receive buffer
size
Retransmit
retries
SYN retries
Time-Wait
Transmit buffer
size
856 of 950

Enables aging of half-closed TCP sessions. A halfclosed TCP session is a session in which the server
sends a FIN but the client does not reply with an
ACK.
[no] half-close-idle-timeout
seconds
Config > Service > Template > L4 > TCP Proxy
Number of minutes that a connection can be idle
before the AX Series terminates the connection.
Enables Nagle congestion compression (described
in RFC 896).
[no] nagle
Maximum number of bytes addressed to the port
that the AX Series will buffer.
[no] receive-buffer number
Number of times the AX Series can retransmit a
data segment for which the AX Series does not
receive an ACK.
[no] retransmit-retries number
Number of times the AX Series can retransmit a
SYN for which the AX Series does not receive an
ACK.
[no] syn-retries number
Number of seconds that a connection can be in the
TIME-WAIT state before the AX Series transitions
it to the CLOSED state.
[no] timewait number
Number of bytes sent by the port that the AX Series
will buffer.
[no] transmit-buffer number
Supported Values
60-15000 seconds
Default: Not set. The AX device keeps
half-closed sessions open indefinitely.

Enabled or disabled
Default: Disabled
1-2147483647 bytes
Default: 87380 bytes
1-20
Default: 3
1-20
Default: 5
1-60 seconds
Default: 5 seconds
1-2147483647
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 43 TCP-Proxy Template Parameters (Continued)
Parameter
Initial window
size
Minimum TCP
MSS size

Sets the initial TCP window size in SYN ACK
packets to clients. The TCP window size in a SYN
ACK or ACK packet specifies the amount of data
that a client can send before it needs to receive an
ACK.
[no] initial-window-size bytes
Sets the Minimum TCP Maximum Segment Size
(MSS) for transmissions from clients.
Supported Values
1-65535 bytes
Default: The AX device uses the TCP
window size set by the client or server.
128-4312
Default: 538
[no] mss
UDP Template Parameters

Table 44 lists the parameters you can configure in UDP templates.
TABLE 44 UDP Template Parameters
Parameter
Template name

Supported Values
[no] slb template udp template-name
below.
Immediate
Config > Service > Template > L4 > UDP

Aging
Specifies how quickly sessions are terminated when

the request is received.
aging {immediate | short [seconds]}
Immediate aging:
Response Received
Session is terminated within 1 second.
Short, with an aging period of 1-6

seconds
Default: Not set. The idle timeout
value in the template is used instead.
If you enable short aging, the default
aging period is 3 seconds.
No Response Idle timeout value in UDP template is used.

Short aging:
Response Received
Session is terminated within 1 second.
No Response Session is terminated after configured short aging period.
Note: If you are configuring DNS load balancing,
A10 Networks recommends using the immediate
option.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
857 of 950

Global SLB Parameters
TABLE 44 UDP Template Parameters (Continued)
Parameter
Idle timeout
Server
reselection

Number of seconds a connection can remain idle
before the AX Series terminates it.
[no] idle-timeout number
Configures the AX device to select another real
server if the server that is bound to an active connection goes down. Without this option, another
server is not selected.
[no] re-select-if-server-down
Supported Values
Enabled or disabled
Default: Disabled

Table 46 lists the SLB parameters you can configure globally.
TABLE 45 Global SLB Parameters
Parameter
Server state

Globally disables or re-enables a real or virtual
server.
Supported Values
Enabled or disabled
Default: Enabled
{disable | enable} slb server

[server-name] [port port-num]
{disable | enable}
slb virtual-server [server-name]
[port port-num]
858 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 45 Global SLB Parameters (Continued)
Parameter
DSR health
check

Enables Layer 4-7 health checking in Direct Server
Return (DSR) configurations.
Supported Values
Enabled or disabled
Default: Disabled
[no] slb dsr-health-check-enable

Config > Service > SLB > Global > Settings
Graceful
shutdown
Maximum
session life
Note: Additional configuration is required. See

Configuring Health Monitoring of Virtual IP
Addresses in DSR Deployments on page 386.
Enables the AX device to wait for the specified
grace period before moving active sessions on a
deleted or disabled port or server to the delete
queue.
[no] slb graceful-shutdown
grace-period
[server | virtual-server]
[after-disable]
Maximum session life following completion of a
TCP flow.

Default: Not set. When you delete a
real or virtual service port, the AX
device places all the ports sessions in
the delete queue, and stops accepting
new sessions on the port.
1-40 seconds
Default: 2 seconds
[slb] msl-time seconds

Hardware-based
SYN cookies

Enables system-wide protection against TCP SYN
flood attacks. SYN cookies enable the AX device to
continue to serve legitimate clients during a TCP
SYN flood attack, without allowing illegitimate
traffic to consume system resources.
On-Threshold Specifies the maximum number
of concurrent half-open TCP connections
allowed on the AX device, before SYN cookies
are enabled. If the number of halfopen TCP connections exceeds the on-threshold, the AX device
enables SYN cookies. You can specify 02147483647 half-open connections.
Off-Threshold - Specifies the minimum number
of concurrent half-open TCP connections for
which to keep SYN cookies enabled. If the number of half-open TCP connections falls below this
level, SYN cookies are disabled. You can specify
0-2147483647 halfopen connections.
Disabled or Enabled
On-Threshold 0-2147483647 halfopen connections
Off-Threshold 0-2147483647 halfopen connections
Default: Disabled
Note: If you leave the On-Threshold
and Off-Threshold fields blank, SYN
cookies are enabled and are always on
regardless of the number of half-open
TCP connections present on the AX
device.
[no] syn-cookie
[on-threshold num off-threshold
num]
Note: This option is supported only on models
AX 2200, AX 3100, AX 3200, AX 5100, and
AX 5200.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
859 of 950

Parameter
Use of IP pool
default gateways
by real servers
Source-IP based
connection rate
limiting

Enables use of IP pool default gateways to forward
traffic from 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 servers IP address, and a default
gateway is defined for the pool, the AX device forwards the server traffic through the pools default
gateway.
[no] slb snat-gwy-for-l3
Note: This parameter is not configurable using the
GUI.
Protects the system from excessive connection
requests from individual clients.
[no] slb conn-rate-limit src-ip
conn-limit
per {100 | 1000}
[shared]
[exceed-action [log]
[lock-out lockout-period]]
Note: The current release does not support configuration of this feature using the GUI.
For more information about this feature, see
Source-IP Based Connection Rate Limiting on
page 726.
Supported Values
Enabled or disabled
Default: Disabled
Connection limit 1-1000000.

Limit period One of the following:
100 milliseconds (one tenth of a
second)
1000 milliseconds (one second)
Scope One of the following:
Shared Connection limit applies
as an aggregate to all virtual ports.
Not shared Connection limit
applies separately to each virtual
port. (This is the default behavior.
There is no Not shared option.)
(cont.)
860 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Source-IP based
connection rate
limiting
(cont.)
Supported Values
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 connection limit.
Lockout Locks out the client for a
specified number of seconds. During the lockout period, all connection requests from the client are
dropped. The lockout period can be
1-3600 seconds (1 hour). There is
no default.
DNS caching
Configures the AX device to locally cache DNS

responses to client requests.
Note: A DNS reply begins aging as soon as it is
cached and continues aging even if the cached reply
is used after aging starts. Use of a cached reply does
not reset the age of that reply.
Default: Not configured

Enabled or disabled
The cache aging timeout can be
1-1000000 seconds.
Default: disabled. When you enable
DNS caching, the default cache aging
timeout is 300 seconds.
[no] dns-cache-enable
[no] dns-cache-age seconds
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
861 of 950

Parameter
Source NAT on
VIP

Globally enables IP NAT support for VIPs.
Source IP NAT can be configured on a virtual port
in the following ways:
Supported Values
Enabled or disabled
Default: disabled
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.
Layer 7 request
accounting
[no] slb snat-on-vip

Globally enables Layer 7 request accounting.
Note: Layer 7 request accounting is automatically
enabled for service groups that use the least-request
load-balancing method.
Enabled or disabled
Default: disabled
To display Layer 7 request statistics, view details

for the service group, real port, or virtual port.
[no] slb enable-l7-req-acct
Hardware-based
content
compression

Enables hardware-based compression.
When you enable hardware-based compression, all
compression settings configured in HTTP templates, 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.
Enabled or disabled
Default: Disabled
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 compression module.
[no] slb hw-compression
862 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Idle timeout for
passthrough TCP
sessions
Trunk load
balancing
Fast-path
processing

Sets the idle timeout for pass-through TCP sessions.
A pass-through TCP session is one that is not terminated by the AX device (for example, a session for
which the AX device is not serving as a proxy for
SLB).
Specify the name of a TCP template. The idle timeout in the TCP template is used.
Only the idle timeout setting in the specified TCP
template is applicable to pass-through TCP sessions. None of the other options in TCP templates
affect pass-through TCP sessions.
[no] slb transparent-tcp-template
template-name
GUI.
Disables or re-enables trunk load balancing or
Layer2/Layer 3 traffic.
[no] slb l2l3-trunk-lb-disable
GUI.
Enables fast-path processing, wherein the AX
device does not perform a deep inspection of every
field within a packet.
Supported Values
Name of a configured TCP template.
To use the default TCP template, specify the name default.
Default: The default idle timeout for
pass-through TCP sessions is 30 minutes. The default idle timeout in TCP
templates is 120 seconds.
Enabled or disabled
Default: Enabled.
Enabled (slb fast-path-disable) or disabled (no slb fastpath-disable)
[no] slb fast-path-disable

TCP Maximum
Segment Size
(MSS)
Statistics
collection
Changes the minimum TCP MSS the AX device

allows for client traffic.
Default: Enabled. Deep inspection of

every packet field is enabled.
128-750
Default: 538
[no] slb mss-table num

GUI.
Globally disables or re-enables collection of statistical data for system resources and for load-balancing
resources.
stats-data-disable
stats-data-enable
resources also must be enabled on the individual
resources.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Enabled or disabled
Default: Statistical data collection for
system resources is enabled by default.
This also allows collection for those
individual load-balancing resources on
which collection is enabled.
Statistical data collection also is enabled by default on individual load-balancing resources.
863 of 950

Parameter
SLB application
buffer threshold

Fine-tunes thresholds for SLB buffer queues.
Hardware buffer IO buffer threshold. For each
CPU, if the number of queued entries in the IO
buffer reaches this threshold, fast aging is enabled and no more IO buffer entries are allowed to
be queued on the CPUs IO buffer.
Supported Values
The supported values and defaults
depend on the AX model. See the CLI
online help.
Relieve threshold Threshold at which fast aging

is disabled, to allow IO buffer entries to be
queued again.
Low buffer threshold Threshold of queued system buffer entries at which the AX begins refusing new incoming connections.
High buffer threshold Threshold of queued system buffer entries at which the AX device drops a
connection whenever a packet is received for that
connection.
Compression
block size
DDoS Protection
Log rate limiting
[no] slb buff-thresh hw-buff num

relieve-thresh num sys-buff-low num
sys-buff-high num
Changes the default compression block size used for
SLB.
[no] compress-block-size bytes
Config > Service > SLB > Global > Rate-Limit Log
See DDoS Protection on page 715.
Configures rate limiting settings for system logging:
Max-local-rate Specifies the maximum number
of messages per second that can be sent to the
local log buffer.
Default: Not set

Max-local-rate 1-100 messages
per second
Max-remote-rate 1-100000 messages per second
Max-remote-rate Specifies the maximum number of messages per second that can be sent to
remote log servers.
Exclude-destination Local,
remote, or both
Exclude-destination Excludes logging to the

specified destination.
Max-local-rate 32 messages per

second
slb rate-limit-logging
[max-local-rate msgs-per-second]
[max-remote-rate msgs-per-second]
[exclude-destination {local |
remote}]
Config > Service > SLB > Global > Rate-Limit Log
864 of 950
6000-32000 bytes
Defaults:
Max-remote-rate 15000 messages

per second
Exclude-destination Logging to
both destinations is enabled.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Real Server Parameters

Table 46 lists the parameters you can configure on real servers.
TABLE 46 Real Server Parameters
Parameter
Server name
and IP address

Name and IP address of the real server.
[no] slb server server-name ipaddr
Server state
Note: The name does not need to match the hostname configured on the server.
State of the real server.
[no] {disable | enable}
Real server
template

Configuration template of real server parameters.
[no] template server template-name
Health check
Enables or disables Layer 3 health monitoring and

species the monitor to use.
[no] health-check
[monitor-name]
Connection
limit
Number of concurrent connections allowed on a real

server.
Supported
Values
String of 1-31
characters
Configurable in
Real Server
Template?
N/A
IPv4 or IPv6
address
Enabled or disabled
No
Default: Enabled
Name of a configured real server
template
Default: Default
real server template
Enabled or disabled
Default: Enabled;
ping (ICMP)
1-1000000 (one
million) if configured on the real
server; 1-1048575
if configured in the
server template
N/A
Yes
Yes
Default: 1000000
if configured on
the real server;
1048575 if configured in the server
template
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
865 of 950

TABLE 46 Real Server Parameters (Continued)
Parameter
Connection
resume

Maximum number of connections the server can
have before the AX device resumes use of the
server. Use does not resume until the number of
connections reaches the configured maximum or
less.
[no] conn-resume connections
Service port
TCP or UDP port number.

[no] port port-num {tcp | udp}
Config > Service > SLB > Server - Port
(For parameters you can set on the service port, see
Real Service Port Parameters on page 868.)
Slow start
Allows time for a server to ramp up after the server

is enabled or comes online, by temporarily limiting
the number of new connections on the server.
Supported
Values
1-1000000 (one
million) connections
Default: Not set.
The AX device is
allowed to start
sending new connection requests to
the server as soon
as the number of
connections on the
server falls back
Transport protocol:
TCP or UDP

Enabled or disabled
Default: Disabled
Administrative weight of the server, used for

weighted load balancing (weighted-least-connection
or weighted-round-robin).
N/A
Port number:
0-65534
[no] slow-start
Weight
Configurable in
Real Server
Template?
Yes, but as additional parameter
with conn-limit
command (CLI) or
additional field
under Connection
Limit Status (GUI)
1-100
Yes
Note: Template
configuration of
this feature provides additional
options. See
Slow-Start on
page 366.
No
Default: 1
[no] weight num

External IP
address

External IP address, used for reaching a server in a
private network from outside the network.
Valid IP address
No
Default: Not set
[no] external-ip ipaddr

866 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 46 Real Server Parameters (Continued)
Parameter
Spoofing
cache
Statistics
collection

Enables support for a spoofing cache server. A
spoofing cache server uses the clients IP address
instead of its own as the source address when
obtaining content requested by the client.
This command applies to the Transparent Cache
Switching (TCS) feature. (See Transparent Cache
Switching on page 295.)
[no] spoofing-cache
Supported
Values
Enabled or disabled
Default: Disabled

the server.
Enabled or
disabled
stats-data-enable
Default: enabled
Configurable in
Real Server
Template?
No
No
stats-data-disable
GSLB IPv6
mapping

Assigns an IPv6 address to the real server for
GSLB.
Valid IPv6 address
No
Default: None
[no] ipv6 ipv6-addr

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
867 of 950

Real Service Port Parameters

Table 47 lists the parameters you can configure on individual service ports
on real servers.
TABLE 47 Real Service Port Parameters
Parameter
Service port
number and
transport protocol

TCP or UDP port number.
[no] port port-num {tcp | udp}
In the CLI, this is set at the real server configuration
level. In the GUI, this is set in the Port section of the
Server page.
Service port
state
Real server
port template
State of the service port.

Configuration template of real port parameters.
[no] template port template-name
Health check
Enables or disables health monitoring and species

the monitor to use.
To base the ports health on the health of another
port of the same type on the same server, use the follow-port option instead.
[no] health-check
[monitor-name |
follow-port portnum method-type]
Note: In the current release, the follow-port option
is not supported in the GUI.
868 of 950
Configurable in
Real Port
Template?
N/A
Supported
Values
TCP or UDP
0-65534
Default: Not set
Note: Port number
0 is a wildcard port
used for IP protocol load balancing. (For more
information, see
IP Protocol Load
Balancing on
page 263.)
Enabled or disabled
No
Default: Enabled
Name of a configured real port template
Default: Default
real port template
Enabled or disabled
N/A
Yes
(The follow-port
option can not be
configured using a
template.)
Default: The AX
performs the
default TCP or
UDP check every
5 seconds. (See
Default Health
Checks on
page 373.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 47 Real Service Port Parameters (Continued)
Parameter
Connection
limit

Number of concurrent connections allowed on the
service port.
Connection
resume
Maximum number of connections the port can have

before the AX device resumes use of the port. Use
does not resume until the number of connections
reaches the configured maximum or less.
[no] conn-resume connections
Weight
Administrative weight of the service port, used for

weighted load balancing (service-weighted-leastconnection).
Supported
Values
1-1000000 (one
million) if configured on the server
port; 1-1048575 if
configured in the
server port template
Default: 1000000
if configured on
the server port;
1048575 if configured in the server
port template
1-1000000 (one
million) connections
Default: Not set.
The AX device is
allowed to start
sending new connection requests to
the port as soon as
the number of connections on the
port falls back
1-100
Configurable in
Real Port
Template?
Yes
Yes, but as additional parameter

with conn-limit
command (CLI) or
additional field
under Connection
Limit Status (GUI)
Yes
Default: 1
[no] weight num

No-SSL

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.
Enabled or
disabled
No
Default: Disabled
(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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
869 of 950

Service Group Parameters
TABLE 47 Real Service Port Parameters (Continued)
Parameter
Statistics
collection

the port.
Supported
Values
Enabled or
disabled
stats-data-enable
Default: enabled
Configurable in
Real Port
Template?
No
stats-data-disable

Table 47 lists the parameters you can configure in service groups.
TABLE 48 Service Group Parameters
Parameter
Service group
name and type
Member

Name of a service group and the transport protocol
used by service ports in the group.
Supported Values
TCP or UDP
[no] slb service-group group-name

{tcp | udp}

Real servers and service ports managed by the
group.
[no] member server-name:portnum
[disable | enable]
[priority num]
[template template-name]
[stats-data-disable | stats-dataenable]
The enable | disable options change the server and
port state within the service group only.
The priority option enables you to designate some
real servers as backups (the lower priority servers)
to be used only if the higher priority servers all are
unavailable.
The template option binds a real port template to
the port.
870 of 950
Name of a configured real server, and

a service port number configured on
the server
The priority can be 1-16.
Defaults:
State enabled
Priority 1
Template not set
Statistical data collection enabled
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 48 Service Group Parameters (Continued)
Parameter
Load balancing
method

Algorithm used to select a real server and service
port to fulfil a clients request.
[no] method lb-method
Note: The fastest-response algorithm takes effect
only if the traffic rate on the servers is at least 5 connections per second (per server). If the traffic rate is
lower, the first server in the service group usually is
selected.
Supported Values
Fastest-response Selects the server
with the fastest SYN-ACK response
time.
Least-connection Selects the server
that currently has the fewest connections.
Service-least-connection Selects
the server port that currently has the
fewest connections. 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 servers administratively
assigned weight and the number of
connections on the server.
Service-weighted-least-connection
Same as weighted-least-connection, 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.
Weighted-round-robin Selects
servers in rotation, biased by the
servers administratively assigned
weights.
If the weight value is the same on
each server, this load-balancing
method simply selects the servers in
rotation.
(cont.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
871 of 950

Parameter
Load balancing
method
(cont.)
Supported Values
Round Robin Strict Provides a
more exact round-robin method.
The standard, default round robin
method is optimized for high performance. 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 285.)
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.
Stateless-per-pkt-round-robin Balances server load by sending each
packet to a different server, in rotation. This method is applicable only
for UDP DNS traffic.
Stateless-src-ip-only-hash Balances server load based on a hash
value calculated using the source IP
address only.
Default: Round robin (simple rotation
without weighting)
872 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Health monitor
Minimum active
members
Reset after server

selection
failure
Statistics
collection

Assigns a health monitor to all members in the service group.
This option 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.
Uses backup servers even if some primary servers
are up. To configure this parameter, specify the
number of primary servers that can still be active
before the backup servers are used.
The skip-pri-set option specifies whether the
remaining primary servers continue to be used. If
you use this option, the AX device uses only the
backup servers and stops using any of the primary
servers.
[no] min-active-member num
[skip-pri-set]
Sends a TCP reset (RST) to clients if server selection fails.
[no] reset-on-server-selectionfail
Supported Values
The default health monitor (IP ping) or
the name of a configured health monitor
Default: Not set
1-63
Default: Not set. Backup servers are
used only if all primary servers are
unavailable.
When you configure this parameter,
the skip-pri-set option is disabled by
default, for all load-balancing methods
except round-robin. For round-robin
(the default), skip-pri-set is always
enabled and can not be disabled.
Enabled or disabled
Default: disabled
Note: For more information about this option, see

Sending a Reset After Server Selection Failure on
page 895.
the service group.
Enabled or
disabled
stats-data-enable
Default: enabled
stats-data-disable
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
873 of 950

Virtual Server Parameters

Table 49 lists the parameters you can configure on virtual servers.
TABLE 49 Virtual Server Parameters
Parameter
Virtual server
name and virtual IP address

Name to identify the virtual server on the AX
device, and the virtual IP address that clients will
request.
To configure a single VIP, enter the IP address.
To configure a contiguous range of VIPs, enter a
subnet, in Classless Interdomain Routing (CIDR)
format.
Configurable in
Virtual Server
Template?
N/A
Supported
Values
String of 1-31
characters
IPv4 or IPv6
address
[no] slb virtual-server name ipaddr

or
[no] slb virtual-server server-name
starting-ip
{subnet-mask | /mask-length}
Virtual server
state

State of the virtual server.
[no] {disable
[when-all-ports-down] |
enable}
The when-all-ports-down option automatically disables the virtual server if all its service ports are
down. If OSPF redistribution of the VIP is enabled,
the AX device also withdraws the route to the VIP
in addition to disabling the virtual server.
Enabled or disabled
No
Default: Virtual
servers are enabled
by default. The
when-all-portsdown option is disabled by default.
Config > Service > Server > Virtual Server
Virtual server
template
Note: The when-all-ports-down option is not configurable using the GUI.

Configuration template of virtual server parameters.
[no] template virtual-server
template-name
Config > Service > Server > Virtual Server
874 of 950
Name of a configured virtual server

template
N/A
Default: Default
virtual server template
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

TABLE 49 Virtual Server Parameters (Continued)
Parameter
Virtual
service port
number and
service type
[no] port port-num service-type
Supported
Values
Port number:
0-65535
Config > Service > SLB > Virtual Server - Port
Service type:
Service type can be one of the following:
fast-http
fast-http Streamlined Hypertext Transfer Protocol (HTTP) service
ftp
ftp File Transfer Protocol
https
http HTTP
mms
https Secure HTTP (SSL)
rtsp
mms Multimedia Messaging Service
sip
rtsp Real Time Streaming Protocol
smtp
sip Session Initiation Protocol
ssl-proxy
smtp Simple Mail Transfer Protocol
tcp
ssl-proxy SSL proxy service
udp
tcp Transmission Control Protocol
others
udp User Datagram Protocol

Service port number and service type.
others Wildcard port used for IP protocol
Configurable in
Virtual Server
Template?
N/A
http
load balancing. (For more information, see

IP Protocol Load Balancing on page 263.)
ARP disable
(For parameters you can set on the service port, see

Virtual Service Port Parameters on page 877.)
Disables or re-enables ARP replies from a virtual
server.
HA group ID to use for session backup.
Default: Disabled;
ARP replies are
enabled.
1-31
Default: Not set
[no] arp-disable
HA group ID
VIP-based
failover
Enabled or disabled

Enables dynamic failover based on server weight.
The configured amount is subtracted from the HA
groups priority value for each real server that goes
down.
1-255
No
No
No
Default: Not set

b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
875 of 950

TABLE 49 Virtual Server Parameters (Continued)
Parameter
OSPF
redistribution

Explicitly include or exclude the VIP in OSPF
redistribution.
Supported
Values
Set or not set
Configurable in
Virtual Server
Template?
No
Default: Not set
Setting this option enables you to selectively redistribute 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 following commands at the OSPF configuration level:
redistribute vip only-not-flagged or redistribute vip
[no] redistribution-flagged
Statistics
collection
the virtual server.
Enabled or
disabled
stats-data-enable
Default: enabled
No
stats-data-disable
876 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Virtual Service Port Parameters

Table 50 lists the parameters you can configure on individual service ports
on virtual servers.
TABLE 50 Virtual Service Port Parameters
Parameter
Virtual
service port
number and
service type

Service port number and service type.
[no] port port-num service-type
Supported
Values
Port number:
0-65535
Config > Service > SLB > Virtual Server - Virtual

Server Port
Service type:
In the CLI, this is set at the virtual server configuration level. In the GUI, this is set on the Virtual
Server Port page.
ftp
Service type can be one of the following:

fast-http Streamlined Hypertext Transfer Protocol (HTTP) service
ftp File Transfer Protocol
http HTTP
https Secure HTTP (SSL)
mms Multimedia Messaging Service
rtsp Real Time Streaming Protocol
sip Session Initiation Protocol over UDP
sip-tcp SIP over TCP
sips Secure SIP over TLS
Configurable in
Virtual Port
Template?
N/A
fast-http
http
https
mms
rtsp
sip
sip-tls
sips
smtp
ssl-proxy
tcp
udp
smtp Simple Mail Transfer Protocol

ssl-proxy SSL proxy service
tcp Transmission Control Protocol
udp User Datagram Protocol
Virtual
service port
state
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.
State of the virtual service port.
Server Port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Enabled or disabled
No
Default: Enabled
877 of 950

TABLE 50 Virtual Service Port Parameters (Continued)
Parameter
Virtual port
template

Configuration template of virtual port parameters.
[no] template virtual-port
template-name
Server Port
Service group
Service group bound to the virtual service port. The

AX device uses real servers and ports in the service
group to fulfill requests for the virtual service port.
Configurable in
Virtual Port
Template?
N/A
Supported
Values
Name of a configured virtual port
template
Default: Default
virtual port template
No
Default: Not set
Template

Server Port
Connection or application template to use for service port parameters.
[no] template template-type
template-name
Server Port
Template type:
One of the types
described in Service Template
Parameters on
page 819.
N/A
Template name:
Name of a configured template.
Access
Control List
(ACL)
ID of an ACL.
If you do not also specify a NAT pool name, the
ACL is used to deny or permit inbound traffic on the
service port.
Default: Depends
on whether the
template type has a
default and
whether the service type uses that
template type. (See
Service Template
Parameters on
page 819.)
Valid standard or
extended ACL ID
Default: None
No
If you do specify a NAT pool name, the ACL does

not permit or deny traffic. Instead, it binds the
source addresses in the ACL to the NAT pool. The
NAT pool is used only for the client addresses in the
ACL.
[no] access-list acl-num

[source-nat-pool pool-name]
Server Port
878 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
aFleX policy

aFleX policy to use for custom SLB processing.
[no] aflex aflex-name
Connection
limit

Server Port
Number of concurrent connections allowed on the
virtual service port.
[no] conn-limit number
Session
synchronization
(connection
mirroring)

Server Port
Backs up session information on the Standby AX
device in an HA configuration. When this option is
enabled, sessions remain up even following a
failover.
Supported
Values
Name of a configured aFleX policy.
Default: None
Configurable in
Virtual Port
Template?
No
0-8000000 (8 million)
0 means no limit.
Default: Not set
Yes, but the range

is 1-1048575
Enabled or disabled
No
Default: Disabled
[no] ha-conn-mirror
Server Port
Direct Server
Return (DSR)
Note: In HA deployments, HA session synchronization is required for persistent sessions (source-IP

persistence, and so on), and is therefore automatically enabled for these sessions by the AX device.
Persistent sessions are synchronized even if session
synchronization is disabled in the configuration.
Disables destination NAT, so that server responses
go directly to clients.
[no] no-dest-nat
Server Port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Enabled or disabled
No
Disabled: Destination NAT is

enabled.
879 of 950

Parameter
Policy-based
SLB (PBSLB)

Uses a black/white list to allow or deny clients who
request the service port, select service groups for
allowed clients, and drop or reset connections if the
connection limit is reached.
[no] pbslb bw-list name
[no] pbslb id id
{service service-group-name |
drop | reset}
[logging [minutes [fail]]]
[no] pbslb over-limit {drop |
reset}
Supported
Values
Name of a configured black/white
list. The list must
be imported onto
the AX device.
Configurable in
Virtual Port
Template?
No
Default: Not set
Note: In the GUI, PBSLB can only be configured

and applied using PBSLB policy templates.
Note: If the option to use default selection if preferred 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, disable 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.
Source NAT
(For information about PBSLB, see Policy-Based

SLB (PBSLB) on page 751.)
Name of a pool of IP addresses to use for Network
Address Translation (NAT).
[no] source-nat pool pool-name
Server Port
Name of a configured source NAT

pool.
No
Default: Not set
Note: This option is not applicable to the mms or

rtsp service types.
880 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
VIP Source
NAT

Enables IP NAT support for the VIP.
Source IP NAT can be configured on a virtual port
in the following ways:
Supported
Values
Enabled or disabled
Configurable in
Virtual Port
Template?
No
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
Server Port
Softwarebased
protection
against TCP
SYN flood
attacks
Use receive
hop for
responses
Note: The current release does not support source

IP NAT on FTP or RTSP virtual ports.
Protects against TCP SYN floods.
[no] syn-cookie [sack]
Server Port
Note: If hardware-based SYN cookies are supported on the AX model you are configuring, use
that version of the feature instead. (See SYN
Cookies on page 718.)
Sends replies to clients back through the last hop on
which the request for the virtual port's service was
received.
Enabled or disabled
No
Default: Disabled
Enabled or disabled
No
Default: Disabled
[no] use-rcv-hop-for-resp
Server Port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
881 of 950

Parameter
Reset after
server
selection
failure
Default
forwarding
after server
selection
failure
Default
selection if
preferred
server
selection fails

Sends a TCP reset (RST) to clients if server selection fails.
[no] reset-on-server-selectionfail
Server Port
Note: For more information about this option, see
Sending a Reset After Server Selection Failure on
page 895.
Contact A10 Networks for information.
Note: This option applies only to wildcard VIPs
(VIP address 0.0.0.0).
[no] use-default-if-no-server
Server Port
Continues checking for an available server in other
service groups if all of the servers are down in the
first service group selected by SLB.
During SLB selection of the preferred server to use
for a client request, SLB checks the following configuration areas, in the order listed:
1.
Supported
Values
Enabled or disabled
Configurable in
Virtual Port
Template?
No
Default: disabled
Enabled or disabled
No
Default: disabled
Enabled or disabled
No
Default: Enabled
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
(cont.)
882 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Parameter
Default
selection if
preferred
server
selection fails
(cont.)

3. Default service group. If none of the items
above results in selection of a server, the
default service group is used.
Supported
Values
Configurable in
Virtual Port
Template?
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 applicable to that configuration area. For example, if the
clients 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
GSLB enable
(DNS proxy
ports only)

Server Port
Enables a DNS port to function as a proxy for Global Server Load Balancing (GSLB) for this virtual
port.
Enabled or disabled
No
Default: Disabled
[no] gslb-enable
Server Port
Statistics
collection
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.
the virtual port.
Enabled or
disabled
stats-data-enable
Default: enabled
No
stats-data-disable
Server Port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
883 of 950

884 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
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 hostnames 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 created, the AX device refreshes its TTL. The AX device also creates service-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 hostname real server that has already been created, the AX device creates a second 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 servers 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 886)

The servers TTL is decremented by 60 every minute. The TTL is refreshed
each time the DNS server replies with the address.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
885 of 732

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 created 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, specifically 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 values 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
server configuration.
The maximum total length of a dynamic server name is 32 bytes. If the
name becomes longer than 32 characters, the AX device truncates the
name to 32 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.
886 of 732
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 created, 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 example, 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 2-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 decrement 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 priorities are not decremented.
Note:
b y
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 hostname. The limit is not applied collectively to all dynamically created servers for the hostname.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
887 of 732

Configuring Dynamic Real Server Creation

You can configure dynamic real servers using the GUI or CLI.
Note:
In the current release, configuration of template options for dynamic

server creation is not supported in the GUI.
USING THE GUI

3. Enter a name for the dynamic real server in the Name field.
4. In the IP Address/Host, enter the hostname known to DNS.
5. Configure additional options for the real server and add ports, as applicable 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.
888 of 732
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 TTL in the DNS
reply to calculate the minimum TTL value to assign to the dynamically created server. The min-ttl-ratio can be 2-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 decrement 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 member. The default priority value is 16 and the default delta is 0.
To display information about dynamically created real servers, use the following 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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
889 of 732

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:
Minimum TTL ratio:
Maximum dynamic server:
16
Health check:
none
Current connection:
Current request:
Total connection:
1919
890 of 732
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Total request:
1919
Total request success:
1877
Total forward bytes:
546650
Total forward packets:
5715
Total reverse bytes:
919730
Total reverse packets:
5631
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:
Minimum TTL ratio:
15
Maximum dynamic server:
1023
Health check:
none
Current connection:
Current request:
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
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
Fwd-p = Forward packets, Rev-p = Reverse packets
Service Group Name
Service
Current
Total
Fwd-p
Rev-p
----------------------------------------------------------------------*sg-test
State: All Up
DRS-10.4.2.6-s2.test.com:80
DRS-10.4.2.5-s1.test.com:80
36
1919
5714
5631
s-test2:80
53
265
212
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
891 of 732

The following command displays detailed statistics for the dynamically created service-group members:
AX#show slb service-group sg-test
Service group name: sg-test
State: All Up
Service selection fail drop:
Service selection fail reset:
Service: DRS-10.4.2.6-s2.test.com:80
UP
Forward packets:
Reverse packets:
Forward bytes:
Reverse bytes:
Current connections:
Persistent connections:
Current requests:
Total requests:
Total connections:
Total requests succ:
Forward bytes:
Response time: 0.00
msec
Service: DRS-10.4.2.5-s1.test.com:80
Forward packets:
5715
546650
UP
Reverse packets:
5631
Reverse bytes:
919730
10
Current requests:
10
Total requests:
Total connections:
1919
1919
Response time: 0.00
msec
1877
Service: s-test1:80
UP
Forward packets:
Forward bytes:
450
31500
Reverse packets:
Reverse bytes:
360
44820
Current requests:
Total requests:
Total connections:
90
1877
Response time: 0.00
0
msec
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
892 of 732
Priority: 1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
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 servers 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 /20.
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. Enter a name for the VIP range in the name field.
4. 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.)
5. Configure additional VIP options as required for your deployment.
6. When finished, click OK at the bottom of the VIP creation page. The
VIP appears in the VIP table.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
893 of 732
USING THE CLI

To configure a set of virtual servers based on subnet, use the following command at the global configuration level of the CLI:
[no] slb virtual-server server-name
{subnet-mask | /mask-length}
starting-ip
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.51.1.1.255:
AX(config)#slb virtual-server vs1 1.1.1.5 /24
894 of 732
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Sending a Reset After Server Selection Failure

The AX device provides an option or 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 following 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 188 on
page 896 shows an example of a Policy-Based SLB (PBSLB) solution that
uses the reset-on-server-selection-fail option.
Note:
b y
The TCP template reset-rev option also can be used to send a RST to clients. 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.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
895 of 732

FIGURE 188
896 of 732
PBSLB Used With reset-on-server-selection-fail Option
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 clients 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-serverselection-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 disabled. 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.
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 category, 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.
Note:
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
897 of 732

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 188 on
page 896.
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
898 of 732
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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

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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
899 of 732
900 of 732
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Scan-All-Members Option in Persistence

Templates
In cookie, source-IP, and destination-IP persistence templates, the matchtype server option has a suboption named scan-all-members. This chapter
describes the option in detail.
The match-type server option changes the granularity of persistence, from
server+port, to simply server. If the match-type is set to server+port (the
default), a persistent session is always sent to the same real port on the same
real server. However, if the match-type is set to server, a persistent session is
always sent to the same real server, but not necessarily to the same real port.
The match-type server option is useful in cases where the same service is
available on multiple service ports on the server. With this option, if the
server port that a client is using for a persistent session goes down, another
service port of the same service type on the same server can be used.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
901 of 950

FIGURE 189
Scan-all-members
VIP 192.168.10.11 uses 3 real servers for HTTP service. Two of the servers
have a single protocol port for HTTP. However, one of the servers has
HTTP service on multiple service ports.
The load-balancing method for the service group is used to select a server
and port for the first request from a given client (source IP address). After
this initial selection, subsequent requests from the same client are sent to the
same server.
By default, when the match-type is changed to server, the AX device uses
the SLB load-balancing method for the first request to select a member, then
uses fast-path processing to select the first member that has the same IP
address as the server that was initially selected.
In this example, if the load-balancing method chooses port 80 on server s3
for the first request, subsequent requests are also sent to s3. If port 80 goes
down, the next request is still sent to s3, but to a different port on s3.
902 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

However, if the member (port 80 on s3) is set to a lower priority or is
administratively disabled, the AX device will use the load-balancing
method to select a server and port for the next request. Any of the enabled
members can be selected.
In this case, it is possible that a different server will be selected for the next
request. For example, if an admin needs to perform some maintenance on
port 80, and disables the port in order to prevent it from being used for further requests, persistent sessions on the port and server may not remain persistent to the same server.
To ensure that sessions do remain persistent on the same server if a member
is administratively disabled or is set to a lower priority, use the scan-allmembers option. In this case, the AX device selects the first member that
has the same IP address as the member that has been taken out of service.
CLI Example
The commands in this section configure the source-IP persistence template
and the service group in Figure 189 on page 902.
The following commands configure the source-IP persistence template:
AX(config)#slb template persist source-ip persist-source
AX(config-source ip persistence template)#match-type server scan-all-members
AX(config-source ip persistence template)#exit

AX(config)#slb service-group sg-1
AX(config-slb service group)#template persist source-ip persist-source
If s3:80 is disabled or is set to a lower priority, the AX device selects the

next member on the same server, s3:8080.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
903 of 950
904 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
SSL Certificate Management

This chapter describes how to install SSL keys, certificates, and Certificate
Revocation Lists (CRLs) on the AX device. Installing these SSL resources
on the AX device enables the AX device to provide SSL services on behalf
of real servers.
You can use the AX device to offload SSL processing from servers or, for
some types of traffic, you can use the AX device as an SSL proxy. (For
more information about SSL offload and SSL proxy, see SSL Offload and
SSL Proxy on page 219.)
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 Transport 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 clients data, then send an
encrypted reply to the client. The client will decrypt the server reply, and so
on.
Note:
SSL is an older version of TLS. The AX device supports SSL version 3.0
and TLS version 1.0. The AX device also supports RFC 3268: AES
Ciphersuites for TLS. For simplicity, elsewhere this document and other
AX user documents use the term SSL to mean both SSL and TLS.
Note:
The AX device supports Privacy Enhanced Mail (PEM) format for certificate files and CRLs. AX SSL processing supports PEM format and RSA
encryption.
SSL Process
SSL works using certificates and keys. Typically, a client will begin a secure
session by sending an HTTPS request to a VIP. The request begins an SSL
handshake. The AX device will respond with a digital certificate, to provide
verification of the content servers identity. From the clients 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
905 of 950

Overview
Figure 190 shows a simplified example of an SSL handshake. In this example, the AX device is acting as an SSL proxy for backend servers.
FIGURE 190
Typical SSL Handshake (simplified)
To begin, the client sends an HTTPS request. The request includes some
encryption details such as the cipher suites supported by the client.
The 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 client.
The client browser checks its certificate store (sometimes called the certificate list) for a copy of the server certificate. If the client does not have a
906 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
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 CAs certificate. If the CA that signed the server certificate
is not a root CA, the client browser should have another certificate or a certificate chain that includes the CA that signed the CAs 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 191 shows an example of a certificate
chain containing three certificates:
FIGURE 191
SSL Certificate Chain Example
-----BEGIN CERTIFICATE----ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw
Oi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQAD
gYEAheIVEe8vArUOZxKkUIGjaYymzJAh8Ty0uUPrikLpQ0IGezByVdbDUJ+HQLGp
2eruTPZpBNADaEfymstIPIxrsuCRhyr3Ymsa2rgzwy9kSXeG83H7E7HxRnpxDNZ8
l+uzpU/rk4j3bO/JVxPZMnwzMWriPSYgL1EKYcOSKyReaxQ=
-----END CERTIFICATE---------BEGIN CERTIFICATE----ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw
-----END CERTIFICATE---------BEGIN CERTIFICATE----ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw
-----END CERTIFICATE-----
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
907 of 950

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 CAs certificate. 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.
On the AX device, a client-SSL template can have one certificate chain file.
The certificate chain must begin at the top with the root CAs certificate, followed in order by the intermediary certificates. If the certificate authority
that signs the server certificate does not provide the certificate chain in a
single file, you can use a text editor to chain the certificates together in a
single file as shown in Figure 191.
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 clients browser may display a certificate warning. Figure 192
shows an example of a certificate warning displayed by Internet Explorer.
FIGURE 192
Note:
908 of 950
Example of Certificate Warning
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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
CA-Signed and Self-Signed Certificates

Typically, clients have a certificate store that includes certificates signed by
the various root CAs. The certificate store may also have some non-CA certificates 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 CAsigned 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 certificate 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 identity 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 907.)
The example in Figure 190 on page 906 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 certificate.

CA-signed certificates are considered to be more secure than self-signed
certificates. Likewise, clients are more likely to be able to validate a CAsigned certificate than a self-signed certificate. If you configure the AX
device to present a self-signed certificate to clients, the clients 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
909 of 950

Overview
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 190 on page 906, only the
first option (Certificate) needs to be configured. You may also need to configure the Certificate chain option.
Certificate Specifies a server certificate that the AX device will send
to a client, so that the client can validate the servers identity. The certificate can be generated on the AX device (self-signed) or can be signed
by another entity and imported onto the AX device.
Key Specifies a public key for a server certificate. If the CSR used to
request the server certificate is generated on the AX device, the key is

automatically generated. Otherwise, the key must be imported.
Certificate chain Specifies a named set of server certificates beginning
with a root CA certificate, and containing all the intermediary certificates in the authority chain that ends with the authority that signed the
server certificate. (See Certificate Chain on page 907.)
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 identities of clients.
910 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
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 handshake does not proceed (it fails) if the client sends a NULL certificate or the certificate is invalid.
Cipher list Specifies the cipher suites supported by the AX device.
When the client sends its connection request, it also sends a list of the
cipher suites it can support. The AX device selects the strongest cipher
suite supported by the client that is also enabled in the template, and
uses that cipher suite for traffic with the client. By default, all the following are enabled:
SSL3_RSA_RC4_40_MD5
TLS1_RSA_EXPORT1024_RC4_56_MD5
TLS1_RSA_EXPORT1024_RC4_56_SHA
Session cache size Specifies the maximum number of cached sessions for
SSL session ID reuse.
Server-SSL Template Options

A server-SSL template is needed only if traffic between the AX device and
real servers will be encrypted using SSL. In this case, the AX device will be
required to validate the identities of the servers.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
911 of 950

Overview
CA certificate Specifies a CA certificate that the AX device can use to
validate the identity of a server.

Cipher list Specifies the cipher suites supported by the AX device.
When the server sends its connection request, it also sends a list of the
cipher suites it can support. The AX device selects the strongest cipher
suite supported by the server that is also enabled in the template and
uses that cipher suite for traffic with the server. The same cipher suites
supported in client-SSL templates are supported in server-SSL templates. Support for all of them is enabled by default.
Certificate Installation Process

To configure an AX device to perform SSL processing on behalf of real
servers, you must install a certificate on the AX device. This certificate is
the one that the AX device will present to clients during the SSL handshake.
You also must configure a client-SSL template, add the key and certificate
to the template, and bind the template to the VIP that will be requested by
clients.
You can install a CA-signed certificate or a self-signed certificate (described
in CA-Signed and Self-Signed Certificates on page 909).
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 Certificate on page 915 and Importing a Certificate and Key on page 918.
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 information 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.
912 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Overview
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-andpaste 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 CAs 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 format, 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
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 927.
5. If applicable, import the certificate chain onto the AX device. The certificate chain must be a single text file, beginning with a root CAs certificate at the top, followed in order by each intermediate signing
authoritys certificate. (See Certificate Chain on page 907.)
Figure 193 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
913 of 950

Overview
FIGURE 193
Note:
Obtaining and Installing Signed Certificate from CA
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 certificate to sign another certificate. However, in this case, a clients
browser is still likely to display a certificate warning to the end user.
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 920.
914 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Generating a Key and CSR for a CA-Signed Certificate

USING THE GUI
1. Select Config > Service > SSL Management, if not already selected.
2. On the menu bar, select Certificate.
3. Click Create.
4. Enter a name for the certificate.
5. In the Issuer drop-down list, select Certificate Authority, if not already
selected.
This option displays the Pass Phrase and Confirm Pass Phrase fields.
6. Enter the rest of the certificate information in the remaining fields of the
Certificate section.
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 certificate for domain example.com and it sub-domains, enter the following
common name: *.example.com
Note:
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 certificate signing request (CSR), and displays the CSR. The CSR is displayed
in the Request Text field.
10. To save the CSR to your PC:
a. Click Download.
Note:
If the browser security settings normally block downloads, you may need
to override the setting. For example, in Internet Explorer, hold the Ctrl
key while clicking Download.
b. Click Save.
c. Navigate to the save location.
d. Click Save again.
Note:
b y
If you prefer to copy-and-paste the CSR, make sure to include everything,

including -----BEGIN CERTIFICATE REQUEST----- and -----END
CERTIFICATE REQUEST-----.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
915 of 950

11. When you receive the certificate from the CA, import it onto the AX
device. (See Importing a Certificate and Key on page 918.)
USING THE CLI

To generate a key and a CSR, use the following command at the global configuration level of the CLI:
slb ssl-create csr csr-name url
The csr-name can be 1-31 characters. The url specifies the file transfer protocol, 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:
tftp://host/file
http://[user@]host/file
https://[user@]host/file
This command displays a series of prompts, for the following information:

IP address of the server to which to export the CSR
Username for write access to the server
Password for write access to the server
Path and filename
Key length, which can be 512, 1024, or 2048 bits
Common name, 1-64 characters
Division, 0-31 characters
Organization, 0-63 characters
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
916 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 certificate for domain example.com and it sub-domains, enter the following
common name: *.example.com
Note:
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 generated along with the CSR.
The following commands generate and export a CSR, then import the
signed certificate.
AX(config)#slb ssl-create csr slbcsr1 ftp:
Password []?********
File name [/]?slbcsr1
input key bits(512,1024,2048) default 1024:<Enter>
input Common Name, 1~64:slbcsr1
input Division, 0~31:div1
input Organization, 0~63:org2
input Locality, 0~31:westcoast
input State or Province, 0~31:ca
input Country, 2 characters:us
input email address, 0~64:axadmin@example.com
input Pass Phrase, 0~31:csrpword
Confirm Pass Phrase:csrpword
AX(config)#import ca-signedcert1 ftp:
Password []?********
File name [/]?ca-signedcert1
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
917 of 950

Importing a Certificate and Key

To import certificate and key files, place them on the PC that is running the
GUI or CLI session, or onto a PC or file server that can be locally reached
over the network.
Note:
If you are importing a CA-signed certificate for which you used the AX
device to generate the CSR, you do not need to import the key. The key is
automatically generated on the AX device when you generate the CSR.
USING THE GUI

3. To import 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 dropdown 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. Otherwise, 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.
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 protocol is used.
In the User and Password fields, enter the username and password
918 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

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 | 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:
tftp://host/file
http://[user@]host/file
https://[user@]host/file
Alternatively, you can use the following commands at the Privileged EXEC
or global Config level of the CLI:
import ssl-cert file-name url
import ssl-key file-name url
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
919 of 950

Generating a Self-Signed Certificate

USING THE GUI
3. Click Create.
4. Enter a name for the certificate.
5. In the Issuer drop-down list, select Self, if not already selected.
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 certificate 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 512, 1024, or 2048 bits
Common name, 1-64 characters
Division, 0-31 characters
Organization, 0-63 characters
Locality, 0-31 characters
State or Province, 0-31 characters
920 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Country, 2 characters
Email address, 0-64 characters
Number of days the certificate is valid, 30-3650 days
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
Note:
The key length, common name, and number of days the certificate is valid
are required. The other information is optional. The default key length is
1024 bits. The default number of days the certificate is valid is 730.
The following commands create a self-signed certificate named slbcert1
and verify the configuration:
AX(config)#slb ssl-create certificate slbcert1
input key bits(512,1024,2048) default 1024:<Enter>
input Common Name, 1~64:slbcert1
input Division, 0~31:Div1
input Organization, 0~63:Org2
input Locality, 0~31:WestCoast
input State or Province, 0~31:CA
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
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
921 of 950

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

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:
tftp://host/file
922 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Exporting Certificates, Keys, and CRLs

Exporting a Certificate and Key
USING THE GUI
3. To export a certificate:
a. Select the certificate. (Click the checkbox next to the certificate
name.)
b. Click Export.
to override the setting. For example, in Internet Explorer, hold the Ctrl
key while clicking Export.
Note:
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 Privileged EXEC or global Config level of the CLI:
export ssl-cert file-name url
export ssl-key file-name url
path, and filename.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
923 of 950

entire URL:
tftp://host/file
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

2. On the menu bar, select Cert Revocation List.
3. Select the CRL. (Click the checkbox next to the CRL name.)
4. Click Export.
Note:
to override the setting. For example, in IE, hold the Ctrl key while clicking Export.
5. Click Save.
6. Navigate to the save location.
7. Click Save again.
Note:
924 of 950
The CLI does not support export of CRLs.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Creating a Client-SSL or Server-SSL Template and Binding it to a VIP
Creating a Client-SSL or Server-SSL Template and

Binding it to a VIP
After creating or importing certificates and keys on the AX device, you
must add them to an SSL template, then bind the template to a VIP, in order
for them to take effect.
Creating an SSL Template

USING THE GUI
2. On the menu bar, select one of the following:
SSL > Client SSL to create a template for SSL traffic between the
AX device (VIP) and clients.

SSL > Server SSL to create a template for SSL traffic between the
AX device and servers.
3. Click Add.
4. Enter or select the configuration options. (For information, see SSL
Templates on page 910, 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 configure template parameters. (For information, see SSL Templates on
page 910 or the AX Series CLI Reference.)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
925 of 950

Converting Certificates and CRLs to PEM Format
Binding an SSL Template to a VIP

USING THE GUI
3. Click on the virtual server name or click Add to create a new one.
4. Enter the VIP name and IP address, if creating a new VIP.
5. In the Port section, select a port and click Edit, or click Add to add a new
port. The Virtual Server Port page appears.
6. Select the template from the Client-SSL Template or Server-SSL Template drop-down list.
7. Click OK.
8. Click OK again.
USING THE CLI

Use one of the following commands at the configuration level for the virtual
port on the VIP:
[no] template client-ssl template-name
[no] template server-ssl template-name
Use the same command on each port for which SSL will be used.

The AX device supports Privacy Enhanced Mail (PEM) format for certificate files and CRLs.
If a certificate or CRL you plan to import onto the AX device is not in PEM
format, it must be converted to PEM format first, before you import it onto
the AX device.
Note:
926 of 950
Beginning in AX Release 2.4.1, you do not need to convert the certificate

into PEM format before importing it. You can specify the format when
you import the certificate. The AX device automatically converts the
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

imported certificate into PEM format. (See Importing a Certificate and
Key on page 918.)
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. Perform step 1 through step 4 on the Windows PC. Perform step 5 through
step 8 on the Unix/Linux workstation.
Steps to perform on the Windows PC:
1. Start the Microsoft Management Console (mmc.exe).
2. Add the Certificates snap-in:
a. Select File Add/Remove Snap-In. The Add/Remove Snap-In dialog
appears.
b. Click Add. A list of available snap-ins appears.
c. Select Certificates.
d. Click Add.
A dialog appears with the following choices: My user account, Service account, and Computer account.
e. Select Computer Account and click Next. The Select Computer dialog 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.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
927 of 950

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 concatenation of the private key and the certificate.
7. Use the vi editor to divide the PKCS12 file into two files, one for the
certificate (.crt) and the other for the private key.
8. To remove the passphrase from the key, use the following command:
$ openssl rsa -in encrypted.key -out unencrypted.key
Note:
Although removing the passphrase is optional, A10 Networks recommends 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 filename.pem
928 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Route Tables
Using the Management Interface as the Source for

Management Traffic
By default, the AX device attempts to use a route from the main route table
for management connections originated on the AX device. You can enable
the AX device to use the management route table to initiate management
connections instead.
This chapter describes the AX devices two route tables, for data and management traffic, and how to configure the device to use the management
route table.
Route Tables
The AX device uses separate route tables for management traffic and data
traffic.
Management route table Contains all static routes whose next hops are
connected to the management interface. The management route table

also contains the route to the device configured as the management
default gateway.
Main route table Contains all routes whose next hop is connected to a
data interface. These routes are sometimes referred to as data plane

routes. Entries in this table are used for load balancing and for Layer 3
forwarding on data ports.
This route table also contains copies of all static routes in the management route table, excluding the management default gateway route.
You can configure the AX device to use the management interface as the
source interface for automated management traffic. In addition, on a caseby-case basis, you can enable use of the management interface and management route table for various types of management connections to remote
devices:
The AX device automatically will use the management route table for reply
traffic on connections initiated by a remote host that reaches the AX device
on the management port. For example, this occurs for SSH or HTTP connections from remote hosts to the AX device.
Note:
b y
In AX Release 1.2.4 and earlier, all static routes are stored in the main
route table, even if the next hop is connected to the management interface.
The management route table contains only the route to the subnet directly
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
929 of 950

Management Routing Options
connected to the management interface, and the IP default gateway configured on the management interface. When you upgrade to an AX release
later than 1.2.4, static routes whose next hop is the management interface
are duplicated in the management route table.
Keep the Management and Data Interfaces in Separate Networks
It is recommended to keep the management interface and the data interfaces
in separate networks. If both tables have routes to the same destination subnet, some operations such as pinging may have unexpected results. An
exception is the default route (0.0.0.0/0), which can be in both tables.
To display the routes in each table, use the following commands:
show ip route mgmt This command displays the routes in the man-
agement route table.

show ip route or show ip fib These commands display data plane
routes.

You can configure the AX device to use the management interface as the
source interface for the following management protocols, used for automated management traffic:
SYSLOG
SNMPD
NTP
RADIUS
TACACS+
SMTP
For example, when use of the management interface as the source interface
for control traffic is enabled, all log messages sent to remote log servers are
sent through the management interface. Likewise, the management route
table is used to find a route to the log server. The AX device does not
attempt to use any routes from the main route table to reach the server, even
if a route in the main route table could be used.
In addition, on a case-by-case basis, you can enable use of the management
interface and management route table for the following types of management connections to remote devices:
930 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

Upgrade of the AX software
SSH or Telnet connection to a remote host
Import or export of files
Export of show techsupport output
Reload of black/white lists
SSL loads (keys, certificates, and Certificate Revocation Lists)
Copy or restore of configurations
Backups
Caution:
If you enable this feature, then downgrade to AX Release 1.2.4 or earlier, it is possible to lose access to the AX device after you downgrade.
This can occur if you configure an external AAA server (TACACS+
server) to authorize CLI commands entered on the AX device, and
the TACACS+ server is connected to the AX device through the management default gateway.
If this is the case, before you downgrade, remove the TACACS+ configuration from the AX device. After you downgrade, you can re-add
the configuration, but make sure the TACACS+ server can be
reached using a route other than through the management default
gateway.
Enabling Use of the Management Interface as the Source for

Automated Management Traffic
By default, use of the management interface as the source interface for automated management traffic is disabled.
To enable it, use the following command at the configuration level for the
management interface:
[no] ip control-apps-use-mgmt-port
Here is an example:
AX(config-if:management)#ip control-apps-use-mgmt-port
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
931 of 950

Using the Management Interface as the Source Interface for

Manually Generated Management Traffic
To use the management interface as the source interface for manually generated management traffic, use the use-mgmt-port option.
In the GUI, this option is provided as a Use Management Port checkbox on
the applicable pages.
In the CLI, this option is supported with the following commands.
Commands at the User EXEC Level

ssh [use-mgmt-port] {host-name | ipaddr)
login-name [protocol-port]
telnet [use-mgmt-port] {host-name | ipaddr)
[protocol-port]
Commands at the Privileged EXEC Level

export {aflex | ssl-cert | ssl-key | axdebug}
file-name [use-mgmt-port] url
ssh [use-mgmt-port] {host-name | ipaddr)
login-name [protocol-port]
telnet [use-mgmt-port] {host-name | ipaddr)
[protocol-port]
Commands at the Global Configuration Level

backup {config | log} [use-mgmt-port] url
[no] bw-list name [use-mgmt-port] url
[period seconds] [load]
copy {running-config | startup-config |
from-profile-name}
[use-mgmt-port]
{url | to-profile-name [cf]}
health external
{delete program-name |
import [use-mgmt-port] [description] url |
export [use-mgmt-port] program-name url}
[no] restore [use-mgmt-port] url
932 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

[no] slb ssl-load
{certificate file-name | private-key file-name}
[use-mgmt-port] url
upgrade {cf | hd} {pri | sec} [use-mgmt-port] url
Show Commands
show techsupport [[use-mgmt-port] export url]
[page]
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010
933 of 950

934 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.2 6/21/2010

Backing Up System Information
Configuration Management
By default, when you click the Save button in the GUI or enter the write
memory command in the CLI, all unsaved configuration changes are saved
to the startup-config. The next time the AX device is rebooted, the configuration is reloaded from this file.
In addition to these simple configuration management options, the AX
device has advanced configuration management options that allow you to
save multiple configuration files. You can save configuration files remotely
on a server and locally on the AX device itself.
Note:
For information about managing configurations for separate partitions on

an AX device configured for Role-Based Administration (RBA), see
Role-Based Administration on page 797.
Note:
For information about synchronizing configuration information between

AX devices in a High Availability (HA) pair, see Synchronizing Configuration Information on page 598.
Note:
For upgrade instructions, see the release notes for the AX release to which
you plan to upgrade.

The AX device allows you to back up the system, individual configuration
files, and even log entries onto remote servers. You can use any of the following file transfer protocols:
Trivial File Transfer Protocol (TFTP)
File Transfer Protocol (FTP)
Secure Copy Protocol (SCP)
Unix Remote Copy (RCP)
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
935 of 950

USING THE GUI

1. Select Config > System > Maintenance.
2. Select one of the following from the menu bar:
Backup > System This option backs up the configuration file(s),
aFleX policies, and SSL certificates and keys.

Backup > Config This option backs up only the specified configuration file.
Backup > Syslog This option backs up the log entries in the AX
devices syslog buffer. (If there are any core files on the system, this
option backs them up as well.)
3. Select the backup location:
Local Saves the backup on the PC or workstation where you are
using the AX GUI.

Remote Saves the backup onto another PC or workstation.
4. If you selected Local:
a. Click OK.
b. Click Save and navigate to the save location. Optionally, you can
edit the filename.
c. Click Save.
5. If you selected Remote:
a. In the Protocol drop-down list, select the file transfer protocol: FTP,
TFTP, RCP, or SCP.
b. If using FTP and the remote device does not use the default FTP
port, change the port.
c. In the Host field, enter the hostname or IP address of the remote
device.
d. In the Location field, enter the pathname. To change the system
backup file from the default name (backup_system.tar), specify
the new name at the end of the path.
e. In the User and Password fields, enter the username and password
required for write access to the remote device.
f. Click OK.
936 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

Saving Multiple Configuration Files Locally
USING THE CLI

At the Privileged EXCE level of the CLI, use the following command:
backup {config | log} url
The config option backs up the startup-config file, aFleX scripts, and SSL
certificates and keys.
The log option backs up the log entries in the AX devices syslog buffer.
The url option specifies the file transfer protocol, username, and directory
path. You can enter the entire URL on the command line or press Enter to
display a prompt for each part of the URL. If you enter the entire URL and a
password is required, you will still be prompted for the password. To enter
the entire URL:
tftp://host/file

The AX device has CLI commands that enable you to store and manage
multiple configurations on the AX device.
Note:
Unless you plan to locally store multiple configurations, you do not need
to use any of the advanced commands or options described in this section.
Just click Save in the GUI or enter the write memory command in the
CLI to save configuration changes. These simple options replace the commands in the startup-config stored in the image area the AX device booted
from with the commands in the running-config.
Note:
Management of multiple locally stored configuration files is not supported in the GUI.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
937 of 950

Configuration Profiles
Configuration files are managed as configuration profiles. A configuration
profile is simply a configuration file. You can locally save multiple configuration profiles on the AX device. The configuration management commands
described in this section enable you to do the following:
Save the startup-config or running-config to a configuration profile.
Copy locally saved configuration profiles.
Delete locally saved configuration profiles.
Compare two configuration profiles side by side to see the differences
between the configurations.

Link the command option startup-config to a configuration profile
other than the one stored in the image area used for the most recent
reboot. (This is the profile that startup-config refers to by default.)
This option makes it easier to test a configuration without altering the
configuration stored in the image area.
Note:
Although the enable and admin passwords are loaded as part of the system configuration, they are not saved in the configuration profiles.
Changes to the enable password or to the admin username or password
take effect globally, regardless of the values that were in effect when a
given configuration profile was saved.
Commands for Local Configuration Management

To manage multiple locally stored configurations, use the following commands. All commands are available at the global configuration level of the
CLI.
write memory
[primary | secondary | profile-name] [cf] |
terminal
This command replaces the configuration commands in the specified configuration profile with the commands in the running-config.
If you enter write memory without additional options, the command
replaces the configuration profile that is currently linked to by startup-config with the commands in the running-config. If startup-config is set to its
default (linked to the configuration profile stored in the image area that was
used for the last reboot), then write memory replaces the configuration profile in the image area with the running-config.
938 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

If you enter write memory primary, the command replaces the configuration profile stored in the primary image area with the running-config. Likewise, if you enter write memory secondary, the command replaces the
configuration profile stored in the secondary image area with the runningconfig.
If you enter write memory profile-name, where profile-name is the name of
a configuration profile, the AX device replaces the commands in the specified profile with the running-config.
The cf option replaces the configuration profile in the specified image area
(primary or secondary) on the compact flash rather than the hard disk. If you
omit this option, the configuration profile in the specified area on the hard
disk is replaced.
The terminal option displays the running-config on the management terminal.
show startup-config [all | profile-name] [cf]
When entered without the all or profile-name option, this command displays the contents of the configuration profile that is currently linked to
"startup-config". To display the contents of a different configuration profile,
use the profile-name option. To display a list of the locally stored configuration profiles, use the all option.
The cf option displays the configuration profile in the specified image area
(primary or secondary) on the compact flash rather than the hard disk. If you
omit this option, the configuration profile in the specified area on the hard
disk is displayed. If the all option is also used, the cf option displays all the
configuration profiles stored on the compact flash.
copy {running-config | startup-config |
from-profile-name}
{url | to-profile-name [cf]}
The copy startup-config to-profile-name command copies the configuration profile that is currently linked to startup-config and saves the copy
under the specified profile name.
The copy running-config to-profile-name command copies the runningconfig and saves the copy under the specified profile name.
The cf option copies the profile to the compact flash instead of the hard
disk.
Note:
b y
Copying a profile from the compact flash to the hard disk is not supported.
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
939 of 950

(The url option backs up the configuration to a remote device. See Backing
Up System Information on page 935.)
diff {startup-config | profile-name}
{running-config | profile-name}
Displays a side-by-side comparison of the commands in a pair of configurations.
The diff startup-config running-config command compares the configuration profile that is currently linked to "startup-config" with the running-config. Similarly, the diff startup-config profile-name command compares the
configuration profile that is currently linked to "startup-config" with the
specified configuration profile.
To compare a configuration profile other than the startup-config to the running-config, enter the configuration profile name instead of startup-config.
To compare any two configuration profiles, enter their profile names instead
of startup-config or running-config.
In the CLI output, the commands in the first profile name you specify are
listed on the left side of the terminal screen. The commands in the other profile that differ from the commands in the first profile are listed on the right
side of the screen, across from the commands they differ from. The following flags indicate how the two profiles differ:
This command has different settings in the two profiles.
This command is in the second profile but not in the first one.
This command is in the first profile but not in the second one.
link startup-config {default | profile-name}

[primary | secondary] [cf]
This command links the "startup-config" token to the specified configuration profile. By default, "startup-config" is linked to "default", which means
the configuration profile stored in the image area from which the AX device
most recently rebooted.
This command enables you to easily test new configurations without replacing the configuration stored in the image area.
The primary | secondary option specifies the image area. If you omit this
option, the image area last used to boot is selected.
940 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

The cf option links the profile to the specified image area in compact flash
instead of the hard disk.
The profile you link to must be stored on the boot device you select. For
example, if you use the default boot device selection (hard disk), the profile
you link to must be stored on the hard disk. If you specify cf, the profile
must be stored on the compact flash. (To display the profiles stored on the
boot devices, use the show startup-config all and show startup-config all
cf commands.)
After you link "startup-config" to a different configuration profile, configuration management commands that affect "startup-config" affect the linked
profile instead of affecting the configuration stored in the image area. For
example, if you enter the write memory command without specifying a
profile name, the command saves the running-config to the linked profile
instead of saving it to the configuration stored in the image area.
Likewise, the next time the AX device is rebooted, the linked configuration
profile is loaded instead of the configuration that is in the image area.
To relink startup-config to the configuration profile stored in the image
area, use the default option (link startup-config default).
delete startup-config profile-name [cf]
This command deletes the specified configuration profile. The cf option
deletes the profile from compact flash instead of the hard disk.
Note:
Although the command uses the startup-config option, the command

only deletes the configuration profile linked to startup-config if you
enter that profiles name. The command deletes only the profile you specify.
Note:
If the configuration profile you specify is linked to startup-config,

startup-config is automatically relinked to the default. (The default is
the configuration profile stored in the image area from which the AX
device most recently rebooted).
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
941 of 950

CLI EXAMPLES
The following command saves the running-config to a configuration profile
named slbconfig2:
AX(config)#write memory slbconfig2
The following command shows a list of the configuration profiles locally

saved on the AX device. The first line of output lists the configuration profile that is currently linked to startup-config. If the profile name is
default, then startup-config is linked to the configuration profile stored
in the image area from which the AX device most recently rebooted.
AX(config)#show startup-config all
Current Startup-config Profile: slb-v6
Profile-Name
Size
Time
-----------------------------------------------------------1210test
1957
Jan 28
18:39
ipnat
1221
Jan 25
10:43
ipnat-l3
1305
Jan 24
18:22
ipnat-phy
1072
Jan 25
19:39
ipv6
2722
Jan 22
15:05
local-bwlist-123
3277
Jan 23
14:41
mgmt
1318
Jan 28
10:51
slb
1354
Jan 23
18:12
slb-v4
12944
Jan 23
19:32
slb-v6
13414
Jan 23
19:19
The following command copies the configuration profile currently linked to

startup-config to a profile named slbconfig3:
AX(config)#copy startup-config slbconfig3
The following command compares the configuration profile currently

linked to startup-config with configuration profile testcfg1. This example is abbreviated for clarity. The differences between the profiles are
shown in this example in bold type.
942 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX(config)#diff startup-config testcfg1
!Current configuration: 13378 bytes
!Configuration last updated at 19:18:57 PST Wed Jan 23 2008
!Configuration last saved at 19:19:37 PST Wed Jan 23 2008
!version 1.2.1
hostname AX
clock timezone America/Tijuana
ntp server 10.1.11.100 1440
...
!
interface ve 30
ip address 30.30.31.1 255.255.255.0

10.10.20.1 255.255.255.0
ip address
ipv6 address 2001:144:121:3::5/64

fc00:300::5/64
ipv6 address
(
> ip nat range-
list v6-1 fc00:300::300/64 2001:144:121:1::900/6

!
ipv6 nat pool p1 2001:144:121:3::996 2001:144:121:3::999 netm <

!
<
slb server ss100 2001:144:121:1::100
<
port 22
tcp
<
--MORE--
The following command links configuration profile slbconfig3 with

startup-config:
AX(config)#link startup-config slbconfig3
The following command deletes configuration profile slbconfig2:

AX(config)#delete startup-config slbconfig2
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
943 of 950

944 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
VLAN-to-VLAN Bridging
VLAN-to-VLAN bridging allows an AX device to selectively bridge traffic
among multiple VLANs. The AX device selectively forwards packets from
one VLAN to another based on the VLAN-to-VLAN bridging configuration
on the AX device. This feature allows the traffic flow between VLANs to be
tightly controlled through the AX device without the need to reconfigure the
hosts in the separate VLANs.
VLAN-to-VLAN bridging is useful in cases where reconfiguring the hosts
on the network either into the same VLAN, or into different IP subnets, is
not desired or is impractical.
You can configure a bridge VLAN group to forward one of the following
types of traffic:
IP traffic only (the default) This option includes typical traffic
between end hosts, such as ARP requests and responses.

This option does not forward multicast packets.
All traffic This option forwards all types of traffic.
Configuration Notes
VLAN-to-VLAN bridging is supported on AX devices deployed in transparent mode (Layer 2) or in gateway mode (Layer 3).
Each VLAN to be bridged must be configured on the AX device. The normal rules for tagging apply:
If an interface belongs to only one VLAN, the interface can be
untagged.
If the interface belongs to more than one VLAN, the interface must be
tagged.
Each VLAN can belong to only a single bridge VLAN group.
Each bridge VLAN group can have a maximum of 8 member VLANs. Traffic from any VLAN in the group is bridged to all other VLANs in the group.
Up to 64 bridge VLAN groups are supported.
If the AX device is deployed in gateway mode, a Virtual Ethernet (VE)
interface is required in the bridge VLAN group.
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
945 of 950
Configuring VLAN-to-VLAN Bridging

To configure VLAN-to-VLAN bridging:
1. Configure each of the VLANs to be bridged. In each VLAN, add the
AX devices interfaces to the VLAN.
2. Configure a bridge VLAN group. Add the VLANs to the group.
If the AX device is deployed in gateway mode, add a Virtual Ethernet
(VE) interface to the group.
Optionally, you can assign a name to the group. You also can change the
types of traffic to be bridged between VLANs in the group.
3. If the AX device is deployed in gateway mode, configure an IP address
on the VE to place the AX device in the same subnet as the bridged
VLANs.
USING THE CLI

To configure a bridge VLAN group, use the following commands.
[no] bridge-vlan-group group-num
Use this command at the global configuration level of the CLI to create the
bridge VLAN group and enter the configuration mode for it, where the following commands are available. The group-num can be 1-64.
[no] name string
This command configures a name for the group. The string can be 1-63
characters long. If the string contains blank spaces, use double quotation
marks around the entire string.
[no] vlan vlan-id
[vlan vlan-id ... | to vlan vlan-id]
This command adds the VLANs to the group.
[no] router-interface ve num
On an AX device deployed in gateway mode, this command adds the VE to
the group.
forward-all-traffic
This command configures the AX device to forward all types of traffic
between the VLANs in the group. By default, only IP traffic is forwarded. If
you change the traffic type but later want to change it back to the default,
you can use the following command: forward-ip-traffic
946 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
Group Information and Statistics

To display information for a bridge VLAN group, use the following command:
show bridge-vlan-group [group-id]
CLI Example Transparent Mode
The commands in this section configure an AX device deployed in transparent mode to forward IP traffic between VLANs 2 and 3.
The following commands configure the VLANs:
AX(config)#vlan 2
AX(config-vlan:2)#tagged ethernet 2
AX(config)#vlan 3
The following commands configure the bridge VLAN group:

AX(config)#bridge-vlan-group 1
AX(config-bridge-vlan-group:1)#vlan 2 to 3
AX(config-bridge-vlan-group:1)#exit
CLI Example Gateway Mode

The commands in this section configure an AX device deployed in gateway
mode to forward IP traffic between VLANs 2 and 3 on IP subnet
192.168.1.x.
The following commands configure the VLANs:
AX(config)#vlan 2
AX(config)#vlan 3
The following commands configure the bridge VLAN group, which

includes a VE:
AX(config)#bridge-vlan-group 1
AX(config-bridge-vlan-group:1)#vlan 2 to 3
AX(config-bridge-vlan-group:1)#router-interface ve 1
AX(config-bridge-vlan-group:1)#exit
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
947 of 950

The following commands assign an IP address to the VE:
AX(config-if:ve1)#ip address 192.168.1.100 /24
948 of 950
b y
D e s i g n
Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010
950
b y
D e s i g n
b y
Corporate Headquarters
A10 Networks, Inc.
2309 Bering Dr.
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
950
D e s i g n

AX Series™ Advanced Traffic Manager Configuration Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

AX Series™ Advanced Traffic Manager Configuration Guide

Hochgeladen von

Copyright:

Verfügbare Formate

P e r f o r m a n c e

AX Series Advanced Traffic Manager

A10 Networks, Inc. 6/21/2010 - All Rights Reserved

Information in this document is subject to change without notice.

EX Series Secure WAN Manager Configuration Guide

EX Series Secure WAN Manager Configuration Guide

Document No.: D-030-01-00-0006 - Ver. 2.4.3

AX Series - Configuration Guide

Obtaining Technical Assistance

Collecting System Information

USING THE GUI (RECOMMENDED)

Log into the GUI.

AX Series - Configuration Guide

USING THE CLI

Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX Series - Configuration Guide

About This Document

System Description The AX Series

The AX Series Advanced Traffic Manager

The AX Series is the industrys best performing application acceleration

AX Series - Configuration Guide

Representations of Layer 2 and Layer 3 Devices

Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX Series - Configuration Guide

Obtaining Technical Assistance

Collecting System Information.............................................................................................................. 5

About This Document

System Description The AX Series .................................................................................................... 7

AX Series - Configuration Guide

Enabling SNMP .............................................................................................................................. 50

Open Shortest Path First (OSPF)

Support for Multiple OSPFv2 Processes and OSPFv3 Instances...................................................105

HTTP Load Balancing

Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX Series - Configuration Guide

HTTP Options for SLB

FTP Load Balancing

AX Series - Configuration Guide

SIP Load Balancing

Load Balancing for SIP over UDP......................................................................................................183

SSL Offload and SSL Proxy

STARTTLS for Secure SMTP

Streaming-Media Load Balancing

Layer 4 TCP/UDP Load Balancing

IP Protocol Load Balancing

Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX Series - Configuration Guide

Configuring a Wildcard VIP ............................................................................................................... 271

SLB Protocol Translation

Stateless Load-Balancing Methods .................................................................................................. 285

Outbound Link Load Balancing

Configuring Link Load Balancing .................................................................................................. 291

Transparent Cache Switching

Firewall Load Balancing

AX Series - Configuration Guide

Server and Port Templates

Default Health Checks ........................................................................................................................373

Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010

AX Series - Configuration Guide

Maintenance Health Status for Servers in Persistence Configurations ........................................ 407

Global Server Load Balancing

AX Series - Configuration Guide

Configure Sites ............................................................................................................................. 475

Document No.: D-030-01-00-0006 - Ver. 2.4.3 6/21/2010