A10 Ax Confguration Guide 2p6k1h

ed by: Rudolf TheRednose Reindeer
0
0

December 2019
PDF

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

Overview 26281t

& View A10 Ax Confguration Guide as PDF for free.

More details 6y5l6z

Words: 234,645
Pages: 960

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 11/3/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 () Fax: +1-408-325-8666 www.a10networks.com

©

A10 Networks, Inc. 11/3/2010 - All Rights Reserved

Information in this document is subject to change without notice. Trademarks A10 Networks, the A10 logo, ACOS, aFleX, aFlow, aGalaxy, aVCS, aXAPI, IDaccess, IDSENTRIE, IP to ID, SmartFlow, SoftAX, VirtualADC, Virtual Chassis, and VirtualN are trademarks or ed 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

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

A10 Networks Inc. Software License and End 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 of this Agreement. Customer shall not: 1) reverse engineer, reverse compile, reverse de-assemble or otherwise translate the Software by any means 2) sublicense, rent or lease the Software.

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

Environmental Considerations Some electronic components may possibly contain dangerous substances. For information on specific component types, please 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, and conditions of delivery, and pricing, your nearest A10 Networks, Inc. location which can be found by visiting www.a10networks.com.

AX Series - Configuration Guide About This Document

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

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

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

3 of 1088

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

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

4 of 1088

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

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

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

5 of 1088

AX Series - Configuration Guide About This Document

6 of 1088

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

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 service contracts, the A10 Networks Technical Assistance Center provides services online and over the phone.

Corporate Headquarters A10 Networks, Inc. 2309 Bering Dr. San Jose, CA 95131-1125 USA Tel: +1-408-325-8668 (main) Tel: +1-888-822-7210 ( – toll-free in USA) Tel: +1-408-325-8676 ( – 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 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.

P e r f o r m a n c e

b y

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

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

7 of 960

AX Series - Configuration Guide About This Document

USING THE CLI 1. to 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 at the prompt. 4. Enter the show tech command. 5. After the command output finishes, save the output in a file. 6. Email the file as an attachment to [email protected]. Note:

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

8 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide About This Document

About This Document This document describes the features of the A10 Networks AX Series™ Advanced Traffic Manager. Configuration examples of the major features are provided. Additional information is available for AX Series systems in the following documents. These documents are included on the documentation CD shipped with your AX Series system, and also are available on the A10 Networks 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 industry’s best performing application acceleration switch that helps organizations scale and maximize application availability through the world’s most advanced application delivery platform. The AX Series Advanced Core Operating System (ACOS) accelerates and P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

9 of 960

AX Series - Configuration Guide 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 27.

Audience This document is intended for use by network architects for determining applicability and planning implementation, and for system s 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

10 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

End License Agreement

3

Obtaining Technical Assistance

7

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

About This Document

9

System Description – The AX Series .................................................................................................... 9 Audience................................................................................................................................................ 10 Representations of Layer 2 and Layer 3 Devices .............................................................................. 10

System Overview

27

AX Series Features............................................................................................................................... 27 ACOS Architecture ............................................................................................................................... 29 AX Software Processes .................................................................................................................. 29 Local File Storage ........................................................................................................................... 31 Hardware Interfaces ............................................................................................................................. 32 Software Interfaces............................................................................................................................... 32 Server Load Balancing......................................................................................................................... 33 Intelligent Server Selection ............................................................................................................. 34 Configuration Templates ................................................................................................................. 34 Global Server Load Balancing............................................................................................................. 36 Outbound Link Load Balancing .......................................................................................................... 36 Transparent Cache Switching ............................................................................................................. 36 Firewall Load Balancing....................................................................................................................... 36 Where Do I Start?.................................................................................................................................. 37

Basic Setup

39

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

11 of 960

AX Series - Configuration Guide Contents

Enabling SNMP .............................................................................................................................. 52 SNMP Traps ................................................................................................................................ 53 SNMP Communities and Views .................................................................................................. 55 SNMP Configuration Steps ......................................................................................................... 56 Configuration Examples .......................................................................................................................59 Emailing Log Messages........................................................................................................................66

Network Setup

73

Overview ................................................................................................................................................73 IP Subnet .......................................................................................................................... 73 Transparent Mode .................................................................................................................................75 Configuration Example ................................................................................................................... 76 Transparent Mode in Multinetted Environment ..................................................................................82 Configuration Example ................................................................................................................... 84 Route Mode............................................................................................................................................88 Configuration Example ................................................................................................................... 89 Direct Server Return in Transparent Mode .........................................................................................93 Configuration Example ................................................................................................................... 95 Direct Server Return in Route Mode....................................................................................................98 Configuration Example ................................................................................................................... 99 Direct Server Return in Mixed Layer 2/Layer 3 Environment..........................................................101

Open Shortest Path First (OSPF)

107

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

HTTP Load Balancing

115

Overview ..............................................................................................................................................115 Configuring HTTP Load Balancing....................................................................................................120

12 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

HTTP Options for SLB

131

Overview.............................................................................................................................................. 131 Summary of HTTP Options ........................................................................................................... 131 HTTP Template Configuration ...................................................................................................... 133 URL Hash Switching........................................................................................................................... 134 URL Hash Switching with Server Load Awareness ...................................................................... 136 Configuring URL Hashing ............................................................................................................. 138 URL / Host Switching ......................................................................................................................... 139 Configuring URL / Host Switching ................................................................................................ 142 Using URL / Host Switching along with Cookie Persistence ........................................................ 143 Using URL / Host Switching along with Source IP Persistence .................................................... 147 URL Failover........................................................................................................................................ 147 Configuring URL Failover ............................................................................................................. 148 5xx Retry and Reassignment............................................................................................................. 149 Content Compression ........................................................................................................................ 150 Hardware-Based Compression ..................................................................................................... 152 How the AX Device Determines Whether to Compress a File ...................................................... 153 Configuring Content Compression ................................................................................................ 154 Client IP Insertion / Replacement...................................................................................................... 157 Configuring Client IP Insertion / Replacement .............................................................................. 159 Header Insertion / Erasure ................................................................................................................. 160 Configuring Header Insertion / Replacement ................................................................................ 161 Configuring Header Erasure ......................................................................................................... 164 URL Redirect Rewrite......................................................................................................................... 165 Configuring URL Redirect Rewrite ................................................................................................ 166 Strict Transaction Switching ............................................................................................................. 167 Enabling Strict Transaction Switching .......................................................................................... 168

FTP Load Balancing

169

Overview.............................................................................................................................................. 169 Configuring FTP Load Balancing...................................................................................................... 171

SIP Load Balancing

189

Load Balancing for SIP over UDP ..................................................................................................... 189 Configuring Load Balancing for SIP over UDP ............................................................................. 190 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

13 of 960

AX Series - Configuration Guide Contents

Load Balancing for SIP over T/TLS ..............................................................................................203 SIP Multiplexing ............................................................................................................................ 203 Client Keepalive and Server Keepalive ........................................................................................ 206 AX Actions if Selection of a Client or SIP Server Fails ................................................................. 207 SLB Network Address Translation for SIP over T / TLS .......................................................... 207 Configuring SIP over T / TLS for SIP Multiplexing .................................................................. 208 CLI Example ............................................................................................................................. 219 Displaying SIP SLB Statistics .................................................................................................... 221 CLI Example ............................................................................................................................. 221 Disabling Reverse NAT Based on Destination IP Address..............................................................222 IP NAT for SIP ......................................................................................................................................224

SSL Offload and SSL Proxy

225

Overview ..............................................................................................................................................225 Choosing an SSL Optimization Implementation ........................................................................... 225 Configuring Client SSL .......................................................................................................................226 Configuring HTTPS Offload................................................................................................................230 Configuring the SSL Proxy Feature...................................................................................................237

STARTTLS for Secure SMTP

245

Overview ..............................................................................................................................................245 Configuring STARTTLS ......................................................................................................................247

Streaming-Media Load Balancing

255

Overview ..............................................................................................................................................255 Configuring Streaming-Media SLB....................................................................................................257

Layer 4 T/UDP Load Balancing

261

Overview ..............................................................................................................................................261 Configuring Layer 4 Load Balancing.................................................................................................264

IP Protocol Load Balancing

269

Overview ..............................................................................................................................................269 Configuring IP Protocol Load Balancing ..........................................................................................272

14 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

Wildcard VIPs

277

Configuring a Wildcard VIP ............................................................................................................... 277 Configuration Examples ............................................................................................................ 281

SLB Protocol Translation

283

Stateless SLB

291

Stateless Load-Balancing Methods .................................................................................................. 291

Outbound Link Load Balancing

295

Configuring Link Load Balancing .................................................................................................. 297

Transparent Cache Switching

301

Overview.............................................................................................................................................. 301 Configuring Layer 4 TCS.................................................................................................................... 304 Configuring Layer 7 TCS.................................................................................................................... 307 Service Type HTTP Without URL Switching Rules ...................................................................... 310 Service Type HTTP with URL Switching Rules ............................................................................ 311 Optimizing TCS with Multiple Cache Servers ............................................................................... 312 Enabling for Cache Spoofing .......................................................................................... 314 Configuring IPv4 TCS in High Availability Layer 3 Inline Mode ..................................................... 315 AX-1 Configuration ....................................................................................................................... 318 AX-2 Configuration ....................................................................................................................... 320 Configuring IPv6 TCS in High Availability Layer 3 Inline Mode ..................................................... 322 AX-1 Configuration ....................................................................................................................... 323 AX-2 Configuration ....................................................................................................................... 326 Configuring TCS for FTP.................................................................................................................... 328 Configuration ................................................................................................................................ 329

Firewall Load Balancing

333

Overview.............................................................................................................................................. 333 FWLB HA with Direct Connection of AX Devices to Firewalls ...................................................... 335 FWLB Parameters............................................................................................................................... 338 T and UDP Session Aging ....................................................................................................... 342 Configuring FWLB .............................................................................................................................. 343

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

15 of 960

AX Series - Configuration Guide Contents

Server and Port Templates

361

Overview ..............................................................................................................................................361 Parameters That Can Be Configured Using Server and Port Templates ..................................... 362 Default Server and Service Port Templates ................................................................................. 364 Configuring Server and Service Port Templates..............................................................................365 Applying a Server or Service Port Template.....................................................................................366 Binding a Server Template to a Real Server ................................................................................ 367 Binding a Server Port Template to a Real Server Port ................................................................. 368 Binding a Virtual Server Template to a Virtual Server .................................................................. 368 Binding a Virtual Server Port Template to a Virtual Service Port ................................................. 369 Binding a Server Port Template to a Service Group .................................................................... 369 Connection Limiting............................................................................................................................370 Setting a Connection Limit ........................................................................................................ 371 Connection Rate Limiting...................................................................................................................372 Slow-Start.............................................................................................................................................374 Gratuitous ARPs for Subnet VIPs......................................................................................................377 T Reset Option for Session Mismatch..........................................................................................378

Health Monitoring

381

Default Health Checks ........................................................................................................................381 Health Method Timers.........................................................................................................................382 Health Check Operation ............................................................................................................... 383 Health Method Types ..........................................................................................................................385 Protocol Port Numbers Tested by Health Checks ........................................................................ 390 Configuring and Applying a Health Method .....................................................................................390 Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments .............................. 394 Configuring POST Requests in HTTP/HTTPS Health Monitors ................................................... 396 Customizing DNS Health Monitors ............................................................................................... 399 Overriding the Target IP Address or Protocol Port Number ......................................................... 402 Basing a Port’s Health Status on Another Port’s Health Status ................................................... 405 Service Group Health Checks ............................................................................................................406 Disable Following Failed Health Check.............................................................................................409 In-Band Health Monitoring .................................................................................................................410 Configuring In-Band Health Monitoring ........................................................................................ 412 Consecutive Health Checks Within a Health Check Period ............................................................414 16 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

Maintenance Health Status for Servers in Persistence Configurations ........................................ 415 On-Demand Health Checks................................................................................................................ 416 Enabling Strict Retries ....................................................................................................................... 418 Globally Changing Health Monitor Parameters ............................................................................... 419 Globally Disabling Layer 3 Health Checks .................................................................................... 420 Compound Health Monitors............................................................................................................... 421 Displaying Health Status.................................................................................................................... 425 Using External Health Methods......................................................................................................... 428 Configuration ................................................................................................................................ 428 Script Examples ............................................................................................................................ 430 TCL Script Example .................................................................................................................. 430 Perl Script Example ................................................................................................................... 432 Shell Script Example ................................................................................................................. 433

Global Server Load Balancing

435

Overview.............................................................................................................................................. 435 Advantages of GSLB .................................................................................................................... 437 Zones, Services, and Sites ........................................................................................................... 438 GSLB Policy .................................................................................................................................. 438 Health Checks ........................................................................................................................... 440 Geo-Location ............................................................................................................................. 441 DNS Options ............................................................................................................................. 443 Metrics That Require the GSLB Protocol on Site AX Devices .................................................. 445 Configuration Overview ..................................................................................................................... 446 Configure Health Monitors ............................................................................................................ 447 Configure the DNS Proxy ............................................................................................................. 448 Configure a GSLB Policy .............................................................................................................. 450 Enabling / Disabling Metrics ...................................................................................................... 450 Changing the Metric Order ........................................................................................................ 452 Configuring RTT Settings .......................................................................................................... 453 ive RTT .............................................................................................................................. 459 Configuring BW-Cost Settings ................................................................................................... 461 Configuring Alias Preference ......................................................................................... 466 Configuring Weighted Alias ....................................................................................................... 467 Loading or Configuring Geo-Location Mappings ....................................................................... 467 Configure Services ....................................................................................................................... 476 Gateway Health Monitoring ....................................................................................................... 477 CLI Example—Site with Single Gateway Link ........................................................................... 480 CLI Example—Site with Multiple Gateway Links ....................................................................... 481 Multiple-Port Health Monitoring ................................................................................................. 481 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

17 of 960

AX Series - Configuration Guide Contents

Configure Sites ............................................................................................................................. 483 Configure a Zone .......................................................................................................................... 484 Enable the GSLB Protocol ........................................................................................................... 485 GSLB Parameters................................................................................................................................487 Policy Parameters ........................................................................................................................ 502 Configuration Examples .....................................................................................................................514 CLI Example ................................................................................................................................. 514 Configuration on the GSLB AX Device (GSLB Controller) ........................................................ 514 Configuration on Site AX Device AX-A ..................................................................................... 515 Configuration on Site AX Device AX-B ..................................................................................... 516 GUI Example ................................................................................................................................ 516 Configuration on the GSLB AX Device (GSLB Controller) ........................................................ 516 Configuration on Site AX Devices ............................................................................................. 526

RAM Caching

527

Overview ..............................................................................................................................................527 RFC 2616 ....................................................................................................................... 527 If-Modified-Since Header ............................................................................................. 528 for no-cache and max-age=0 Cache-Control Headers ................................................ 528 Insertion of Age and Via Headers into Cached Responses ...................................................... 529 Cacheability Behavior of AX RAM Cache .................................................................................... 529 Dynamic Caching ......................................................................................................................... 530 Host Verification ........................................................................................................................... 530 Configuring RAM Caching..................................................................................................................531

High Availability

541

Overview ..............................................................................................................................................541 Layer 3 Active-Standby HA .......................................................................................................... 542 Layer 3 Active-Active HA .............................................................................................................. 544 Layer 2 Active-Standby HA (Inline Deployment) .......................................................................... 546 Preferred HA Port ...................................................................................................................... 549 Port Restart ............................................................................................................................... 550 Layer 3 Active-Standby HA (Inline Deployment) .......................................................................... 551 HA Messages ............................................................................................................................... 552 HA Heartbeat Messages ........................................................................................................... 553 Gratuitous ARPs ....................................................................................................................... 553 HA Interfaces ................................................................................................................................ 554 Session Synchronization .............................................................................................................. 555

18 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

Optional Failover Triggers ............................................................................................................ 556 VLAN-based Failover ................................................................................................................ 556 Gateway-based Failover ........................................................................................................... 556 Route-based Failover ................................................................................................................ 557 Real Server or Port Health-based Failover ............................................................................... 557 VIP-based Failover .................................................................................................................... 558 How the Active AX Device Is Selected ......................................................................................... 559 HA Pre-Emption ............................................................................................................................ 562 HA Sets ......................................................................................................................................... 563 HA Configuration Parameters ....................................................................................................... 564 HA Status Indicators .......................................................................................................................... 571 In the GUI .................................................................................................................................. 571 In the CLI ................................................................................................................................... 571 Configuring Layer 3 HA...................................................................................................................... 572 Configuring Layer 2 HA (Inline Mode) .............................................................................................. 582 Layer 2 Inline HA Configuration Example ..................................................................................... 582 Configuring Layer 3 HA (Inline Mode) .............................................................................................. 590 Layer 3 Inline HA Configuration Example ..................................................................................... 591 Configuring Optional Failover Triggers............................................................................................ 596 VLAN-Based Failover Example .................................................................................................... 596 Gateway-Based Failover Example ............................................................................................... 597 Route-Based Failover Example .................................................................................................... 599 VIP-Based Failover Example ........................................................................................................ 601 Forcing Active Groups to Change to Standby Status..................................................................... 603 Enabling Session Synchronization................................................................................................... 603 Configuring OSPF-Related HA Parameters...................................................................................... 605 OSPF Awareness of HA ............................................................................................................... 605 OSPF on Standby AX in Layer 3 Inline Mode ................................................................. 606 Synchronizing Configuration Information........................................................................................ 606 Configuration Items That Are Backed Up ..................................................................................... 607 Configuration Items That Are Not Backed Up ........................................................................... 608 Performing HA Synchronization .................................................................................................... 610 Tip for Ensuring Fast HA Failover..................................................................................................... 612

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

19 of 960

AX Series - Configuration Guide Contents

Network Address Translation

615

SLB NAT ...............................................................................................................................................616 SLB Destination NAT ................................................................................................................... 616 SLB Source NAT .......................................................................................................................... 617 IP Source NAT Configuration Limits ......................................................................................... 617 Connection Reuse .................................................................................................................... 617 Source NAT for Servers in Other Subnets ................................................................................ 622 Direct Server Return ..................................................................................................................... 624 IP NAT for VIPs .............................................................................................................. 626 Using IP Pool Default Gateways To Forward Traffic from Real Servers ...................................... 627 IP Source NAT......................................................................................................................................627 Configuring Dynamic IP Source NAT ........................................................................................... 629 Configuring Static IP Source NAT ................................................................................................ 635 NAT ALG for PPTP ......................................................................................................... 638 Configuring NAT ALG for PPTP ................................................................................................ 639 Fast Aging for IP NATted ICMP and DNS Sessions .................................................................... 642 Client and Server T Resets for NATted T Sessions ........................................................... 644 Requirements for Translation of DNS Traffic ............................................................................... 644 IP NAT Use in Transparent Mode in Multi-Netted Environment ................................................... 644 NAT Range List Requires AX Interface or Route Within the Global Subnet ................................ 645 IP NAT in HA Configurations ........................................................................................................ 645

Large-Scale Network Address Translation

647

Overview ..............................................................................................................................................647 How LSN Differs from Traditional NAT ......................................................................................... 651 Benefits of LSN ............................................................................................................................ 653 Sticky NAT ................................................................................................................................ 653 Full-Cone NAT .......................................................................................................................... 653 Hairpinning ................................................................................................................................ 655 Quotas .............................................................................................................................. 655 Static Port Reservation ............................................................................................................. 660 LSN Logging ................................................................................................................................. 661 LSN Operational Logging .......................................................................................................... 661 LSN Traffic Logging .................................................................................................................. 662 LSN NAT Capacities .................................................................................................................... 663 Notes and Limitations ................................................................................................................... 665 Configuring Large-Scale NAT ............................................................................................................666 Configure an LSN NAT Pool ........................................................................................................ 667 Configure a LID ............................................................................................................................ 667 Configure a Class List .................................................................................................................. 668

20 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

Bind the CLass List for Use with LSN ........................................................................................... 669 Enable Inside NAT on the Interface Connected to Internal Clients .............................................. 669 Enable Outside NAT on the Interface Connected to the Internet ................................................. 669 Enable New-path Processing ....................................................................................................... 669 Optional Configuration .................................................................................................................. 670 Configuring Static Mappings ..................................................................................................... 670 Enabling Full-Cone for Well-Known Ports ................................................................... 670 Configuring External Logging for LSN Traffic Logs ................................................................... 671 Configure the IP Selection Method ............................................................................................ 673 Configuring the LSN SYN Timeout ............................................................................................ 673 Displaying LSN Information............................................................................................................... 674 Clearing LSN Statistics and Sessions .......................................................................................... 674 Configuration Example ...................................................................................................................... 675

Management Security Features

679

Configuring Additional s ......................................................................................... 679 Configuring an ..................................................................................................... 680 Deleting an .......................................................................................................... 684 Configuring Lockout .............................................................................................................. 685 Securing Access by Ethernet................................................................................................ 687 Displaying the Current Management Access Settings .................................................................. 690 Regaining Access if You Accidentally Block All Access ............................................................... 691 Changing Web Access Settings........................................................................................................ 691 Configuring AAA for Access ................................................................................................. 694 Authentication ............................................................................................................................... 694 Authentication Process .............................................................................................................. 694 Authorization for GUI Access ........................................................................................................ 698 Authorization for CLI Access ........................................................................................................ 698 RADIUS CLI Authorization ........................................................................................................ 698 TACACS+ CLI Authorization ..................................................................................................... 699 RADIUS Authorization Based on Service-Type ........................................................................ 700 ing .................................................................................................................................... 701 Command ing (TACACS+ only) ................................................................................... 701 TACACS+ ing Debug Options ...................................................................................... 702 Configuring AAA for Access .............................................................................................. 702 Configuring Authentication ........................................................................................................ 703 Configuring Authorization .......................................................................................................... 704 Configuring ing ............................................................................................................. 705

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

21 of 960

AX Series - Configuration Guide Contents

Configuring Windows IAS for AX RADIUS Authentication ........................................................... 708 Procedure Overview .................................................................................................................. 709 Configure Access Groups ......................................................................................................... 709 Configure RADIUS Client for AX Device ................................................................................... 710 Configure Remote Access Policies ........................................................................................... 712 Add AD s to AX Access Groups ........................................................................................ 722 the IAS Server in Active Directory .............................................................................. 723 Configure RADIUS in the AX Device ........................................................................................ 724 Test the Configuration ............................................................................................................... 724

Traffic Security Features

725

DDoS Protection..................................................................................................................................725 Enabling DDoS Protection ............................................................................................................ 727 Configuring IP Anomaly Filters for System-Wide PBSLB ............................................................. 727 Displaying and Clearing IP Anomaly Statistics ............................................................................. 728 SYN Cookies ........................................................................................................................................728 The Service Provided By SYN Cookies ....................................................................................... 729 Enabling Hardware-Based SYN Cookies ..................................................................................... 730 Configuration when Target VIP and Client-side Router Are in Different Subnets ..................... 731 Enabling Software-Based SYN Cookies ...................................................................................... 732 Configuring Layer 2/3 SYN Cookie ................................................................................. 733 ICMP Rate Limiting..............................................................................................................................734 Source-IP Based Connection Rate Limiting .....................................................................................736 Parameters ................................................................................................................................... 737 Log Messages .............................................................................................................................. 737 Deployment Considerations ......................................................................................................... 738 Configuration ............................................................................................................................. 739 Configuration Examples ............................................................................................................... 740 DNS Security........................................................................................................................................741 Access Control Lists (ACLs)..............................................................................................................743 How ACLs Are Used .................................................................................................................... 743 Configuring Standard IPv4 ACLs ................................................................................................. 744 Configuring Extended IPv4 ACLs ................................................................................................. 746 Configuring Extended IPv6 ACLs ................................................................................................. 750 Adding a Remark to an ACL ......................................................................................................... 753 Transparent Session Logging ...................................................................................................... 754 Sample Log Messages for Transparent Sessions .................................................................... 754 Configuration ............................................................................................................................. 755 Applying an ACL to an Interface ................................................................................................... 756 Applying an ACL to a Virtual Server Port ..................................................................................... 757 22 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

Using an ACL to Control Management Access ............................................................................ 758 Using an ACL for NAT .................................................................................................................. 758 Resequencing ACL Rules ............................................................................................................. 758 Policy-Based SLB (PBSLB) ............................................................................................................... 761 Configuring a Black/White List ...................................................................................................... 761 Dynamic Black/White-list Client Entries .................................................................................... 762 Configuring System-Wide PBSLB ................................................................................................ 764 Configuring PBSLB for Individual Virtual Ports ............................................................................. 766 Displaying PBSLB Information .................................................................................................. 774 Configuration Example—Sockstress Attack Protection ................................................................ 776 Geo-location-based Access Control for VIPs .................................................................................. 778 Configuration ............................................................................................................................. 779 Enabling PBSLB Statistics Counter Sharing ............................................................................. 784 Enabling Full-Domain Checking for Connection Limits ............................................................. 785

IP Limiting

787

Overview.............................................................................................................................................. 787 Class Lists .................................................................................................................................... 787 Class List Syntax ....................................................................................................................... 788 IP Address Matching ................................................................................................................. 788 Example Class Lists .................................................................................................................. 789 IP Limiting Rules ........................................................................................................................... 789 Match IP Address ...................................................................................................................... 790 Configuring Source IP Limiting......................................................................................................... 791 Configuring a Class List ................................................................................................................ 791 Configuring the IP Limiting Rules ................................................................................................. 795 Applying Source IP Limits ............................................................................................................. 798 Displaying IP Limiting Information ................................................................................................ 800 CLI Examples—Configuration ...................................................................................................... 801 Configure System-Wide IP Limiting With a Single Class .......................................................... 801 Configure System-Wide IP Limiting With Multiple Classes ....................................................... 801 Configure IP Limiting on a Virtual Server .................................................................................. 802 Configure IP Limiting on a Virtual Port ...................................................................................... 803 CLI Examples—Display ................................................................................................................ 803 Class Lists ................................................................................................................................. 803 IP Limiting Rules ....................................................................................................................... 805 IP Limiting Statistics .................................................................................................................. 806

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

23 of 960

AX Series - Configuration Guide Contents

Role-Based istration

807

Overview ..............................................................................................................................................808 Resource Partitions ...................................................................................................................... 809 Roles ...................................................................................................................... 811 Configuring Role-Based istration...........................................................................................813 Configuring Private Partitions ....................................................................................................... 813 Changing the Maximum Number of aFleX Policies Allowed in a Partition ................................ 814 Migrating Resources Between Partitions .................................................................................. 815 Deleting a Partition .................................................................................................................... 815 Configuring Partition s .......................................................................................... 816 CLI Example ................................................................................................................................. 818 Viewing and Saving the Configuration..............................................................................................819 Viewing the Configuration ............................................................................................................ 819 Saving the Configuration .............................................................................................................. 820 Switching To Another Partition..........................................................................................................821 Synchronizing the Configuration.......................................................................................................822 Operator Management of Real Servers .............................................................................................824

SLB Parameters

829

Service Template Parameters ............................................................................................................829 Cache Template Parameters ....................................................................................................... 831 Client SSL Template Parameters ................................................................................................. 833 Connection Reuse Template Parameters .................................................................................... 836 Cookie Persistence Template Parameters ................................................................................... 837 Destination-IP Persistence Template Parameters ....................................................................... 839 DNS Template Parameters .......................................................................................................... 842 HTTP Template Parameters ........................................................................................................ 842 Policy Template Parameters ........................................................................................................ 849 Server SSL Template Parameters ............................................................................................... 853 SIP Template Parameters (SIP over T/TLS) ........................................................................... 854 SIP Template Parameters (SIP over UDP) .................................................................................. 857 SMTP Template Parameters ........................................................................................................ 858 Source-IP Persistence Template Parameters .............................................................................. 860 SSL Session-ID Persistence Template Parameters ..................................................................... 863 Streaming-Media Template Parameters ...................................................................................... 864 T Template Parameters ........................................................................................................... 864 T-Proxy Template Parameters ................................................................................................ 865 UDP Template Parameters .......................................................................................................... 867

24 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Contents

Global SLB Parameters...................................................................................................................... 868 Real Server Parameters ..................................................................................................................... 874 Real Service Port Parameters............................................................................................................ 877 Service Group Parameters................................................................................................................. 879 Virtual Server Parameters.................................................................................................................. 884 Virtual Service Port Parameters ........................................................................................................ 887

Dynamic Real Server Creation Using DNS

895

Template Options for Dynamically Created Real Servers............................................................... 896 Configuring Dynamic Real Server Creation ..................................................................................... 898

VIP Creation Based on Subnet

903

Sending a Reset After Server Selection Failure

905

Scan-All- Option in Persistence Templates

911

SSL Certificate Management

915

Overview.............................................................................................................................................. 915 SSL Process ................................................................................................................................. 915 Certificate Chain ........................................................................................................................ 917 Certificate Warning from Client Browser ................................................................................... 918 CA-Signed and Self-Signed Certificates ................................................................................... 919 SSL Templates .......................................................................................................................... 920 Certificate Installation Process ..................................................................................................... 922 Requesting and Installing a CA-Signed Certificate ................................................................... 922 Installing a Self-Signed Certificate ............................................................................................ 924 Generating a Key and CSR for a CA-Signed Certificate ................................................................. 925 Importing a Certificate and Key......................................................................................................... 928 Generating a Self-Signed Certificate ................................................................................................ 930 Importing a CRL.................................................................................................................................. 932 Exporting Certificates, Keys, and CRLs ........................................................................................... 933 Exporting a Certificate and Key .................................................................................................... 933 Exporting a CRL ........................................................................................................................... 934 Creating a Client-SSL or Server-SSL Template and Binding it to a VIP ........................................ 935 Creating an SSL Template ........................................................................................................... 935

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

25 of 960

AX Series - Configuration Guide Contents

Binding an SSL Template to a VIP ............................................................................................... 936 Converting Certificates and CRLs to PEM Format...........................................................................936 Converting SSL Certificates to PEM Format ................................................................................ 937 Converting CRLs from DER to PEM Format ................................................................................ 938

Using the Management Interface as the Source for Management Traffic

939

Route Tables ........................................................................................................................................939 Management Routing Options ...........................................................................................................940 Enabling Use of the Management Interface as the Source for Automated Management Traffic ........................................................................................................................................... 941 Using the Management Interface as the Source Interface for Manually Generated Management Traffic ..................................................................................................................... 942 Commands at the EXEC Level ......................................................................................... 942 Commands at the Privileged EXEC Level ................................................................................. 942 Commands at the Global Configuration Level .......................................................................... 942 Show Commands ...................................................................................................................... 943

Configuration Management

945

Backing Up System Information ........................................................................................................945 Saving Multiple Configuration Files Locally.....................................................................................947 Configuration Profiles ................................................................................................................... 948 Commands for Local Configuration Management ........................................................................ 948

VLAN-to-VLAN Bridging

955

Configuring VLAN-to-VLAN Bridging ........................................................................................ 956

26 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide AX Series Features

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

AX Series Features Key features of the AX Series include: • Application Delivery Features • Comprehensive IPv4/IPv6 • Transparent (Layer 2) and gateway (Layer 3) mode for

•

• • • • • • •

easy deployment into existing infrastructures • Network Address Translation (NAT) – IPv4-IPv4, IPv4-IPv6, IPv6-IPv4, IPv6-IPv6, ALG for PPTP, Large-Scale NAT (LSN) • OSPFv2 for IPv4, OSPFv3 for IPv6 • IPv4/IPv6 static routes • DH relay Advanced Layer 4/7 Server Load Balancing • Fast T, fast UDP, fast HTTP, and full HTTP Proxy • Comprehensive protocol : HTTP, HTTPS, FTP, T, 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 – 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

27 of 960

AX Series - Configuration Guide AX Series Features • Acceleration and Security • SSL acceleration and offload • Traffic security • Management access security – Local database and

for optional remote RADIUS or TACACS+ AAA • Spam filter (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 Interface (GUI) with language localiza• • • •

tion Industry-standard Command Line Interface (CLI) On-demand backup of configuration files, logs, and system files SNMP, syslog, alerting Virtualized Management, provided by Role-Based istration (RBA)

• Troubleshooting tools • Port mirroring • Debug subsystem for packet capture

28 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 Us 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 s 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) is ed. 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 -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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

29 of 960

AX Series - Configuration Guide 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, 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 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 logs into

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

30 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 tech 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 tech files use no more than 3-4 G. aFleX scripts range from 0-500 KB. Monitoring data includes objects for U, 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 . 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

31 of 960

AX Series - Configuration Guide 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 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

32 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Server Load Balancing

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

P e r f o r m a n c e

b y

SLB Example

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

33 of 960

AX Series - Configuration Guide Server Load Balancing

Intelligent Server Selection The services managed by the AX device are controlled by service groups. A service group is a set of real servers. The AX device selects a real server for a client’s request based on a set of tunable criteria including server health, server response time, and server load. These criteria can be tuned for individual servers and even individual service ports. The AX device provides a robust set of configurable health monitors for checking the health (availability) of servers and individual services. For more information, see “Health Monitoring” on page 381.

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: • T-Proxy – Controls T/IP stack parameters • T – Controls the idle timeout for unused sessions and specifies

whether the AX device sends T 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

34 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Server Load Balancing • 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 T connection setup by

establishing and reusing T 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 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 T 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 115 • “FTP Load Balancing” on page 169 • “SIP Load Balancing” on page 189 • “SSL Offload and SSL Proxy” on page 225 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

35 of 960

AX Series - Configuration Guide Global Server Load Balancing • “STARTTLS for Secure SMTP” on page 245 • “Streaming-Media Load Balancing” on page 255 • “Layer 4 T/UDP Load Balancing” on page 261

For descriptions of all the parameters you can control using templates, see “Server and Port Templates” on page 361 and “Service Template Parameters” on page 829.

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

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

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

Firewall Load Balancing Firewall Load Balancing (FWLB) maximizes throughput through firewall bottlenecks by load balancing server-client sessions across the firewalls. For more information, see “Firewall Load Balancing” on page 333.

36 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Where Do I Start?

Where Do I Start? • To configure basic system settings, see “Basic Setup” on page 39. • To configure network settings, see “Network Setup” on page 73 and

“Routing Parameters” on page 835. • To configure traffic management features (SLB, GSLB, LLB, TCS, and

FWLB), see the remaining chapters in this guide.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

37 of 960

AX Series - Configuration Guide Where Do I Start?

38 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Logging On

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

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

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

Note:

This chapter does not describe how to access the 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 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 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:

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

39 of 960

AX Series - Configuration Guide 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 ed. The browser also must SSLv3 or TLS 1.0. Browsers that only SSLv2 are not ed. • SSH access to CLI – The SSH client used to access the CLI must sup-

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

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 679.) To log onto the CLI using SSH: 1. On a PC connected to a network that can access the AX device’s management interface, open an SSH connection to the IP address of the management interface. 2. Generally, if this the first time the SSH client has accessed the AX device, the SSH client displays a security warning. Read the warning carefully, then acknowledge the warning to complete the connection. (Press Enter.)

40 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Logging On 3. At the as: prompt, enter the name. 4. At the : prompt, enter the . If the name and are valid, the command prompt for the EXEC level of the CLI appears: AX> The 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 : prompt, enter the enable . (This is not the same as the , although it is possible to configure the same value for both s.) If the enable 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 ed on the Web browsers listed in Table 1. TABLE 1

GUI Browser Platform

Browser IE 7.0, 6.0 Firefox 3.x, 2.x Safari 3.0 Chrome

Windows ed

Linux N/A

ed Not ed Not ed

ed N/A Not ed

MAC N/A N/A ed Not ed

A screen resolution of at least 1024x768 is recommended. 1. Open one of the Web browsers listed in Table 1. 2. In the URL field, enter the IP address of the AX device’s management interface.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

41 of 960

AX Series - Configuration Guide Logging On 3. If the browser displays a certificate warning, select the option to continue to the server (the AX device). A dialog is displayed. The name and appearance of the dialog depends on the browser you are using. FIGURE 3

GUI Dialog (Internet Explorer)

4. Enter your name and and click OK. Note:

The default name and are “”, “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.

42 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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:

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

P e r f o r m a n c e

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 11/3/2010

43 of 960

AX Series - Configuration Guide Configuring Basic System Parameters

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 :enable- 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

44 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Basic System Parameters 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: as: Welcome to AX Using keyboard-interactive authentication. : Last : 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

45 of 960

AX Series - Configuration Guide Configuring Basic System Parameters c. Enter the message in the 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 | } [multi-line end-marker] line The option changes the first banner, which is displayed after you enter the name. The exec option changes the second banner, which is displayed after you enter the . 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.

46 of 960

Note:

You do not need to configure Daylight Savings Time. The AX device automatically adjusts the time for Daylight Savings Time based on the timezone you select.

Note:

When you change the AX timezone or system time, the statistical database is cleared. This database contains general system statistics (performance, and U, memory, and disk utilization) and SLB statistics. For

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Basic System Parameters example, in the GUI, the graphs displayed on the Monitor > Overview page are cleared.

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

47 of 960

AX Series - Configuration Guide Configuring Basic System Parameters 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

48 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Basic System Parameters • 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 ed: • 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:

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

49 of 960

AX Series - Configuration Guide Configuring Basic System Parameters 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 device’s data ports, not the management port. To enable the AX device to reach remote log servers through the management port, see “Using the Management Interface as the Source for Management Traffic” on page 939. 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 device’s data ports, not the management port. To enable the AX device to reach SMTP servers through the management port, see “Using the Management Interface as the Source for Management Traffic” on page 939. Protocol port to which email messages sent to the SMTP server are addressed.

ed 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. Default: None configured

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.

50 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Basic System Parameters 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 1. Select Config > System > Settings. 2. Select Log on the menu bar. 3. Change settings as needed. (For descriptions of the settings, see Table 2.) 4. Click OK.

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

P e r f o r m a n c e

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

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

51 of 960

AX Series - Configuration Guide Configuring Basic System Parameters 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 52.

Enabling SNMP AX devices 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 ed. The AX device s 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

52 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Basic System Parameters • 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 ed: • 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, -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 ed by the AX device. All traps are disabled by default. TABLE 3

AX SNMP Traps

Trap Category SNMP

P e r f o r m a n c e

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 11/3/2010

53 of 960

AX Series - Configuration Guide Configuring Basic System Parameters TABLE 3

AX SNMP Traps (Continued)

Trap Category System

Trap Start Shutdown Restart Control U 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 U utilization is higher than 90%.*

Data U utilization

Indicates that data U 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. A10 Networks. Indicates that a power supply has failed. A10 Networks. Indicates that the primary Hard Disk has failed or the RAID system has failed. 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. 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

High Availability (HA)

Active Standby Active-Active

54 of 960

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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Basic System Parameters TABLE 3

AX SNMP Traps (Continued)

Trap Category Server Load Balancing (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 server’s service port is up when at least one member (real server and real port) in the service group bound to the virtual port is up. Indicates that an SLB virtual service port has gone down. Indicates that the configured SLB application buffer threshold has been exceeded.*

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

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 s. You can minimize security risk by applying the same principles to selecting a community name as you

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

55 of 960

AX Series - Configuration Guide Configuring Basic System Parameters would to selecting a . 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 groups and individual SNMP s, and allow or disallow them to read specific portions of the AX MIBs using different views. When you configure an SNMP group or , you specify the SNMP version. SNMP v1 and v2c do not authentication or encryption of SNMP packets. SNMPv3 does. You can enable authentication, encryption, or both, on an individual SNMP -group basis when you configure the groups. You can specify the authentication method and the for individual SNMP s when you configure the s.

SNMP Configuration Steps To configure SNMP: 1. Optionally, configure location and information. 2. Optionally, configure external SNMP trap receivers. 3. Optionally, configure one or more read-only communities. 4. Optionally, configure views, groups, and s. 5. Enable the SNMP agent and SNMP traps. 6. Save the configuration changes. You are not required to perform these configuration tasks in precisely this order. The workflow in the GUI is slightly different from the workflow shown here. Note: By default, the AX device can reach remote logging and trap servers only if they are reachable through the AX device’s data ports, not the management port. To enable the AX device to reach remote logging and trap servers through the management port, see “Using the Management Interface as the Source for Management Traffic” on page 939.

56 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Basic System Parameters

USING THE GUI To configure for SNMPv3 or to configure views, groups, and s, use the CLI. The current release does not 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 device’s location. c. In the System field, enter the name or email address of the AX to 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

57 of 960

AX Series - Configuration Guide Configuring Basic System Parameters 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 information, use the following commands: snmp-server location location snmp-server -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}]

58 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples 4. To configure views, groups, and s, 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 name group groupname {v1 | v2 | v3 [auth {md5 | sha} [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

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

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

P e r f o r m a n c e

b y

The GUI does not configuration of SNMPv3 settings.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

59 of 960

AX Series - Configuration Guide Configuration Examples FIGURE 5

60 of 960

Config > Network > DNS > DNS

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples FIGURE 6

P e r f o r m a n c e

b y

Config > System > Time > Date/Time

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

61 of 960

AX Series - Configuration Guide Configuration Examples FIGURE 7

62 of 960

Config > System > Settings > Log

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples FIGURE 8

P e r f o r m a n c e

b y

Config > System > SNMP

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

63 of 960

AX Series - Configuration Guide Configuration Examples

64 of 960

FIGURE 9

Config > System > SNMP > Trap List

FIGURE 10

Save Button

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples

CLI EXAMPLE The following commands log onto the CLI, access the global configuration level, and set the hostname and configure the other DNS settings: as: Welcome to AX Using keyboard-interactive authentication. :******** Last : Tue Jan 13 19:51:56 2009 from 192.168.1.144 [type ? for help] AX>enable :******** 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 banner to “welcome to mode” and set the EXEC banner to “welcome to exec mode”: AX-SLB2(config)#banner “welcome to 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 s. 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 11/3/2010

65 of 960

AX Series - Configuration Guide Emailing Log Messages sage levels are sent to the management terminal in CLI sessions. The message level emailed to s is set to Emergency (0) messages only. AX-SLB2(config)#logging host 192.168.10.10

AX-SLB2(config)#smtp ourmailsrvr AX-SLB2(config)#logging email-address [email protected] 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 Me_1 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

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

not specify a message level, messages of any severity level match the filter and can be emailed. • Software Module – Software modules for which to email messages. Messages are emailed only if they come from one of the specified software modules. If you do not specify a software module, messages from all modules match the filter and can be emailed. • Regular Expression – Message text to match on. Standard regular expression syntax is ed. Only messages that meet the criteria of the regular expression can be emailed. The regular expression

66 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Emailing Log Messages 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 67”.) • Trigger option – Specifies whether to buffer matching messages or send

them immediately. Boolean Operators A logging email filter consists of a set of conditions ed 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 ed: • 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 1. Select Config > System > Settings. 2. On the menu bar, select Log. 3. In the Logging Email Filter section, click Add. A configuration page for the filter appears. 4. In the ID field, enter the filter ID, 1-8. 5. To immediately send matching messages in an email instead of buffering them, select Trigger. Otherwise, matching messages are buffered until the message buffer becomes full or the send timer for emailed log messages expires.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

67 of 960

AX Series - Configuration Guide Emailing Log Messages 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.

68 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Emailing Log Messages 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]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

69 of 960

AX Series - Configuration Guide Emailing Log Messages 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 ed. 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 ed in a filter.

70 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Emailing Log Messages • The total number of conditions plus the number of Boolean operators

ed in a filter is 16. • For backward compatibility, the following syntax from previous releases

is still ed: 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 es 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

71 of 960

AX Series - Configuration Guide Emailing Log Messages

72 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Network Setup This chapter describes how to insert the AX device into your network. After you complete the setup tasks in this chapter that are applicable to your network, the AX device will be ready to configure for its primary function: load balancing.

Overview AX Series devices can be inserted into your network with minimal or no changes to your existing network. You can insert the AX device into your network as a Layer 2 switch or a Layer 3 router. The same Layer 4-7 features are available with either deployment option. You can deploy the AX device as a single unit or as a High Availability (HA) pair. Deploying a pair of AX devices in an HA configuration provides an extra level of redundancy to help ensure your site remains available to clients. For simplicity, the examples in this chapter show deployment of a single AX device. For information about HA, see “High Availability” on page 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

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

73 of 960

AX Series - Configuration Guide Overview 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 interface’s address. An AX device deployed in route mode (Layer 3) can have separate IP addresses on each data interface. No two interfaces can have IP addresses that are in the same subnet. This applies to the management interface and all data interfaces.

74 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

75 of 960

AX Series - Configuration Guide 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 617.) 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 es 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

76 of 960

Config > Network > Interface > Transparent

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

77 of 960

AX Series - Configuration Guide Transparent Mode FIGURE 16

78 of 960

Config > Service > SLB > Server

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Transparent Mode Service group configuration FIGURE 17

P e r f o r m a n c e

b y

Config > Service > SLB > Service Group

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

79 of 960

AX Series - Configuration Guide Transparent Mode Virtual server configuration

80 of 960

FIGURE 18

Config > Service > SLB > Virtual Server

FIGURE 19

Config > Service > SLB > Virtual Server - Virtual Server Port

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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:ethernet2)#enable AX(config-if:ethernet2)#interface ethernet 3 AX(config-if:ethernet3)#enable 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 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server rs2 10.10.20.4 AX(config-real server)#port 80 t 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 t AX(config-slb service group)#member rs1:80 AX(config-slb service group)#member rs2: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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

81 of 960

AX Series - Configuration Guide Transparent Mode in Multinetted Environment

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.

82 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Transparent Mode in Multinetted Environment 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 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 device’s IP address. However, in a multinetted environment where the AX device is deployed in transparent mode, source NAT is required, to allow health checking of server 10.10.20.4 and its application port. In this example, an address pool containing a range of addresses in the 10.10.20.x subnet is configured. The pool configuration includes the default gateway for the 10.10.20.x subnet (10.10.20.1). Without a gateway 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:

P e r f o r m a n c e

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 11/3/2010

83 of 960

AX Series - Configuration Guide Transparent Mode in Multinetted Environment

Configuration Example This section shows the GUI screens and CLI commands needed to implement the configuration shown in Figure 20. 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 75.

USING THE GUI

84 of 960

FIGURE 21

Config > Network > VLAN

FIGURE 22

Config > Service > IP Source NAT > IPv4 Pool

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Transparent Mode in Multinetted Environment FIGURE 23

P e r f o r m a n c e

b y

Config > Service > SLB > Virtual Server - Virtual Server Port

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

85 of 960

AX Series - Configuration Guide Transparent Mode in Multinetted Environment

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:ethernet2)#enable AX(config-if:ethernet2)#interface ethernet 3 AX(config-if:ethernet3)#enable AX(config-if:ethernet3)#interface ethernet 4 AX(config-if:ethernet4)#enable AX(config-if:ethernet4)#exit

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

86 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Transparent Mode in Multinetted Environment Commands to configure the real servers AX(config)#slb server rs1 10.10.10.4 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server rs2 10.10.20.4 AX(config-real server)#port 80 t 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 t AX(config-slb service group)#member rs1:80 AX(config-slb service group)#member rs2: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...)#source-nat pool pool1 AX(config-slb virtual server-slb virtua...)#service-group sg-web

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

87 of 960

AX Series - Configuration Guide 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

88 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 OSPF. In this example, a static route is configured to use as the default route through 10.10.10.1. Although this example shows single physical links, you could use trunks as physical links. You also could use multiple VLANs. In this case, the IP addresses would be configured on Virtual Ethernet (VE) interfaces, one per VLAN, instead of being configured on individual Ethernet ports. Since the AX device is a router in this deployment, downstream devices can use the AX device as their default gateway. The database server would use 192.168.3.100 as its default gateway, the router connected to port 3 would use 192.168.1.111 as its default gateway, and the Layer 2 switch connected to 192.168.2.100 would use that address as its default gateway. If a pair of AX devices in a High Availability (HA) configuration is used, the downstream devices would use a floating IP address shared by the two AX devices as their default gateway. (For more on HA, see “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.

Configuration Example This section shows the GUI screens and CLI commands needed to implement the configuration shown in Figure 24. 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 75.

Note:

In the current release, the GUI does not configuration of OSPF.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

89 of 960

AX Series - Configuration Guide Route Mode

USING THE GUI

90 of 960

FIGURE 25

Config > Network > Interface > LAN > IPv4

FIGURE 26

Config > Network > Route > IPv4 Static

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Route Mode

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

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

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 192.168.1.101 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server rs2 192.168.2.101 AX(config-real server)#port 80 t 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 t AX(config-slb service group)#member rs1:80 AX(config-slb service group)#member rs2:80 AX(config-slb service group)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

91 of 960

AX Series - Configuration Guide Route Mode Commands to configure the virtual server AX(config)#slb virtual-server vip1 10.10.10.99 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#service-group sg-web

92 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Direct Server Return in Transparent Mode

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

93 of 960

AX Series - Configuration Guide Direct Server Return in Transparent Mode 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 back through the AX device. Note:

VIP redistribution is not ed for VIPs that are configured for Direct Server Return (DSR). DSR Health Checking Layer 3 and Layer 4-7 health checks are ed 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 T and UDP health monitors or configure new health monitors. This example uses the default T health monitor. Requirements This configuration has certain requirements: • Requirements on the AX device: • The AX device, virtual server, and the real servers all must be in the

same subnet. • The virtual server IP address must be configured as a loopback interface on each real server. (This is performed on the real server itself, not as part of the real server’s configuration on the AX device.) • DSR must be enabled on the virtual service ports. (Enabling DSR is equivalent to disabling destination NAT.) Note:

94 of 960

In the current release, for IPv4 VIPs, DSR is ed on virtual port types (service types) T, UDP, FTP, and RTSP. For IPv6 VIPs, DSR is ed on virtual port types T, UDP, and RTSP. P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Direct Server Return in Transparent Mode • 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.)

Configuration Example 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 device’s IP address and default gateway 1. Select Config > Network > Interface. 2. On the menu bar, select Transparent. 3. Enter the IP address, network mask or prefix length, and default 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) 1. Select Config > Network > Interface. 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

95 of 960

AX Series - Configuration Guide Direct Server Return in Transparent Mode 4. In the Virtual Server Port section, select Enabled next to Direct Server Return. Configure other settings if needed. (The other settings are not specific to DSR and depend on the application.) 5. Click OK. The virtual port list for the virtual server reappears. 6. Click OK again. The virtual server list reappears.

USING THE CLI The following commands configure the global IP address and default 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 interface connected to the clients and server: AX(config)#interface ethernet 3 AX(config-if:ethernet3)#enable 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 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server rs2 10.10.10.4 AX(config-real server)#port 80 t 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 t AX(config-slb service group)#member rs1:80 AX(config-slb service group)#member rs2:80 AX(config-slb service group)#exit

96 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Direct Server Return in Transparent Mode Commands to configure the virtual server AX(config)#slb virtual-server vip1 10.10.10.99 AX(config-slb virtual server)#port 80 t AX(config-slb virtual server-slb virtua...)#service-group sg-web 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

97 of 960

AX Series - Configuration Guide Direct Server Return in Route Mode

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

98 of 960

VIP redistribution is not ed for VIPs that are configured for Direct Server Return (DSR).

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Direct Server Return in Route Mode

Configuration Example 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 1. Select Config > Network > Interface. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

99 of 960

AX Series - Configuration Guide Direct Server Return in Route Mode

USING THE CLI The following commands enable the Ethernet interface used in the example and configure an IP address on it: AX(config)#interface ethernet 3 AX(config-if:ethernet3)#enable AX(config-if:ethernet3)#ip address 10.10.10.2 /24 AX(config-if:ethernet3)#exit

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

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

100 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Direct Server Return in Mixed Layer 2/Layer 3 Environment

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

101 of 960

AX Series - Configuration Guide Direct Server Return in Mixed Layer 2/Layer 3 Environment To deploy the backup server: • In the service group, assign a higher priority to the 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 server’s 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:

VIP redistribution is not ed for VIPs that are configured for Direct Server Return (DSR).

USING THE GUI Configure a port template to enable destination NAT on the backup server’s 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.

102 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Direct Server Return in Mixed Layer 2/Layer 3 Environment 5. Select Disabled next to Direct Server Return. 6. Click OK. Configure the service group 1. Select Config > Service > SLB. 2. On the menu bar, select Service Group. 3. Click on the service group name or click Add to create a new one. 4. If this is a new service group, enter the name. 5. 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. b. Enter the protocol port number in the Port field. c. Select the port template for the backup server from the Server Port Template drop-down list. This is the template configured in “Configure a port template to enable destination NAT on the backup server’s port” on page 102. d. Leave 1 selected in the Priority drop-down list. e. Click Add. 7. Click OK.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

103 of 960

AX Series - Configuration Guide Direct Server Return in Mixed Layer 2/Layer 3 Environment FIGURE 30

Config > Service > SLB > Template > Server Port

FIGURE 31

Config > Service > SLB > Service Group

To set the priority values of the primary servers to a higher value than the backup server, re-add the for the primary servers’ ports, and use the priority option. Set the priority to a value higher than 1 (the default). Use the same priority value on each of the primary server’s member ports.

104 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Direct Server Return in Mixed Layer 2/Layer 3 Environment 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 to the service group: AX(config)#slb service-group sg-dsr t 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

105 of 960

AX Series - Configuration Guide Direct Server Return in Mixed Layer 2/Layer 3 Environment

106 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide for Multiple OSPFv2 Processes and OSPFv3 Instances

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

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

for Multiple OSPFv2 Processes and OSPFv3 Instances AX Release 2.4.3 s 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.

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 AX Release 2.4.3 includes for the following OSPF MIBs: • RFC 1850 – OSPFv2 Management Information Base • draft-ietf-ospf-ospfv3-mib-08 – OSPFv3 Management Information Base P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

107 of 960

AX Series - Configuration Guide Configuration Example

Configuration Example The configuration excerpts in this example configure OSPFv2 and OSPFv3 on an AX device.

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

The following commands configure two Virtual Ethernet (VE) interfaces. On VE 3, an IPv4 address is configured. On VE 4, an IPv4 address and an IPv6 address are configured. OSPFv2 authentication is configured on VE 3, and the OSPF cost is set to 20. On VE 4, the OSPF cost is set to 15. interface ve 3 ip address 1.1.1.2 255.255.255.0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 abc ip ospf cost 20 !

108 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Example interface ve 4 ip address 1.1.60.2 255.255.255.0 ipv6 address 5f00:1:1:60::2/64 ip ospf cost 15

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

The following commands configure global settings for OSPFv3 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

109 of 960

AX Series - Configuration Guide Configuration Example

OSPF Logging Router logging is disabled by default. You can enable router logging to one or more of the following destinations: • CLI terminal (stdout) • Local logging buffer • Local file • External log servers

Note:

Log file settings are retained across reboots but debug settings are not.

Note:

Enabling debug settings that produce lots of output, or enabling all debug settings, is not recommend for normal operation.

Configuring Router Logging for OSPF To configure router logging for OSPF: 1. Enable output options. 2. Set severity level and facility. 3. Enable debug options to generate output. For additional syntax information, including show and clear commands for router logging, see the AX Series CLI Reference. 1. Enable output options: To enable output to the terminal, use the following command at the global configuration level of the CLI: router log stdout To enable output to the local logging buffer, use the following command at the global configuration level of the CLI: router log syslog To enable output to a local file, use the following command at the global configuration level of the CLI:

110 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Example [no] router log file { name string | per-protocol | rotate num | size Mbytes } To enable output to a remote log server, use the following command at the global configuration level of the CLI: logging host ipaddr [ipaddr...] [port protocol-port] Up to 10 remote logging servers are ed. 2. Set severity level and facility: The default severity level for router logging is 7 (debugging). The default facility is local0. To change set the severity level for messages output to the terminal, use the following command at the global configuration level of the CLI: logging monitor severity-level The severity-level can be one of the following: • 0 or emergency • 1 or alert • 2 or critical • 3 or error • 4 or warning • 5 or notification • 6 or information • 7 or debugging

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

111 of 960

AX Series - Configuration Guide Configuration Example To change the severity level for messages output to a file, use the following command at the global configuration level of the CLI: router log trap severity-level To change the facility, use the following command at the global configuration level of the CLI: logging facility facility-name The facility-name can be one of the following: • local0 • local1 • local2 • local3 • local4 • local5 • local6 • local7

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

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

(NFSM).

112 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Example • nsm – Enables debugging for the Network Services Module (NSM).

The NSM deals with use of ACLs, route maps, interfaces, and other network parameters. • packet – Enables debugging for OSPF packets. • route – Enables debugging for OSPF routes.

For each level, both debug commands are required. CLI Example The following commands configure OSPFv2 logging to a local file. AX(config)#router log file name ospf-log AX(config)#router log file per-protocol AX(config)#router log file size 100 AX(config)#debug a10 ospf all AX(config)#debug ospf packet

These commands create a router log file named “ospf-log”. The per-protocol option will log messages for each routing protocol separately. The log file will hold a maximum 100 MB of data, after which the messages will be saved in a backup and the log file will be cleared. The following command displays the contents of the local router log file: AX(config)#show router log file ospfd 2010/04/21 09:57:20 OSPF: IFSM[ve 3:1.1.1.2]: Hello timer expire 2010/04/21 09:57:20 OSPF: SEND[Hello]: To 224.0.0.5 via ve 3:1.1.1.2, length 64 2010/04/21 09:57:20 OSPF: ----------------------------------------------------2010/04/21 09:57:20 OSPF: Header 2010/04/21 09:57:20 OSPF:

Version 2

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

Type 1 (Hello)

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

Packet Len 48

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

Router ID 2.2.2.2

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

Area ID 0.0.0.0

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

Checksum 0x0

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

Instance ID 0

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

AuType 2

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

Cryptographic Authentication

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

Key ID 1

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

113 of 960

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

Auth Data Len 16

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

Sequence number 1271830931

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

NetworkMask 255.255.255.0

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

HelloInterval 10

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

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

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

RtrPriority 1

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

RtrDeadInterval 40

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

DRouter 1.1.1.200

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

BDRouter 1.1.1.2

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

# Neighbors 1

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

Neighbor 31.31.31.31

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

Version 2

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

Type 1 (Hello)

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

Packet Len 48

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

Router ID 2.2.2.2

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

Area ID 0.0.0.0

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

Checksum 0x49eb

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

Instance ID 0

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

AuType 0

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

NetworkMask 255.255.255.0

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

HelloInterval 10

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

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

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

RtrPriority 1

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

RtrDeadInterval 40

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

DRouter 3.3.3.2

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

BDRouter 3.3.3.1

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

# Neighbors 1

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

Neighbor 81.81.81.81

...

114 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

HTTP Load Balancing This chapter describes HTTP load balancing and how to configure it. Fast-HTTP is optimized for very high performance information transfer in comparison to regular HTTP. Due to this optimization, fast-HTTP does not all the comprehensive capabilities of HTTP such as header insertion and manipulation. It is recommended not to use fast-HTTP for applications that require compete data transfer integrity.

Note:

Overview HTTP load balancing manages HTTP traffic across a Web server farm. Figure 32 shows an example of an HTTP load balancing deployment. Note:

P e r f o r m a n c e

b y

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

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

115 of 960

AX Series - Configuration Guide Overview FIGURE 32

HTTP Load Balancing

In this example, a server farm consisting of three servers provides content for Web site www.example.com. Clients access the site through its virtual IP address, 192.168.10.11. When the AX device receives a client request for the HTTP port (80) on 192.168.10.11, the AX device selects a real server and sends the client request to the server. For simplicity in this example, the real servers use the default protocol port number for HTTP (80). The port numbers on the real and virtual servers are not required to match. The client is unaware of the real IP address of the real server, nor is the 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 client’s perspective, the Web session is between the client and port 80 on 192.168.10.11.

116 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

SERVICE GROUPS A service group contains a set of real servers from which the AX device can select to service a client request. This example uses a single service group that contains all the real servers and the applicable service port (80). During configuration, you bind the 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 s the following service types for HTTP ports: • HTTP – Complete T stack. Use this service type if you plan to cus-

tomize any templates. For example, if you plan to use SSL (HTTPS load balancing or SSL offload), or customize the HTTP template to change information in the HTTP headers of server replies, use the HTTP service type. Also use this service type for stream-based applications such as RAM Caching and compression. • Fast-HTTP – Streamlined hybrid stack for high performance. If you do

not plan to offload SSL or customize any templates, use Fast-HTTP. (For a complete list of the service types, see “Virtual Service Port Parameters” on page 887.)

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

117 of 960

AX Series - Configuration Guide Overview 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 829.) Service Templates For HTTP, the AX configuration applies “default” templates of each of the following template types to HTTP service ports: • T-Proxy – T-proxy templates control T stack settings, includ-

ing the idle timeout for T connections. Unless you need to change the setting for a T/IP stack parameter, you can safely allow the AX device to apply the default T-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 T 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 617.) 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.

118 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview (For an example that uses a source-IP persistence template, see “Layer 4 T/UDP Load Balancing” on page 261.) Server and Port Templates The AX device uses templates for configuration of some commonly used server and port parameters. By default, the following templates are applied: • Default server template – Contains configuration parameters for real

servers • Default port template – Contains configuration parameters for real ser-

vice ports • Default virtual-server template – Contains configuration parameters for

virtual servers • Default virtual-port template – Contains configuration parameters for

virtual service ports Each of the default templates is named “default”. For more information about server and port templates, see the following: • “Server and Port Templates” on page 361 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

HEALTH MONITORS This example uses the following types of health monitors to check the real servers: • Ping – A Layer 3 health method that sends an ICMP echo request to the

real server’s IP address. The server es the health check if the AX device receives a ping reply. • T – By default, every 30 seconds the AX device sends a connection

request (T SYN) to each load balanced T port on each server, in this case ports 80 and 443. A T port es the health check if the server replies to the AX device by sending a T SYN ACK. By default, the AX device completes the T 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

119 of 960

AX Series - Configuration Guide Configuring HTTP Load Balancing • Every 30 seconds, the AX device sends an HTTP GET request for the

default index page. • The HTTP service port es 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 381.)

Configuring HTTP Load Balancing To configure the HTTP load balancing solution described in “Overview” on page 115, perform the following tasks on the AX device: 1. Configure an HTTP health monitor. 2. Configure the real servers. On each real server: • Add the HTTP service port. • Enable the HTTP health monitor.

3. Configure the service group. Add the real servers and service ports to the group. 4. Configure the virtual server: • Add the HTTP service port, with service type Fast-HTTP. • Bind the service group to the virtual port.

USING THE GUI To configure an HTTP health method 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.

120 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTP Load Balancing 6. Optionally, select or enter additional options for the health monitor. (See “Health Monitoring” on page 381.) In this example, you can use all the default settings 7. Click OK. The new monitor appears in the health monitor table. FIGURE 33

Config > Service > Health Monitor > Health Monitor

To configure the real servers Perform the following procedure separately for each real server. 1. Select Config > Service > SLB. 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. Note:

P e r f o r m a n c e

b y

Enter the server’s real address, not the virtual server IP address.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

121 of 960

AX Series - Configuration Guide Configuring HTTP Load Balancing 6. In the Health Monitor drop-down list, select ping or leave the monitor unset. Note:

If you leave the monitor unset, the Layer 3 health monitor that comes in the AX configuration by default is used. (See “Default Health Checks” on page 381.) 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 120. 9. Click Add. The port appears in the port list. 10. Click OK. The real server appears in the server table. FIGURE 34

122 of 960

Config > Service > SLB > Server

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTP Load Balancing FIGURE 35

Config > Service > SLB > Server (real servers added)

The AX device begins sending health checks to a real server’s IP address and service ports as soon as you finish configuring the server. The overall health status for the server is shown in the Health column. If the status is

Note:

Down ( ) instead of Up ( ), that health monitors are configured for all the service ports. The default Layer 3 health method is automatically 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

123 of 960

AX Series - Configuration Guide Configuring HTTP Load Balancing FIGURE 36

124 of 960

Config > Service > SLB > Service Group

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTP Load Balancing 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

125 of 960

AX Series - Configuration Guide Configuring HTTP Load Balancing

126 of 960

FIGURE 37

Config > Service > SLB > Virtual Server

FIGURE 38 section

Config > Service > SLB > Virtual Server - Virtual Server Port

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTP Load Balancing

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 t 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 t 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:

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

127 of 960

AX Series - Configuration Guide Configuring HTTP Load Balancing 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)#port 80 t AX(config-real server-node port)#health-check http-hmon AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server web-3 10.10.10.3 AX(config-real server)#port 80 t AX(config-real server-node port)#health-check http-hmon AX(config-real server-node port)#exit

128 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTP Load Balancing AX(config-real server)#exit AX(config)#slb server web-4 10.10.10.4 AX(config-real server)#port 80 t AX(config-real server-node port)#health-check http-hmon AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure the service group: AX(config)#slb service-group sg-web t AX(config-slb service group)#member web-2:80 AX(config-slb service group)#member web-3:80 AX(config-slb service group)#member web-4:80 AX(config-slb service group)#exit

The following commands configure the virtual server: AX(config)#slb virtual-server web-vip 192.168.10.11 AX(config-slb virtual server)#port 80 fast-http AX(config-slb virtual server-slb virtua...)#service-group sg-web AX(config-slb virtual server-slb virtua...)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

129 of 960

AX Series - Configuration Guide Configuring HTTP Load Balancing

130 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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. HTTP templates can be used with the following service (virtual port) types: • HTTP • HTTPS • Fast-HTTP

Fast-HTTP is optimized for very high performance information transfer in comparison to regular HTTP. Due to this optimization, fast-HTTP does not all the comprehensive capabilities of HTTP such as header insertion and manipulation. It is recommended not to use fast-HTTP for applications that require compete data transfer integrity.

Note:

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

131 of 960

AX Series - Configuration Guide Overview • URL / host switching – Selects a service group based on the URL path

or domain in the client’s GET request. (See “URL / Host Switching” on page 139.) • 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 147.) • 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 149.) • 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 rebalancing of server selection. (See “Strict Transaction Switching” on page 167.) 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 U-intensive compression tasks. (See “Content Compression” on page 150.) Options that Modify HTTP Requests • Client IP insertion – Inserts the client’s IP address into GET requests

before sending the requests to a real server. The address is added as a value to the X-ClientIP field by default. Optionally, you can add the client address to a different field instead; for example: X-Forwarded-For. (See “Client IP Insertion / Replacement” on page 157.) • Header insertion / erasure – Inserts a field:value pair into requests or

responses, or deletes a header. (See “Header Insertion / Erasure” on page 160.) 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 165.)

132 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

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:

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: 1. Select Config > Service > SLB. 2. Select Virtual Server on the menu bar. 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

133 of 960

AX Series - Configuration Guide URL Hash Switching 6. Make sure the port type is HTTP, Fast-HTTP, or HTTPS. 7. In the HTTP Template drop-down list, select the HTTP template. 8. Configure other options if needed. (For example, if you are configuring a new port, make sure to select the service group.) 9. Click OK. The port appears in the Port list of the Port section. 10. Click OK. The virtual server list reappears.

USING THE CLI To configure an HTTP template, enter the following command at the global configuration level of the CLI: slb template http template-name This command changes the CLI to the configuration level for the template. The remaining sections in this chapter describe the commands for 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.

134 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 asg 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

135 of 960

AX Series - Configuration Guide 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 server’s load status from the server. Server Configuration This feature requires some custom configuration on the server. The server must be configured to insert an HTTP header named “Server-Status” in the server’s responses. The header must have one of the following values: 0, 1, or 2. Server-Status: load=N The value N can be 0, 1, or 2. The AX device manages requests to the server based on the Server-Status code. Table 4 describes the valid load status codes that can be reported by a server.

136 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide URL Hash Switching TABLE 4

Server-Status Load Values

Load Status Reported by Server 0

1

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.

2

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 server’s requests. Note: If no other servers are able to help, all servers in the service group are pulled in to help. Requests will be sent round-robin among the busy servers. For example, if there are 3 servers, and s1 returns status 2, s2 returns 1, and s3 returns 0, then the traffic is sent round-robin between s1 and s3. However, if s3 returns 1 or 2, then the traffic is sent round-robin among all 3 servers.

The system conditions that result in reporting 0, 1, or 2 depend on how you program calculation of the code. For example, you can program the server to set the Server-Status code based on U utilization, memory utilization, I/O utilization, and so on. For a U-intensive application, you could calculate the Server-Status code based on U 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

137 of 960

AX Series - Configuration Guide URL Hash Switching TABLE 5

Server-Status Load-Balancing Example

Server S1 S2 S3 S1 S2 S3 S1 S2 S3

Load Status Reported by Server 0 0 0 2 0 0 2 1 or 2 0

AX Action New requests for /article-new1 are sent only to server S1.

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

138 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide URL / Host Switching 5. If you plan to use the server load awareness option, select the Use Server Status checkbox. 6. Click OK.

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 135. 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)#port 80 http 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

URL / Host Switching The AX device s multiple service groups. URL / host switching enables an AX device to select a service group based on the URL or domain name in a client’s GET request. The selection overrides the service group configured on the virtual port. You can configure an HTTP template with one of the following servicegroup switching options: • URL switching – Selects a service group based on the URL path in the

GET line of the HTTP request’s header

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

139 of 960

AX Series - Configuration Guide URL / Host Switching • Host switching – Selects a service group based on the domain name in

the Host field of the HTTP request’s header Note:

If you plan to use URL / host switching along with cookie persistence, you must enable the match-type service-group option in the cookie persistence template. (See “Using URL / Host Switching along with Cookie Persistence” on page 143.) 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.

140 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide URL / Host Switching 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. An HTTP template can be configured with only one type of service-group switching, URL switching or host switching. However, if you need to use both types of switching, you can do so with an aFleX script.

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

141 of 960

AX Series - Configuration Guide URL / Host Switching

Configuring URL / Host Switching The following sections show how to configure URL / host switching.

USING THE GUI 1. Access the configuration sections for the template. (See “HTTP Template Configuration” on page 133.) 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

142 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide URL / Host Switching host-switching {starts-with |contains | ends-with} host-string service-group service-group-name CLI Example The following commands implement the URL switching configuration shown in Figure 40 on page 140. 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 AX(config-HTTP template)#exit

The following commands bind the HTTP template and service group sg-abc to virtual port 80: AX(config)#slb virtual-server vs1 1.1.1.1 AX(config-slb virtual server)#port 80 http 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 vs1 1.1.1.1 AX(config-slb virtual server)#port 80 http 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 s use of URL / host switching and cookie persistence in the same SLB configuration. However, to enable this , 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

143 of 960

AX Series - Configuration Guide URL / Host Switching 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.

144 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide URL / Host Switching • If the client’s request does not have a persistence cookie that includes

the selected service group, the AX device uses SLB to select a server, then inserts a persistence cookie into the reply from the server. The cookie includes the service group name. • If the client’s request already has a persistence cookie containing the

name of the selected service group, the AX device uses the information in the cookie to select the same server within the service group. For example, the first time service group sgabc is selected by URL 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 server’s reply, to ensure that the same server is used the next time URL switching selects sg123. Even though URL switching does not always select the same service group, the same server within the selected service group is always selected. Cookie Persistence Match-Type Options When cookie persistence is configured, the AX device adds a persistence cookie to the server reply before sending the reply to the client. The client’s browser re-inserts the cookie into each request. The format of the cookie depends on the match-type setting: • match-type (port) – This is the default setting. Subsequent requests

from the client will be sent to the same real port on the same real server. URL switching or host switching is used only for the first request. The cookie that the AX device inserts into the server reply has the 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. The cookie that the AX device inserts into the server reply has the following format: Set-Cookie: cookiename=rserverIP P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

145 of 960

AX Series - Configuration Guide URL / Host Switching • 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. The cookie that the AX device inserts into the server reply has the following format: Set-Cookie: cookiename-vport-servicegroupname=rserverIP_rport • match-type server service-group – Subsequent requests from the cli-

ent for the same VIP will be sent to the same real server, within the service group selected by URL switching or host switching. URL switching or host switching is still used for every request. The cookie that the AX device inserts into the server reply has the following format: Set-Cookie: cookiename-servicegroupname=rserverIP Note:

For security, address information in the persistence cookies is encrypted.

USING THE CLI To enable the service-group option, use the following command at the 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 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

146 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 shows an example. FIGURE 42

P e r f o r m a n c e

b y

URL Failover

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

147 of 960

AX Series - Configuration Guide 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 165.)

Configuring URL Failover The following sections show how to configure URL failover.

USING THE GUI 1. Access the configuration sections for the template. (See “HTTP Template Configuration” on page 133.) 2. In the URL Failover field of the HTTP section, enter the URL to which to redirect clients. 3. Click OK. The HTTP template list reappears.

USING THE CLI Enter the following command at the configuration level for the HTTP template: failover-url url-string CLI Example The following commands implement the URL failover configuration shown in Figure 42 on page 147. The following commands configure the HTTP template: AX(config)#slb template http urlfailover AX(config-HTTP template)#failover-url www.example2.com AX(config-HTTP template)#exit

148 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

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

5xx Retry and Reassignment By default, if a real server replies to a request with a 5xx status code (for example, HTTP 503 – Service Unavailable), the AX device forwards the error to the client. HTTP templates have an option to override this behavior. You can configure the AX device to retry sending a client’s request to a service port that replies with an HTTP 5xx status code, and reassign the request to another server if the first server replies with a 5xx status code. The AX device is allowed to reassign the request up to the configured number of retries. For example, assume that a service group has three (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 167.)

Note:

This option is ed only for virtual port types HTTP and HTTPS. It is not ed 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

149 of 960

AX Series - Configuration Guide 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 asg 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 client’s request with a 5xx status code. The AX device stops using the service port and server for 30 seconds following reassignment. AX(config)#slb template http 5xxretry AX(config-HTTP)#strict-transaction-switch AX(config-HTTP)#retry-on-5xx

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

150 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Content Compression Compression is ed only for HTTP and HTTPS virtual ports. Compression is not ed 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 client’s request contains the Accept-Encoding field with the “compress” value for the requested content type. By default, when you enable compression on the AX device, the device removes the entire Accept-Encoding field from the request before sending the request to the server. As a result, the server does not compress the 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 s 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 U 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:

P e r f o r m a n c e

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 11/3/2010

151 of 960

AX Series - Configuration Guide 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 ed. 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:

152 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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:

P e r f o r m a n c e

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 11/3/2010

153 of 960

AX Series - Configuration Guide 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 133.) 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 s 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:

154 of 960

If the Hardware Compression option is not present, your AX device does not contain a compression module.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

155 of 960

AX Series - Configuration Guide Content Compression To display compression statistics, use the following command: show slb http-proxy [detail] To enable hardware-based compression (if ed 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

156 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

0

last failure code

0

compression queue full

0

max queued request count 84 max queued submit count

68

Client IP Insertion / Replacement 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 616.) However, in configurations where IP source NAT is enabled for SLB, the client’s IP address is not the source IP address in the request received by the real server. Instead, the source IP address of the request is the address into which the AX device translated the client’s IP address. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

157 of 960

AX Series - Configuration Guide Client IP Insertion / Replacement To add the client’s IP address back to the request, you do not need to change the network configuration or NAT settings. Instead, you can simply enable the AX device to insert the client’s IP address into the header of the client’s GET request before sending the request to a real server. Figure 44 shows an example of client IP insertion. FIGURE 44

158 of 960

Client IP Insertion

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Client IP Insertion / Replacement In this example, SLB source NAT changes the source address of the client’s GET request from 192.168.100.3 to 10.20.20.11. However, the client’s source IP address is preserved within the HTTP header of the request, by inserting the address into the X-ClientIP field. This option inserts the client’s IP address into the X-ClientIP field by default. However, you can specify another field name instead. For example, you can configure the option to insert the client IP address into the X-Forwarded-For field. To insert HTTP header fields with other types of values, or to erase fields, see “Header Insertion / Erasure” on page 160.

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 1. Access the configuration sections for the template. (See “HTTP Template Configuration” on page 133.) 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

159 of 960

AX Series - Configuration Guide 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). 5. Click OK. The HTTP template list reappears.

USING THE CLI Enter the following command at the configuration level for the HTTP template: insert-client-ip [http-fieldname] [replace] The http-fieldname option specifies the HTTP field, for example: X-Forwarded-For. Without this option, the client IP address is inserted into the X-ClientIP field. The replace option replaces any client addresses that are already in the header. CLI Example The following commands implement the client IP insertion configuration shown in Figure 44 on page 158. The following commands configure the HTTP template: AX(config)#slb template http insertclientip AX(config-HTTP template)#insert-client-ip AX(config-HTTP template)#exit

The following commands bind the HTTP template to virtual port 80: AX(config)#slb virtual-server vs1 1.1.1.1 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#template http insertclientip

Header Insertion / Erasure 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.

160 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Header Insertion / Erasure Note:

The header insert, replace, and erase options described in this section are not ed with the fast-http service type. The AX device does not allow an HTTP template with any of these header options to be bound to a fast-http virtual port. Likewise, the AX device does not allow any of the header options to be added to an HTTP template that is already bound to a fast-http virtual port.

Note:

To configure the AX device to insert the client’s IP address, see “Client IP Insertion / Replacement” on page 157.

Note:

Header insertion is not ed on fast-HTTP virtual ports.

Configuring Header Insertion / Replacement To configure header insertion or replacement, specify the header (the field:value pair), and the insert or replace option. The insert / replace option can be one of the following: • Insert-always – always inserts the field:value pair. If the request already

contains a header with the same field name, the new field:value pair is added after the existing field:value pair. Existing headers are not replaced. • Insert-if-not-exist – inserts the header only if the packet does not already

contain a header with the same field name. • Default behavior (neither of the options above) – inserts the header. If

the packet already contains one or more headers with the specified field name, this option replaces the last header. Effects of the Insert / Replace Options Here are some examples of the effects of the insert / replace options: insertalways, insert-if-not-exist, and the default (no options). For these examples, assume that a client’s request packet already contains the following Cookie headers: “Cookie: a=1” and “Cookie: b=2”. GET / HTTP/1.1 Host: www.example.com Cookie: a=1 Cookie: b=2 ...

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

161 of 960

AX Series - Configuration Guide Header Insertion / Erasure Effect When insert-always Is Used If you configure an HTTP template to insert “Cookie: c=3”, and you use the insert-always option, the client’s header is changed as follows: GET / HTTP/1.1 Host: www.example.com Cookie: a=1 Cookie: b=2 Cookie: c=3 ... Effect When insert-if-not-exist Is Used If you configure an HTTP template to insert “Cookie: c=3”, and you use the insert-if-not-exist option, the client’s header is changed only if it does not contain any “Cookie” headers. Therefore, the client request in this example is unchanged: GET / HTTP/1.1 Host: www.example.com 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 Host: www.example.com Cookie: c=3 Cookie: b=2 ...

USING THE GUI 1. Access the configuration sections for the template. (See “HTTP Template Configuration” on page 133.) 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-

162 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Header Insertion / Erasure 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. 5. Click OK. The HTTP template list reappears.

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]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

163 of 960

AX Series - Configuration Guide Header Insertion / Erasure 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 1. Access the configuration sections for the template. (See “HTTP Template Configuration” on page 133.) 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. 5. Click OK. The HTTP template list reappears.

164 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

URL Redirect Rewrite 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:

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

165 of 960

AX Series - Configuration Guide URL Redirect Rewrite 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 1. Access the configuration sections for the template. (See “HTTP Template Configuration” on page 133.) 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 t-portnum} The default SSL port number (t-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.

166 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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-HTTP template)#exit

The following commands bind the HTTP template to virtual port 80: AX(config)#slb virtual-server vs1 1.1.1.1 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#template http secureredirect

Strict Transaction Switching By default, the AX device performs server selection once for a client 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:

P e r f o r m a n c e

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 11/3/2010

167 of 960

AX Series - Configuration Guide Strict Transaction Switching

Enabling Strict Transaction Switching The following sections show how to enable strict transaction switching.

USING THE GUI 1. Access the configuration sections for the template. (See “HTTP Template Configuration” on page 133.) 2. In the HTTP section, select Enabled next to Strict Transaction Switch. 3. Click OK. The HTTP template list reappears.

USING THE CLI To enable strict transaction switching, enter the following command at the configuration level for the HTTP template: strict-transaction-switch

168 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

FTP Load Balancing This chapter describes how to configure SLB for FTP services.

Overview FTP load balancing optimizes the 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

P e r f o r m a n c e

b y

FTP Load Balancing

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

169 of 960

AX Series - Configuration Guide Overview In this example, FTP files are served by three real servers. Each server has the same set of files available for . One of the servers also provides the HTML pages for the site. The AX device s both the ive 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 asg 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 T templates are required. • For HTTP, the default T 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 T port on a virtual server when you create the port, unless you explicitly bind another T template to the virtual port instead. • For FTP, a custom T template is required, with the idle time set to a

high value, to prevent FTP sessions from timing out if they pause for a while. This custom T 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 T 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.

170 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing For more information about templates, see the following: • “Service Template Parameters” on page 829 • “Server and Port Templates” on page 361

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 request to the port. In this

example, the default settings are used: Every 30 seconds, the AX device sends an anonymous FTP 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 T and UDP transport layers. This configuration also uses those health checks. (For information, see “Default Health Checks” on page 381.)

Configuring FTP Load Balancing To configure FTP load balancing: 1. Configure HTTP and FTP health methods, to use for checking the health of the HTTP and FTP ports on the servers. 2. Configure the real servers: a. For each server, add its FTP port and enable health checking of the port, using the FTP health method configured in step 1. b. For the server that will serve the Web pages, add the server’s HTTP port and enable health checking of the port, using the HTTP health method configured in step 1.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

171 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing 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 T 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 T 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 T template.

USING THE GUI To configure the health monitors 1. Select Config > Service > Health Monitor. 2. Click Add. 3. In the Health Monitor section, enter a name for the monitor in the Name field. 4. Click Method. 5. In the Method section, select HTTP from the Type drop-down list. 6. Click OK. The new health monitor appears in the health monitor table. 7. Repeat step 2 through step 6 to configure the FTP health monitor. In step 5, select FTP instead of HTTP.

172 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing

P e r f o r m a n c e

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 11/3/2010

173 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing FIGURE 48 monitors)

Config > Service > Health Monitor (showing configured health

To configure the real servers 1. Select Config > Service > SLB. 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 T. 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 172. (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.

174 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing FIGURE 49

P e r f o r m a n c e

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 11/3/2010

175 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing FIGURE 50

176 of 960

Config > Service > SLB > Server (ftp-3)

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing FIGURE 51

Config > Service > SLB > Server (ftp-4)

FIGURE 52 servers)

Config > Service > SLB > Server (showing configured real

Note:

P e r f o r m a n c e

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 11/3/2010

177 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing To configure the T template for FTP 1. Select Config > Service > Template. 2. Select L4 > T 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 T template table. FIGURE 53

Config > Service > Template > L4 > T

To configure a service group for HTTP 1. Select Config > Service > SLB. 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 T. 6. In the Algorithm field, select the load balancing method. For this example, select Weighted Round Robin. 7. Enter the real server’s IP address in the Server field. 8. Enter the protocol port in the Port field.

178 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing 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 178, 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 10.10.10.2-4 for port 21.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

179 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing

180 of 960

FIGURE 55

Config > Service > Service Group (for FTP)

FIGURE 56

Config > Service > Service Group (service groups added)

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing To configure the virtual server 1. Select Config > Service > SLB. 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 T template you configured in “To configure the T template for FTP” on page 178. 12. Click OK. The new virtual server appears in the virtual server table.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

181 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing

182 of 960

FIGURE 57

Config > Service > Virtual Server

FIGURE 58 (for HTTP)

Config > Service > Virtual Server - Virtual Server Port section

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing

P e r f o r m a n c e

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 11/3/2010

183 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing

USING THE CLI 1. To configure the health monitors, use the following commands: health monitor monitor-name 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.) 2. To configure the real servers, use the following commands: slb server server-name ipaddr 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 t The port command adds a T 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. health-check monitor-name 3. To configure the T template for FTP, use the following commands: slb template t template-name This command creates the T template and changes the CLI to the configuration level for the template. idle-timeout seconds

184 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing The idle-timeout command specifies the number of seconds a T 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: slb service-group group-name t This command creates the service group and changes the CLI to the configuration level for it. member server-name:portnum 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: slb service-group group-name t This command creates the service group and changes the CLI to the configuration level for it. member server-name:portnum 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: slb virtual-server name ipaddr 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: service-group group-name template t template-name

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

185 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing The service-group command binds the virtual port to a service group. The template t command binds the virtual port to a T 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)#exit AX(config)#health monitor ftp-monitor AX(config-health:monitor)#method ftp AX(config-health:monitor)#exit

The following commands configure the real servers: AX(config)#slb server ftp-2 10.10.10.2 AX(config-real server)#weight 80 AX(config-real server)#port 8801 t AX(config-real server-node port)#health-check http-monitor AX(config-real server-node port)#exit AX(config-real server)#port 21 t AX(config-real server-node port)#health-check ftp-monitor AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server ftp-3 10.10.10.3 AX(config-real server)#weight 100 AX(config-real server)#port 21 t AX(config-real server-node port)#health-check ftp-monitor AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server ftp-4 10.10.10.4 AX(config-real server)#weight 100 AX(config-real server)#port 21 t AX(config-real server-node port)#health-check ftp-monitor AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure the T template for use with FTP: AX(config)#slb template t ftp-longidletime AX(config-L4 T LB template)#idle-timeout 15000 AX(config-L4 T LB template)#exit

186 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FTP Load Balancing The following commands configure the service group for HTTP: AX(config)#slb service-group http-grp t AX(config-slb service group)#member ftp-2:8801 AX(config-slb service group)#exit

The following commands configure the service group for FTP: AX(config)#slb service-group ftp-grp t AX(config-slb service group)#member ftp-2:21 AX(config-slb service group)#member ftp-3:21 AX(config-slb service group)#member ftp-4:21 AX(config-slb service group)#method weighted-rr AX(config-slb service group)#exit

The following commands configure the virtual server: AX(config)#slb virtual-server ftp-vip 192.168.10.21 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#service-group http-grp AX(config-slb virtual server-slb virtua...)#exit 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 t ftp-longidletime

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

187 of 960

AX Series - Configuration Guide Configuring FTP Load Balancing

188 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 T/TLS. IP source NAT is not ed on SIP virtual ports.

Note:

Load Balancing for SIP over UDP AX Series devices 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 190.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

189 of 960

AX Series - Configuration Guide Load Balancing for SIP over UDP 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.

190 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over UDP 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 to send a 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: a. Select Config > Service > SLB. b. Select Server on the menu bar. c. Click Add.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

191 of 960

AX Series - Configuration Guide Load Balancing for SIP over UDP 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.

192 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over UDP 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: a. Select Config > Service > SLB. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

193 of 960

AX Series - Configuration Guide Load Balancing for SIP over UDP

GUI CONFIGURATION EXAMPLE The following GUI examples show the configuration steps. FIGURE 63 Config > Service > Health Monitor > Health Monitor (example for Registrar servers)

194 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over UDP FIGURE 64 Config > Service > Health Monitor > Health Monitor (example for other SIP servers)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

195 of 960

AX Series - Configuration Guide Load Balancing for SIP over UDP

196 of 960

FIGURE 65

Config > Service > SLB > Server

FIGURE 66 added

Config > Service > SLB > Server - Registrar and Proxy servers

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over UDP

P e r f o r m a n c e

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 11/3/2010

197 of 960

AX Series - Configuration Guide Load Balancing for SIP over UDP

198 of 960

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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over UDP

USING THE CLI 1. To configure a SIP health monitor using the SIP health method, use the following commands: health monitor monitor-name Enter this command at the global Config level. method sip [ [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 request instead, use the 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: slb server server-name ipaddr Enter this command at the global Config level. port port-num udp Enter this command at the configuration level for the real server. health-check monitor-name 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 Enter this command at the global Config level. 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

199 of 960

AX Series - Configuration Guide Load Balancing for SIP over UDP Enter this command at the global Config level. registrar service-group group-name header-erase string header-insert string header-replace string new-string timeout minutes -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 -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 through the AX device. (See “Disabling Reverse NAT Based on Destination IP Address” on page 222.) 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: slb virtual-server name ipaddr Enter this command at the global Config level. port port-number sip Enter this command at the configuration level for the virtual server. service-group group-name template sip template-name Enter these commands at the configuration level for the virtual port.

200 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over UDP

CLI CONFIGURATION EXAMPLE The commands in the following example implement the SIP load balancing configuration shown in Figure 62 on page 190. 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 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-real server)#exit AX(config)#slb server Registrar2 10.10.10.57 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-real serverexit

The following commands configure the SIP proxy servers: AX(config)#slb server Proxy3 10.10.20.11 AX(config-real server)#port 5060 udp AX (config-real server-node port)#health-check sip_monitor AX (config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server Proxy4 10.10.20.12 AX(config-real server)#port 5060 udp AX (config-real server-node port)#health-check sip_monitor AX (config-real server-node port)#exit AX(config-real server)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

201 of 960

AX Series - Configuration Guide Load Balancing for SIP over UDP 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)#exit AX(config)#slb service-group sip5060 udp AX(config-slb service group)#member Proxy3:5060 AX(config-slb service group)#member Proxy4:5060 AX(config-slb service group)#exit

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

202 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS

Load Balancing for SIP over T/TLS SIP over T/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 T / 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 T. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

203 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS 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 client’s request before freeing the connection. Figure 75 shows an example. FIGURE 75

204 of 960

SIP Connection Reuse

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS 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 T is different from the operation of connection reuse for HTTP. For HTTP, the AX device does not free a connection after sending a client’s request. Instead, the AX device frees the connection only after receiving a response to the request.

Note:

AX Requirements for SIP Multiplexing In addition to the requirements for any SIP over T / 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 client’s request before forwarding the request to the SIP server. The header contains the client’s IP address and client port number. The AX device expects the server to send back this header, and uses the header to identify the client to which to send replies from the SIP server. • Server keepalive (described in “Client Keepalive and Server Keepalive”

on page 206) Client and Server Requirements for SIP Multiplexing In order for the AX device to be used as a multiplexer for SIP over T/ TLS, the clients and SIP servers must meet certain requirements: • The SIP clients must be able to send SIP pings. • The SIP server must be able to reply to SIP pings, with SIP pongs. • The SIP server must be able to include the X-Forward-For header added

to the client’s request by the AX device, in replies to the client.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

205 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS

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:

206 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS

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 T / TLS SLB Network Address Translation (NAT) is used for SIP over T / 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 server’s real IP address and SIP port to the VIP address and port, then sends the packet to the client. By default, the AX device also translates the client IP address and protocol port number where they are used in some other parts of the SIP packet. However, the AX device does not translate server addresses or protocol port numbers in the following headers: • Call-ID header • X-Forwarded-For header • Via headers, except for the top Via header

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

207 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS 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 T / TLS for SIP Multiplexing To configure an AX device for secure SIP multiplexing: • Optionally, configure a health monitor for SIP over T. • 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 T as the protocol type. Use a Layer 4 T health monitor. When you add the T port, the default T 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 T Clients, add a protocol port with service type “sip-t”. 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.

208 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS

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-T • SIP-TLS

Otherwise, the GUI procedures for creating the configuration items needed for SIP over T/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 204. FIGURE 77

P e r f o r m a n c e

b y

Config > Service > SLB > Server

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

209 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS FIGURE 78

210 of 960

Config > Service > SLB > Service Group

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS

P e r f o r m a n c e

FIGURE 79

Config > Service > Template > Application > SIP

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 11/3/2010

211 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS

212 of 960

FIGURE 81

Config > Service > SSL Management - import certificate

FIGURE 82

Config > Service > SSL Management - import key

FIGURE 83

Config > Service > Template > SSL > Client SSL

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS FIGURE 84

P e r f o r m a n c e

b y

Config > Service > SLB > Virtual Server - Virtual Server Port

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

213 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS 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 T 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 t

214 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS To Configure Real Servers Use the following commands: slb server server-name ipaddr Use this command at the global configuration level of the CLI. For the ipaddr, use the SIP server’s real IP address. This command changes the CLI to the configuration level for the server, where the following command is available: port port-num t 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 T health monitor to the port. To Configure a Service Group Use the following commands: slb service-group group-name t 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 T/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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

215 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS insert-client-ip This command inserts an “X-Forwarded-For: IP-address:port” header into SIP packets from the client to the SIP server. The header contains the client IP address and source protocol port number. The AX device uses the header to identify the client when forwarding a server reply. This option is disabled by default. client-keep-alive This command enables the AX device to respond to SIP pings from clients on behalf of SIP servers. When this option is enabled, the AX device responds to a SIP ping from a client with a “pong”. This option is disabled by default. Note:

If connection reuse is configured, even if client keepalive is disabled, the AX device will respond to a client SIP ping with a pong. server-keep-alive seconds This command specifies how often the AX device sends a SIP ping on each reusable connection with the SIP server. The AX device silently drops the server’s pong reply. If the server does not reply to a SIP ping within the connection-reuse 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:

216 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS • 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 T / TLS” on page 207.) 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 Use the following commands: 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

217 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS [no] slb ssl-load {certificate file-name | private-key file-name} [use-mgmt-port] url The use-mgmt-port option uses the AX device’s management route table and management port to communicate with the remote server. Without this option, the AX device uses the main route table and a data interface to communicate with the remote server. The url specifies the file transfer protocol (tftp:, ftp:, s:, or r:), name (if required), and directory path. You can enter the entire URL on the command line or press Enter to display a prompt for each part of the URL. If you enter the entire URL and a is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]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 the following commands: slb virtual-server name ipaddr 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-t Use the sips option to add a port for SIP over TLS clients. Use the sip-t option to add a port for SIP over T clients. This command changes the CLI to the configuration level for the virtual port, where the following commands are available:

218 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS service-group group-name 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 204, and show SIP SLB statistics. The following commands access the configuration level of the CLI and configure a SIP over T health monitor: AX>enable AX#config AX(config)#health monitor sip-over-t AX(config-health:monitor)#method sip t

The following commands configure the real servers: AX>enable AX#config AX(config)#slb server siptls-rs1 10.4.2.1 AX(config-real server)#port 5060 t AX(config-real server)#healthcheck sip-over-t AX(config-real server-node port)#exit AX(config-real server)#exit

AX(config)#slb server siptls-rs2 10.4.2.2 AX(config-real server)#port 5060 t AX(config-real server)#healthcheck sip-over-t AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure the service group: AX(config)#slb service-group siptls-sg t 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 AX(config-slb service group)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

219 of 960

AX Series - Configuration Guide Load Balancing for SIP over T/TLS 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 s: Address or name of remote host []?192.168.1.1 name []? []?********* File name [/]?ca-cert.pem AX(config)#slb ssl-load private-key ca-certkey.pem s: Address or name of remote host []?192.168.1.1 name []? []?********* File name [/]?ca-certkey.pem AX(config)#slb ssl-load certificate cert.pem s: Address or name of remote host []?192.168.1.1 name []? []?********* File name [/]?cert.pem AX(config)#slb ssl-load private-key certkey.pem s: Address or name of remote host []?192.168.1.1 name []? []?********* 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

220 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Load Balancing for SIP over T/TLS The following commands configure the virtual server: 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 U. Without this option, aggregate statistics are shown for all Us.

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

221 of 960

AX Series - Configuration Guide 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 through the AX device. Figure 86 shows an example. 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 through the AX device, the destination server will receive the traffic from the VIP address instead of the SIP server address. To disable reverse NAT in this type of situation: 1. Configure an extended ACL that matches on the SIP server IP address or subnet as the source address, and matches on the destination server’s IP address or subnet as the destination address.

222 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 1. Select Config > Service > Template. 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 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] -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 server’s subnet and on the database server’s subnet: AX(config)#access-list 101 permit ip 10.10.10.0 /24 10.20.20.0 /24

The following commands configure a SIP template that disables reverse NAT for traffic that matches the ACL: AX(config)#slb template sip sip1 AX(config-sip)#-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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

223 of 960

AX Series - Configuration Guide IP NAT for SIP

IP NAT for SIP The AX device s 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 ed. 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 ! interface ethernet 3 ip address 171.1.1.1 255.255.255.0 ip nat inside ! interface ethernet 5 ip address 2.2.2.1 255.255.255.0 ip nat outside ! ip nat pool xin 2.2.2.100 2.2.2.100 netmask /32 ip nat inside source list 1 pool xin

224 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 131. • SSL proxy – The AX device acts as a Layer 4 SSL proxy for T ser-

vices such as POPS, SMTPS, IMAPS, and LDAPS. SSL offload uses service type (virtual port type) HTTPS, and s 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 s STARTTLS acceleration and encryption. See “STARTTLS for Secure SMTP” on page 245.

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

225 of 960

AX Series - Configuration Guide Configuring Client SSL Implement SSL proxy if the following are true: • The traffic will be SSL-secured traffic over T, but not necessarily

HTTPS traffic. • Layer 7 features are not required.

Configuring Client SSL 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 915. 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, R, or S.

226 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Client SSL – 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 and fields, enter the name and 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 phrase, enter the phrase. h. Click OK. The new template appears in the Client SSL template table.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

227 of 960

AX Series - Configuration Guide Configuring Client SSL

GUI CONFIGURATION EXAMPLE The following GUI examples show the configuration steps. 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, name (if required), directory path, and filename.

228 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Client SSL 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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file 2. To configure a client SSL template, use the following commands: slb template client-ssl template-name Enter this command at the global Config level. cert cert-name Enter this command at the configuration level for the client SSL template. key key-name [phrase phrase-string]

CLI CONFIGURATION EXAMPLE 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: Address or name of remote host []?1.1.1.2 name []?ax []?********* File name [/]?sslcert1.crt AX(config)#slb ssl-load key sslcertkey.pem ftp: Address or name of remote host []?1.1.1.2 name []?ax []?********* 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 AX(config-client SSL template)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

229 of 960

AX Series - Configuration Guide Configuring HTTPS Offload

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 226.) 2. Configure the real servers for the T 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 131.) 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 ed. 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 U utilization, regardless of whether traffic is active on the virtual port.

USING THE GUI 1. To configure real servers: a. Select Config > Service > SLB. b. Select Server on the menu bar. 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 T, if not already selected.

230 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTPS Offload 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: a. Select Service Group on the menu bar. b. Click Add. c. On the Service Group tab, enter a name for the service group. d. In the Type drop-down list, select T, 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 131. 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

231 of 960

AX Series - Configuration Guide Configuring HTTPS Offload

GUI CONFIGURATION EXAMPLE The following GUI examples show the configuration steps. FIGURE 89

232 of 960

Configure > Service > SLB > Server

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTPS Offload FIGURE 90

P e r f o r m a n c e

b y

Configure > Service > SLB > Service Group

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

233 of 960

AX Series - Configuration Guide Configuring HTTPS Offload FIGURE 91

234 of 960

Configure > Service > SLB > Virtual Server

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring HTTPS Offload FIGURE 92

Configure > Service > SLB > Virtual Server - Port tab

USING THE CLI 1. To configure a real server, use the following commands: slb server server-name ipaddr Enter this command at the global Config level. port port-num t Enter this command at the configuration level for the real server. 2. To configure a service group for the servers and add them to the group, use the following commands: slb service-group group-name t Enter this command at the global Config level. member server-name [priority number] Enter this command at the configuration level for the service group. 3. To configure HTTP template options, see “HTTP Options for SLB” on page 131.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

235 of 960

AX Series - Configuration Guide Configuring HTTPS Offload 4. To configure a virtual server and HTTPS virtual port, use the following commands: slb virtual-server name ipaddr Enter this command at the global Config level. port port-number https Enter this command at the configuration level for the virtual server. service-group group-name template http template-name template client-ssl template-name Enter these commands at the configuration level for the virtual port to bind the port to the service group and the application templates.

CLI CONFIGURATION EXAMPLE 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. The following commands configure the real servers: AX(config)#slb server HTTPS1 10.5.5.2 AX(config-real server)#port 80 t AX (config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server HTTPS2 10.5.5.3 AX(config-real server)#port 80 t AX (config-real server-node port)# #exit AX(config-real server)#exit

The following commands configure a service group for the HTTPS servers: AX(config)#slb service-group HTTPS_servers t AX(config-slb service group)#member HTTPS1:80 AX(config-slb service group)#member HTTPS2:80 AX(config-slb service group)#exit

236 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

Configuring the SSL Proxy Feature To configure the AX device as an SSL proxy for a T service: 1. Configure client SSL. (See “Configuring Client SSL” on page 226.) 2. Configure the real servers for the T 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: a. Select Config > Service > SLB. b. Select Server on the menu bar. 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 T, 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: a. Select Service Group on the menu bar. b. Click Add. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

237 of 960

AX Series - Configuration Guide Configuring the SSL Proxy Feature c. On the Service Group tab, enter a name for the service group. d. In the Type drop-down list, select T, 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.

238 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring the SSL Proxy Feature

GUI CONFIGURATION EXAMPLE The following GUI examples show the configuration steps. FIGURE 93

P e r f o r m a n c e

b y

Configure > Service > SLB > Server

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

239 of 960

AX Series - Configuration Guide Configuring the SSL Proxy Feature FIGURE 94

240 of 960

Configure > Service > SLB > Service Group

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring the SSL Proxy Feature

P e r f o r m a n c e

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 11/3/2010

241 of 960

AX Series - Configuration Guide Configuring the SSL Proxy Feature

USING THE CLI 1. To configure a real server, use the following commands: slb server server-name ipaddr Enter this command at the global Config level. port port-num t Enter this command at the configuration level for the real server. 2. To configure a service group for the servers and add them to the group, use the following commands: slb service-group group-name t Enter this command at the global Config level. member server-name [priority number] Enter this command at the configuration level for the service group. 3. To configure a virtual server and port for the T service, use the following commands: slb virtual-server name ipaddr Enter this command at the global Config level. port port-number ssl-proxy Enter this command at the configuration level for the virtual server. service-group group-name template client-ssl template-name Enter these commands at the configuration level for the virtual port.

242 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring the SSL Proxy Feature

CLI CONFIGURATION EXAMPLE The following commands configure proxy SSL for POPS. The same commands can be used to configure SSL proxy for other T 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. The following commands configure the real servers: AX(config)#slb server POP1 10.5.5.2 AX(config-real server)#port 110 t AX (config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server POP2 10.5.5.3 AX(config-real server)#port 110 t AX (config-real server-node port)# #exit AX(config-real server)#exit

The following commands configure a service group for the POP servers: AX(config)#slb service-group POP_servers t AX(config-slb service group)#member POP1:110 AX(config-slb service group)#member POP2:110 AX(config-slb service group)#exit

The following commands configure the VIP to which clients will send POPS traffic: AX(config)#slb virtual-server v1 10.6.6.6 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

243 of 960

AX Series - Configuration Guide Configuring the SSL Proxy Feature

244 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 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

P e r f o r m a n c e

b y

STARTTLS

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

245 of 960

AX Series - Configuration Guide 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 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

246 of 960

STARTTLS Domain Switching

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring STARTTLS

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

247 of 960

AX Series - Configuration Guide Configuring STARTTLS

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 . (See “Configuring the SSL Proxy Feature” on page 237.) 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.

248 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring STARTTLS To configure a virtual server for STARTTLS (step 6 above): 1. Select Configure > Service > SLB. 2. Select Virtual Server on the menu bar. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

249 of 960

AX Series - Configuration Guide Configuring STARTTLS

GUI CONFIGURATION EXAMPLE The following GUI examples show the configuration steps. FIGURE 99

250 of 960

Config > Service > Template > Application > SMTP

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring STARTTLS 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, name (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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file 2. To configure a client SSL template, use the following commands: slb template client-ssl template-name P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

251 of 960

AX Series - Configuration Guide Configuring STARTTLS Enter this command at the global Config level. cert cert-name Enter this command at the configuration level for the client SSL template. key key-name [phrase phrase-string] 3. To configure a real server for an SMTP server, use the following commands: slb server server-name ipaddr Enter this command at the global Config level. port port-num t Enter this command at the configuration level for the real server. 4. To configure a service group for the SMTP servers and add them to the group, use the following commands: slb service-group group-name t Enter this command at the global Config level. member server-name [priority number] Enter this command at the configuration level for the service group. 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 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

252 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring STARTTLS SMTP and client SSL templates to the port, use the following commands: slb virtual-server name ipaddr Enter this command at the global Config level. port port-num smtp Enter this command at the configuration level for the virtual server. service-group group-name template smtp template-name template client-ssl template-name Enter these commands at the configuration level for the virtual port. 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]

CLI CONFIGURATION EXAMPLE The following commands implement the STARTTLS configuration shown in Figure 97 on page 245. To begin, the following commands import an SSL certificate and key: AX(config)#slb ssl-load certificate starttls.crt ftp: Address or name of remote host []?1.1.1.2 name []?ax []?********* File name [/]?starttls.crt AX(config)#slb ssl-load key tlscertkey.pem ftp: Address or name of remote host []?1.1.1.2 name []?ax []?********* File name [/]?tlscertkey.pem

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

253 of 960

AX Series - Configuration Guide Configuring STARTTLS 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 AX(config-client SSL template)#exit

The following commands configure the SMTP real servers: AX(config)#slb server SMTP1 10.1.1.2 AX(config-real server)#port 25 t AX (config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server SMTP2 10.1.1.3 AX(config-real server)#port 25 t AX (config-real server-node port)# #exit AX(config-real server)#exit

The following commands configure a service group for the SMTP servers: AX(config)#slb service-group SMTP_servers t AX(config-slb service group)#member SMTP1:25 AX(config-slb service group)#member SMTP2:25 AX(config-slb service group)#exit

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 v1 10.1.1.1 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

254 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Streaming-Media Load Balancing This chapter describes streaming-media load balancing and how to configure it.

Overview AX Series devices 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 s load balancing of Session Initiation Protocol (SIP) sessions. For information, see “SIP Load Balancing” on page 189.

Note:

Figure 101 shows an example of a streaming-media load balancing solution.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

255 of 960

AX Series - Configuration Guide Overview FIGURE 101

Streaming-Media Load Balancing

In this example, a server farm provides streaming content in both RTSP and MMS format. All the servers are allowed to serve HTTP and HTTPS requests. Two of the servers (stream-rs2 and stream-rs3) are configured to serve RTSP and MMS requests. Service Groups This example uses the following service groups: • all80-grp – The servers in this service group provide HTTP and HTTPS

service. In this example, all the servers are 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.

256 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 hip of the RTSP group can easily be edited to include only the RTSP servers, and so on.

Note:

Templates By default, the default T template is applied to RTSP and MMS traffic. (For information, see “T Template Parameters” on page 864.) Health Monitors This example uses the default Layer 3 health check (ping) and the default Layer 4 T health check.

Configuring Streaming-Media SLB 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 ed 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: 1. Select Config > Service > 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

257 of 960

AX Series - Configuration Guide Configuring Streaming-Media SLB When configuring the virtual server, select RTSP or MMS as the service port type.

USING THE CLI 1. To configure the real servers, use the following commands: slb server server-name ipaddr 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 t Available at the configuration level for the server, the port command adds a T 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: slb service-group group-name t This command creates the service group and changes the CLI to the configuration level for it. member server-name:portnum 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. 3. To configure the virtual server, use the following commands: slb virtual-server name ipaddr 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: service-group group-name The service-group command binds the virtual port to a service group.

258 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Streaming-Media SLB

CLI CONFIGURATION EXAMPLE The following commands configure the real servers: AX(config)#slb server stream-rs1 192.168.66.21 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server stream-rs2 192.168.66.22 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config-real server)#port 1755 t AX(config-real server-node port)#exit AX(config-real server)#port 554 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server stream-rs3 192.168.66.23 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#port 1755 t AX(config-real server-node port)#exit AX(config-real server)#port 554 t AX(config-real server-node port)#exit AX(config-real server)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

259 of 960

AX Series - Configuration Guide Configuring Streaming-Media SLB The following commands configure the service groups: AX(config)#slb service-group all80-grp t AX(config-slb service group)#member stream-rs1:80 AX(config-slb service group)#member stream-rs1:443 AX(config-slb service group)#member stream-rs2:80 AX(config-slb service group)#member stream-rs2:443 AX(config-slb service group)#member stream-rs3:80 AX(config-slb service group)#member stream-rs3:443 AX(config-slb service group)#exit AX(config)#slb service-group rtsp554-grp t AX(config-slb service group)#member stream-rs2:554 AX(config-slb service group)#member stream-rs3:554 AX(config-slb service group)#exit AX(config)#slb service-group mms1755-grp t AX(config-slb service group)#member stream-rs2:1755 AX(config-slb service group)#member stream-rs3:1755 AX(config-slb service group)#exit

The following commands configure the virtual server: AX(config)#slb virtual-server streaming-vip 192.168.69.4 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#service-group all80-grp AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#port 443 https AX(config-slb virtual server-slb virtua...)#service-group all80-grp AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#port 554 rtsp AX(config-slb virtual server-slb virtua...)#service-group rtsp554-grp AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#port 1755 mms AX(config-slb virtual server-slb virtua...)#service-group mms1755-grp AX(config-slb virtual server-slb virtua...)#exit

260 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Layer 4 T/UDP Load Balancing This chapter describes Layer 4 load balancing of T and UDP traffic and how to configure it. 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 (T, UDP, or other), see “IP Protocol Load Balancing” on page 269.

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 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 T or UDP load balancing for the service. Figure 102 shows an example of a Layer 4 load balancing implementation.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

261 of 960

AX Series - Configuration Guide Overview FIGURE 102

Layer 4 SLB

Layer 4 load balancing balances traffic based on the transport protocol (T or UDP) and the protocol port number. The payload of the UDP or T 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).

262 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

VIRTUAL SERVER The custom application on the real servers is accessed at T port 1020 by clients through virtual IP address 192.168.55.55.

TEMPLATES The AX device has default T and UDP templates. You can use the default template or configure another T or UDP template and use that one instead. If your Layer 4 load balancing configuration is for a T application and you do not bind a T template to the virtual port, the default T 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 T 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 T and UDP templates, see the following sections: • “T Template Parameters” on page 864 • “UDP Template Parameters” on page 867

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

263 of 960

AX Series - Configuration Guide 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 (T 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 381.

Configuring Layer 4 Load Balancing To configure Layer 4 load balancing: 1. Configure the real servers. Add the custom application’s T or UDP port number, with the applicable service type (T 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 T 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: a. Select Config > Service > SLB. b. Select Server on the menu bar. 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, T 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.

264 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 4 Load Balancing 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 application, T or UDP. 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 T or UDP template: a. Select Config > Service > Template. b. Select L4 > T or L4 > UDP on the menu bar. c. Click Add. d. Enter a name for the template. e. Edit template settings as needed for your application. (See “T Template Parameters” on page 864 or “UDP Template Parameters” on page 867.) f. Click OK. 4. To configure a source-IP persistence template: a. Select Config > Service > Template. b. Select Persistent > Source IP Persistent on the menu bar. c. Click Add. d. Enter a name for the template. e. Edit template settings as needed for your application. (See “SourceIP Persistence Template Parameters” on page 860.) f. Click OK. 5. To configure the virtual server: a. Select Config > Service > SLB, if not already selected. b. Select Virtual Server on the menu bar. c. Click Add. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

265 of 960

AX Series - Configuration Guide Configuring Layer 4 Load Balancing 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 application, T or UDP. 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 1. To configure the real servers, use the following commands: slb server server-name ipaddr This command changes the CLI to the configuration level for the real server, where you can use the following command to add the T or UDP port to the server: port port-num {t | 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 {t | udp} This command changes the CLI to the configuration level for the service group, where you can use the following command to add the real servers and service ports to the group: member server-name:portnum The portnum is the protocol port number of the service to be load balanced. In this example, specify “t-2:1020”. Repeat the command for “t-3:1020” and “t-4:1020”.

266 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 4 Load Balancing 3. To configure a custom T or UDP template, use the following commands at the global configuration level of the CLI: slb template t 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 “T Template Parameters” on page 864 or “UDP Template Parameters” on page 867. 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 5. To configure the virtual server, use the following commands: slb virtual-server name ipaddr This command changes the CLI to the configuration level for the virtual server, where you can use the following command to add the virtual port to the server: port port-number {t | udp} For this example, specify t 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: service-group group-name 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

267 of 960

AX Series - Configuration Guide Configuring Layer 4 Load Balancing

CLI EXAMPLE The following commands configure the real servers: AX(config)#slb server t-2 10.10.10.2 AX(config-real server)#port 1020 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server t-3 10.10.10.3 AX(config-real server)#port 1020 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server t-4 10.10.10.4 AX(config-real server)#port 1020 t AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure the service group: AX(config)#slb service-group t-sg t AX(config-slb service group)#member t-2:1020 AX(config-slb service group)#member t-3:1020 AX(config-slb service group)#member t-4:1020 AX(config-slb service group)#exit

The following commands configure a source-IP persistence template: AX(config)#slb template persist source-ip app1020persist AX(config-source ip persistence template)#match-type server AX(config-source ip persistence template)#exit

The following commands configure the virtual server: AX(config)#slb virtual-server web-vip 192.168.55.55 AX(config-slb virtual server)#port 1020 t AX(config-slb virtual server-slb virtua...)#service-group t-sg AX(config-slb virtual server-slb virtua...)#template persist source-ip app1020persist

268 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

IP Protocol Load Balancing This chapter describes load balancing of traffic based solely on transport protocol (T, 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 T, UDP, or other (not UDP or T), 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

269 of 960

AX Series - Configuration Guide Overview FIGURE 103

IP Protocol Load Balancing

This example uses separate service groups for each of the following types of traffic: • HTTP traffic addressed to T port 80 is sent to service group http-grp. • All T traffic addressed to any T port except port 80 is sent to ser-

vice group t-grp.

270 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview • All UDP traffic, addressed to any UDP port, is sent to service group

udp-grp. • All other traffic (all non T/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 T port 80 is always used for client requests addressed to that port, instead of a service group configured for the wildcard port. Health checking does not apply to the wildcard port. When you configure IP protocol load balancing, make sure to disable health checking of port 0. If you leave health checking enabled, the port will be marked down and the client’s request therefore will not be serviced. SLB NAT For client request traffic to which IP protocol load balancing applies, the AX device translates only the destination IP address, not the protocol port number. The AX device translates the destination IP address in the request from the VIP address to a real server’s IP address. The AX device then sends the request to the same protocol port number as the one requested by the client. (Likewise, the AX device does not translate the port number to “0”.) In configurations where some protocol port numbers are explicitly specified, auto port translation is still ed for the explicitly specified port numbers. In the example above, SLB NAT can translate T port 80 into another T port number if required by the configuration. Template For T or UDP, a T or UDP template is applied, as in other types of SLB. Optionally, you also can use a source-IP persistence template. For non-T/UDP traffic, the T template is used.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

271 of 960

AX Series - Configuration Guide Configuring IP Protocol Load Balancing Direct Server Return For either of the following types of applications, IP protocol load balancing is ed 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 T/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-T/UDP traffic. Layer 4 load balancing applies only to T or UDP traffic. In addition, IP protocol load balancing uses a wildcard port number that matches on any T port, UDP port, or any non-T/UDP port, depending on the configuration. Layer 4 load balancing requires you to explicitly specify the protocol port numbers to load balance.

Configuring IP Protocol Load Balancing 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 (real servers) for traffic to which IP protocol load balancing will apply, specify 0 as the protocol port for the member.

272 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring IP Protocol Load Balancing 3. Configure the virtual server. Bind virtual port 0 to the service group(s) that have for port 0. Specify one of the following as the service type: • T • UDP • Others

For load balancing of non-T/UDP traffic, you can specify T 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-T/ UDP traffic.

Note:

USING THE GUI Configuration of IP protocol SLB is similar to configuration of T/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 T, 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 270. For simplicity, the example assumes that only the default T 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 ed as in previous releases. AX(config)#slb server rs1 10.10.10.21 AX(config-real server)#port 80 t AX(config-real server)#exit AX(config)#slb server rs2 10.10.10.22 AX(config-real server)#port 80 t AX(config-real server)#exit AX(config)#slb server rs3 10.10.20.21 AX(config-real server)#port 0 t P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

273 of 960

AX Series - Configuration Guide Configuring IP Protocol Load Balancing AX(config-real server)#no health-check AX(config-real server)#exit AX(config)#slb server rs4 10.10.20.22 AX(config-real server)#port 0 t AX(config-real server)#no health-check AX(config-real server)#exit AX(config)#slb server rs5 10.10.30.21 AX(config-real server)#port 0 udp AX(config-real server)#no health-check AX(config-real server)#exit AX(config)#slb server rs6 10.10.30.22 AX(config-real server)#port 0 udp AX(config-real server)#no health-check AX(config-real server)#exit AX(config)#slb server rs7 10.10.40.21 AX(config-real server)#port 0 t AX(config-real server)#no health-check AX(config-real server)#exit AX(config)#slb server rs8 10.10.40.22 AX(config-real server)#port 0 t AX(config-real server)#no health-check AX(config-real server)#exit

The following commands configure the service groups. AX(config)#slb service-group http-grp t AX(config-slb service group)#member rs1:80 AX(config-slb service group)#member rs2:80 AX(config-slb service group)#exit AX(config)#slb service-group t-grp t AX(config-slb service group)#member rs3:0 AX(config-slb service group)#member rs4:0 AX(config-slb service group)#exit AX(config)#slb service-group udp-grp udp AX(config-slb service group)#member rs5:0 AX(config-slb service group)#member rs6:0 AX(config-slb service group)#exit AX(config)#slb service-group others-grp t AX(config-slb service group)#member rs7:0 AX(config-slb service group)#member rs8:0 AX(config-slb service group)#exit

274 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring IP Protocol Load Balancing The following commands configure the virtual server. AX(config)#slb virtual-server vip1 192.168.2.1 AX(config-slb virtual server)#port 80 t AX(config-slb virtual server-slb virtua...)#service-group http-grp AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#port 0 t AX(config-slb virtual server-slb virtua...)#service-group t-grp AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#port 0 udp AX(config-slb virtual server-slb virtua...)#service-group udp-grp AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#port 0 others AX(config-slb virtual server-slb virtua...)#service-group t-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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

275 of 960

AX Series - Configuration Guide Configuring IP Protocol Load Balancing

276 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 ed.

Note:

Configuring a Wildcard VIP 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. Promiscuous VIP must be enabled on the interface connected to clients who will access wildcard VIPs. By default, promiscuous VIP is disabled.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

277 of 960

AX Series - Configuration Guide Configuring a Wildcard VIP 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. -Through Layer 2/3 Forwarding for Layer 4 Wildcard VIP Traffic AX Release 2.0.2 and later s 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: 1. Select Config > Service > SLB. 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. 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.

278 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring a Wildcard VIP 7. Select the IP version, IPv4 or IPv6. 8. Configure other VIP settings, then click OK. To enable promiscuous VIP : 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

279 of 960

AX Series - Configuration Guide Configuring a Wildcard VIP 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 , use the following command at the configuration level for each interface connected to clients: [no] ip allow-promiscuous-vip

280 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring a Wildcard VIP

Configuration Examples See the following: • “Outbound Link Load Balancing” on page 295 • “Transparent Cache Switching” on page 301

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

281 of 960

AX Series - Configuration Guide Configuring a Wildcard VIP

282 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

SLB Protocol Translation SLB Protocol Translation (SLB-PT) enables IPv4 servers to be used for serving content to IPv6 clients. Likewise, SLB-PT enables IPv6 servers to be used for serving content to IPv4 clients. Server farms can contain both IPv4 and IPv6 servers. SLB-PT is ed for the following virtual port types: • UDP • T • 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

283 of 960

AX Series - Configuration Guide FIGURE 106

SLB Protocol Translation

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 client’s request to the selected server. If the server is an IPv4 server, the AX device translates the IP protocol of the client’s request from IPv6 to IPv4 before forwarding it to the IPv4 server. Likewise, when the AX device receives the servers’s reply, the AX device translates the reply from IPv4 to IPv6, then forwards the reply to the client. 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.

284 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide As a minimum requirement, a single NAT pool is required, for the IP type (IPv4 or IPv6) that differs from the IP type of clients. In this example, an IPv4 pool is required. The pool is used if the AX device selects an IPv4 server for an IPv6 client’s request. The pool must be bound to each of the virtual ports that has a corresponding real port on an IPv4 server. If the deployment also will send IPv4 client requests to IPv6 servers, an IPv6 pool is also required. For simplicity, the CLI example below uses a single IPv4 NAT pool. Following the example, the “Examples Using Multiple Source NAT Pools” on page 288 section describes how to use multiple pools. CLI Example The following commands configure the SLB-PT deployment shown in Figure 106 on page 284. 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)#interface ethernet 1 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:ethernet1)#enable AX(config-if:ethernet1)#interface ethernet 2 AX(config-if:ethernet2)#ipv6 address 2001:32::2020:2001/64 AX(config-if:ethernet2)#enable AX(config-if:ethernet2)#exit

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:

P e r f o r m a n c e

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 288. 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 11/3/2010

285 of 960

AX Series - Configuration Guide The following commands configure the IPv4 real servers. For simplicity, all the IPv4 and IPv6 servers have the same real ports. AX(config)#slb server v4server-1 192.168.217.10 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 53 udp AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#port 25 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server v4server-2 192.168.217.11 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 53 udp AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#port 25 t AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure the IPv6 real servers: AX(config)#slb server v6server-1 2001:558:ff4e:2::1 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 53 udp AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#port 25 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server v6server-2 2001:558:ff4e:2::2 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 53 udp AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit

286 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide AX(config-real server)#port 25 t AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure the service group: AX(config)#slb service-group sgv4v6 AX(config-slb service group)#member v4server-1:80 AX(config-slb service group)#member v4server-2:80 AX(config-slb service group)#member v6server-1:80 AX(config-slb service group)#member v6server-2:80 AX(config-slb service group)#member v4server-1:53 AX(config-slb service group)#member v4server-2:53 AX(config-slb service group)#member v6server-1:53 AX(config-slb service group)#member v6server-2:53 AX(config-slb service group)#member v4server-1:443 AX(config-slb service group)#member v4server-2:443 AX(config-slb service group)#member v6server-1:443 AX(config-slb service group)#member v6server-2:443 AX(config-slb service group)#member v4server-1:25 AX(config-slb service group)#member v4server-2:25 AX(config-slb service group)#member v6server-1:25 AX(config-slb service group)#member v6server-2:25 AX(config-slb service group)#exit

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 s: Address or name of remote host []?10.10.10.2 name []?ax []?********* File name [/]?sslcert.pem AX(config)#slb ssl-load certificate certkey.pem s: Address or name of remote host []?10.10.10.2 name []?ax []?********* File name [/]?certkey.pem AX(config)#slb template client-ssl cssl AX(config-client SSL template)#certsslcert.pem AX(config-client SSL template)#key certkey.pem AX(config-client SSL template)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

287 of 960

AX Series - Configuration Guide The following commands configure the VIP: AX(config)#slb virtual-server v6vip 2001:32::2020:2000 AX(config-slb virtual server)#port 80 http 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-slb virtua...)#exit AX(config-slb virtual server)#port 53 udp 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-slb virtua...)#exit AX(config-slb virtual server)#port 443 https AX(config-slb virtual server-slb virtua...)#source-nat pool v4natpool-1 AX(config-slb virtual server-slb virtua...)#template client-ssl cssl AX(config-slb virtual server-slb virtua...)#service-group sgv4v6 AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#port 25 smtp 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-slb virtua...)#exit

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: AX(config)#ip nat pool v4natpool-1 192.168.217.200 192.168.217.200 netmask /24 AX(config)#ip nat pool v4natpool-2 192.168.217.220 192.168.217.220 netmask /24

288 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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)#port 80 http AX(config-slb virtual server-slb virtua...)#access-list name v6acl-1 sourcenat-pool v4natpool-1 AX(config-slb virtual server-slb virtua...)#access-list name v6acl-2 sourcenat-pool v4natpool-2

Each of the access-list commands binds one of the IPv6 ACLs to the virtual port. The source-nat-pool option used with each command binds an IPv4 pool to the ACL. When the AX device receives a request for the VIP, the AX device matches the client address against the source addresses in the ACLs. The AX device then uses the IPv4 NAT pool bound to the first matching ACL. The AX device translates the client’s request from an IPv6 packet into an IPv4 packet. The AX device replaces the client’s IPv6 address with an IPv4 address from the selected pool. The IPv6 VIP address is replaced with the server’s IPv4 address. If the client’s 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 client’s IP type (IPv4 or IPv6) is not the same as the IP type of the selected server. Otherwise, if the IP type of the client and the selected server is the same, SLB-PT is not required for the request. The request is sent to the server with the client’s original IP address.

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 client’s IP address must match the source address in at least one of the ACLs associated with the pools. Otherwise, the client’s traffic is dropped. Note:

P e r f o r m a n c e

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 11/3/2010

289 of 960

AX Series - Configuration Guide This example builds on the example in “Multiple IPv4 Pools” on page 288. 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 client’s IP address will be used. Likewise, if SLB selects an IPv6 server, the IPv6 pool bound to the ACL will be used. The following commands configure the IPv6 NAT pools: AX(config)#ipv6 nat pool v6natpool-1 2001:32::2020:2010 2001:32::2020:2010 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: AX(config-slb virtual server-slb virtua...)#access-list name v6acl-1 sourcenat-pool v4natpool-2 AX(config-slb virtual server-slb virtua...)#access-list name v6acl-2 sourcenat-pool v6natpool-1

290 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 292.) 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 293.)

Stateless Load-Balancing Methods 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 T or UDP port. • Stateless Destination IP+Port Hash – Balances server load based on a

hash value calculated using the destination IP address and destination T 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 T 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

291 of 960

AX Series - Configuration Guide Stateless Load-Balancing Methods 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 ed. Mega-proxies may interfere with equal balancing of traffic load among the multiple data Us. 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

292 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Stateless Load-Balancing Methods

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

293 of 960

AX Series - Configuration Guide Stateless Load-Balancing Methods

294 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

Outbound Link Load Balancing The AX Series s 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

P e r f o r m a n c e

b y

Link Load Balancing

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

295 of 960

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

link being selected an equal number of times. • Least-connections – Selects the link that has the least current client con-

nections on it. The connection count is based on client connections 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 es back through the AX device, use an IP source NAT pool for each WAN link. The pools do not need to contain more than a few addresses. The AX device internally uses a separate protocol port number for each client session on a pool address. SLB destination NAT, which is enabled by default, must be disabled. In a standard SLB configuration, destination NAT is used to translate the server address (destination IP address) requested by clients from the VIP address into the server’s real address. However, this NAT operation is not applicable to outbound LLB.

296 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

Configuring Link Load Balancing To configure LLB: 1. Configure an IP source NAT pool for each link to be load balanced. The address range in a pool must be in the same subnet as the next-hop router’s interface with the AX device. Configure a pool group and add the pools to it. 2. Configure the AX interfaces connected to the clients. Enable promiscuous VIP 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 (T 0, UDP 0, or both) to the server. You can use Layer 3 health checking (ICMP ping) to check the health of the router’s IP interface. However, the configuration requires health checking to be disabled on the wildcard ports added for a router. The router will not respond to these health checks. If you leave health 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 T and UDP ports, configure a service group for T 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 T port (T 0) and bind it to the T 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

297 of 960

AX Series - Configuration Guide CLI Example The commands in this example implement the LLB configuration shown in Figure 107 on page 295. 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 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)#interface ethernet 3 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)#interface ethernet 4 AX(config-if: ethernet4)#ip address 10.20.20.1 255.255.255.0 AX(config-if: ethernet4)#ip allow-promiscuous-vip AX(config-if: ethernet4)#exit

The following commands configure the AX interfaces to the next-hop routers for the load-balanced links: AX(config)#interface ethernet 1 AX(config-if: ethernet1)#ip address 192.168.10.2 255.255.255.0 AX(config-if: ethernet1)#exit AX(config)#interface ethernet 2 AX(config-if: ethernet2)#ip address 192.168.20.2 255.255.255.0 AX(config-if: ethernet2)#exit

298 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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)#port 0 t AX(config-real server-node port)#no health-check AX(config-real server-node port)#exit AX(config-real server)#port 0 udp AX(config-real server-node port)#no health-check AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server link-201 192.168.20.1 AX(config-real server)#port 0 t AX(config-real server-node port)#no health-check AX(config-real server-node port)#exit AX(config-real server)#port 0 udp AX(config-real server-node port)#no health-check AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure service groups for the links: AX(config)#slb service-group outbound-t-links t AX(config-slb svc group)#member link-101:0 AX(config-slb svc group)#member link-201:0 AX(config-slb svc group)#exit AX(config)#slb service-group outbound-udp-links udp AX(config-slb svc group)#member link-101:0 AX(config-slb svc group)#member link-201:0 AX(config-slb svc group)#exit

The following commands configure the virtual server: AX(config)#slb virtual-server wildcard-vip 0.0.0.0 AX(config-slb vserver)#port 0 t AX(config-slb vserver-vport)#service-group outbound-t-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 AX(config-slb vserver-vport)#no-dest-nat

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

299 of 960

AX Series - Configuration Guide

300 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Transparent Cache Switching Overview The AX Series s 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 shows an example. FIGURE 108

P e r f o r m a n c e

b y

Transparent Cache Switching

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

301 of 960

AX Series - Configuration Guide Overview In this example, a client sends a request for content that is hosted by the content server. The AX device redirects the client’s request to the cache server. If the cache server has the requested content, the cache server sends the content to the AX device, which sends the content to the client. If the content is cacheable, but the cache server does not have the requested content or the content is stale, the cache server requests the content from the content server, caches the content, then sends the content to the AX device, which sends the content to the client. Granularity of TCS You can configure Layer 4 TCS or Layer 7 TCS. • Layer 4 TCS – Sends all T 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

302 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Overview switching rule, the AX device selects the service group specified in the URL switching rule, instead of the service group bound to the virtual port. For example, you can configure a URL switching rule that matches on any URL that contains “.mycorp/”. In this case, requests for any URL that contains “.mycorp/” are sent to the service group that contains the cache server. Requests for other URLs are sent to the gateway router instead. In a Layer 7 TCS configuration that uses URL switching, a separate real server is required for the gateway router, and the real server is required to be placed in its own service group. The gateway router’s service group is used as the default service group for the virtual port. Client requests to a URL that does not match a URL switching rule are sent to the gateway router’s service group instead of the cache server’s service group. • Destination-IP persistence template – In deployments that use multiple

cache servers, you can use a destination-IP persistence template to ensure that the same cache server is used for every request for content on a given content server. The AX device uses standard SLB to select a cache server for the first request to a real server IP address, and assigns a hash value to the server. All subsequent requests for the same real server are sent to the same cache server. By always using the same cache server for content from a given server, a destination-IP persistence template can reduce duplication of content on multiple cache servers, and can also reduce cache misses. • RAM caching template – To also cache some content on the AX device

itself, you can use a RAM caching template. In this case, the AX device directly serves content that is cached on the AX device, and only sends requests to the cache server for content that is not cached on the AX device. • Connection reuse template – You can use a connection reuse template to

reuse T connections. When a client’s session ends, the T connection is not terminated. Instead, the connection is reused for a new client session. for Spoofing Caches Some cache servers can use the client’s IP address instead of the cache server’s IP address as the source address when obtaining content requested by the client. A cache server operating in this mode is a spoofing cache server. Configuration for a spoofing cache server includes a couple of additional steps. (See “Enabling for Cache Spoofing” on page 314.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

303 of 960

AX Series - Configuration Guide Configuring Layer 4 TCS High Availability 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 315.

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

304 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring Layer 4 TCS CLI Example The commands in this section implement the TCS configuration shown in Figure 109. FIGURE 109

P e r f o r m a n c e

b y

Layer 4 TCS

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

305 of 960

AX Series - Configuration Guide Configuring Layer 4 TCS 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-vlan:4)#exit 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-vlan:2)#exit AX(config)#interface ve 2 AX(config-if:ve2)#ip address 10.10.10.1 255.255.0.0 AX(config-if:ve2)#exit

The following commands configure the interface to the cache server: AX(config)#interface ethernet 5 AX(config-if:ethernet5)#ip address 110.110.110.254 255.255.255.0 AX(config-if:ethernet5)#exit

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. T port 80 is added to the real server. AX(config)#slb server cache-rs 110.110.110.10 AX(config-real server)#port 80 t AX(config-real server-node port)#exit

306 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring Layer 7 TCS The following command configures a service group for the cache server: AX(config)#slb service-group sg-tcs t AX(config-slb svc group)#member cache-rs:80 AX(config-slb svc group)#exit

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 t AX(config-slb vserver-vport)#service-group sg-tcs AX(config-slb vserver-vport)#no-dest-nat

Configuring Layer 7 TCS Layer 7 TCS can be configured in either of the following ways. Select one of these methods based on the level of granularity you want to use for traffic redirection. • Service type HTTP without URL switching rules – This method redi-

rects all HTTP traffic to the cache server. The configuration steps are very similar to those for Layer 4 TCS. The only difference is use of HTTP instead of T 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 308 shows an example of the first method, which does not use URL switching rules. Figure 111 on page 309 shows an example of the second method, which does use URL switching rules.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

307 of 960

AX Series - Configuration Guide Configuring Layer 7 TCS FIGURE 110

308 of 960

Layer 7 TCS Without URL Switching Rules

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring Layer 7 TCS FIGURE 111

P e r f o r m a n c e

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 11/3/2010

309 of 960

AX Series - Configuration Guide Configuring Layer 7 TCS

Service Type HTTP Without URL Switching Rules To configure this type of Layer 7 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 T port; for example, T port 80. 4. Configure a service group for the cache server and add the cache server to it. 5. Configure a virtual server with virtual IP address 0.0.0.0 (the wildcard VIP address) and bind it to the ACL. Add virtual port 80 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 The commands in this section implement the TCS configuration shown in Figure 110 on page 308. The commands for configuring the interfaces and ACL, and the real server and service group for the cache server, are the same as those used in the Layer 4 TCS example, and are therefore not shown. The following commands configure a 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 http AX(config-slb vserver-vport)#service-group sg-tcs AX(config-slb vserver-vport)#no-dest-nat

310 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring Layer 7 TCS

Service Type HTTP with URL Switching Rules To configure this type of Layer 7 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 T or UDP port; for example, T 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 T port number as the one on the cache server (for example, T 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:

5. Configure a service group for the cache server and add the cache server 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. 8. Configure a virtual server with virtual IP address 0.0.0.0 (the wildcard VIP address) and bind it to the ACL. Add virtual port 80 with service type HTTP and bind it to the service group containing the cache server. Bind the virtual port to the HTTP template. Enable disable destination NAT. Add virtual port 0 with service type HTTP and bind it to the service group containing the router. Enable disable destination NAT. CLI Example The commands in this section implement the TCS configuration shown in Figure 111 on page 309. The commands for configuring the interfaces and P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

311 of 960

AX Series - Configuration Guide Configuring Layer 7 TCS 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 AX(config-real server)#port 80 t AX(config-real server-node port)#no health-check AX(config-real server-node port)#exit

The following commands configure a service group for the router: AX(config)#slb service-group sg-router t AX(config-slb svc group)#member router:80 AX(config-slb svc group)#exit

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-HTTP template)#exit

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 http AX(config-slb vserver-vport)#service-group sg-router AX(config-slb vserver-vport)#template http http1 AX(config-slb vserver-vport)#no-dest-nat

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 The commands in this section implement the TCS configuration shown in Figure 112. Only the commands specific to destination-IP persistence are

312 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring Layer 7 TCS 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:

P e r f o r m a n c e

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 11/3/2010

313 of 960

AX Series - Configuration Guide Configuring Layer 7 TCS 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 virtual-server wildcard 0.0.0.0 acl 198 AX(config-slb vserver)#port 80 http AX(config-slb vserver-vport)#template http http1 AX(config-slb vserver-vport)#service-group sg-router AX(config-slb vserver-vport)#no-dest-nat AX(config-slb vserver-vport)#template persist destination-ip d-sticky AX(config-slb vserver-vport)#exit AX(config-slb vserver)#exit

Enabling 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 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 . 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 for the TCS configuration shown in Figure 112. AX(config)#interface ethernet 5 AX(config-if:ethernet5)#ip address 110.110.110.254 255.255.255.0 AX(config-if:ethernet5)#ip cache-spoofing-port AX(config-if:ethernet5)#exit AX(config)#slb server cache-rs 110.110.110.10 AX(config-real server)#spoofing-cache AX(config-real server)#port 80 t

314 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide 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 shows an example. FIGURE 113

P e r f o r m a n c e

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 11/3/2010

315 of 960

AX Series - Configuration Guide Configuring IPv4 TCS in High Availability Layer 3 Inline Mode 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 on the AX interface connected to the cache server. • U processing – U 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.

316 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring IPv4 TCS in High Availability Layer 3 Inline Mode • 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 T, should be used. HA ses-

sion synchronization is ed 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 on the real server configuration for the cache server. Service group parameters: • Type – Typically, the type should be T. • – 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 307.) The example in Figure 113 on page 315 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 (T). • 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:

P e r f o r m a n c e

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 11/3/2010

317 of 960

AX Series - Configuration Guide Configuring IPv4 TCS in High Availability Layer 3 Inline Mode 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 ing a large file, the reset may be noticeable, because the 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 302. The following CLI examples show how to implement the configuration shown in Figure 113 on page 315.

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)#u-process AX-1(config-if:ethernet1)#interface ethernet 3 AX-1(config-if:ethernet3)#ip allow-promiscuous-vip AX-1(config-if:ethernet3)#u-process AX-1(config-if:ethernet3)#interface ethernet 5 AX-1(config-if:ethernet5)#ip cache-spoofing-port AX-1(config-if:ethernet5)#u-process AX-1(config-if:ethernet5)#interface ethernet 6 AX-1(config-if:ethernet6)#u-process 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

318 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring IPv4 TCS in High Availability Layer 3 Inline Mode the router that connects the AX device to the client. U processing is also enabled on the routes. AX-1(config)#ip route 20.20.20.0 /24 10.10.10.20 u-process AX-1(config)#ip route 192.168.19.0 /24 10.10.10.254 u-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 interface ethernet 3 AX-1(config)#ha interface ethernet 6 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 t AX-1(config-real server-node port)#exit AX-1(config-real server)#exit AX-1(config)#slb server cache2 10.10.10.11 AX-1(config-real server)#spoofing-cache AX-1(config-real server)#port 80 t 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 t AX-1(config-slb svc group)#member cache1:80 AX-1(config-slb svc group)#member cache2:80 AX-1(config-slb svc group)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

319 of 960

AX Series - Configuration Guide Configuring IPv4 TCS in High Availability Layer 3 Inline Mode The following commands configure the virtual server: 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 t 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 AX-2(config-trunk:1)#ethernet 1 to 2 ethernet 9 AX-2(config-trunk:1)#trunk 3 AX-2(config-trunk:3)#ethernet 3 to 4 AX-2(config-trunk:3)#vlan 11 AX-2(config-vlan:11)#untagged ethernet 3 to 6 AX-2(config-vlan:11)#tagged ethernet 1 to 2 ethernet 9 AX-2(config-vlan:11)#router-interface ve 1 AX-2(config-vlan:11)#interface ethernet 1 AX-2(config-if:ethernet1)#u-process AX-2(config-if:ethernet1)#interface ethernet 3 AX-2(config-if:ethernet3)#ip allow-promiscuous-vip AX-2(config-if:ethernet3)#u-process AX-2(config-if:ethernet3)#interface ethernet 5 AX-2(config-if:ethernet5)#ip cache-spoofing-port AX-2(config-if:ethernet5)#u-process AX-2(config-if:ethernet5)#interface ethernet 6 AX-2(config-if:ethernet6)#u-process AX-2(config-if:ethernet6)#interface ve 1 AX-2(config-if:ve1)#ip address 10.10.10.2 255.255.255.0 AX-2(config-if:ve1)#ip allow-promiscuous-vip AX-2(config-if:ve1)#exit

320 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring IPv4 TCS in High Availability Layer 3 Inline Mode AX-2(config)#ip route 20.20.20.0 /24 10.10.10.20 u-process AX-2(config)#ip route 192.168.19.0 /24 10.10.10.254 u-process 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 group 1 priority 180 AX-2(config)#ha interface ethernet 1 AX-2(config)#ha interface ethernet 3 AX-2(config)#ha interface ethernet 6 AX-2(config)#ha conn-mirror ip 10.10.10.1 AX-2(config)#ha preemption-enable AX-2(config)#floating-ip 10.10.10.250 ha-group 1 AX-2(config)#ha l3-inline-mode AX-2(config)#ha restart-port-list ethernet 1 to 5 ethernet 9 AX-2(config)#slb server cache1 10.10.10.10 AX-2(config-real server)#spoofing-cache AX-2(config-real server)#port 80 t AX-2(config-real server-node port)#exit AX-2(config-real server)#exit AX-2(config)#slb server cache2 10.10.10.11 AX-2(config-real server)#spoofing-cache AX-2(config-real server)#port 80 t AX-2(config-real server-node port)#exit AX-2(config-real server)#exit AX-2(config)#slb service-group sg-cache-80 t AX-2(config-slb svc group)#member cache1:80 AX-2(config-slb svc group)#member cache2:80 AX-2(config-slb svc group)#exit AX-2(config)#slb virtual-server wildcard 0.0.0.0 acl 198 AX-2(config-slb vserver)#ha-group 1 AX-2(config-slb vserver)#port 80 t AX-2(config-slb vserver-vport)#service-group sg-cache-80 AX-2(config-slb vserver-vport)#no-dest-nat AX-2(config-slb vserver-vport)#ha-conn-mirror

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

321 of 960

AX Series - Configuration Guide Configuring IPv6 TCS in High Availability Layer 3 Inline Mode

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

322 of 960

TCS – HA Layer 3 Inline Mode

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring IPv6 TCS in High Availability Layer 3 Inline Mode 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)#trunk 1 AX-1(config-trunk:1)#ethernet 5 to 6 AX-1(config-trunk:1)#vlan 21 AX-1(config-vlan:21)#untagged ethernet 1 to 3 AX-1(config-vlan:21)#router-interface ve 1 AX-1(config-vlan:21)#vlan 22 AX-1(config-vlan:22)#untagged ethernet 2 AX-1(config-vlan:22)#router-interface ve 22 AX-1(config-vlan:22)#vlan 56 AX-1(config-vlan:56)#untagged ethernet 5 to 6 AX-1(config-vlan:56)#router-interface ve 56 AX-1(config-vlan:11)#interface ethernet 1 AX-1(config-if:ethernet1)#u-process AX-1(config-if:ethernet1)#interface ethernet 2 AX-1(config-if:ethernet2)#u-process AX-1(config-if:ethernet2)#ip cache-spoofing-port AX-1(config-if:ethernet2)#interface ethernet 3 AX-1(config-if:ethernet3)#u-process AX-1(config-if:ethernet3)#interface ethernet 5 AX-1(config-if:ethernet5)#u-process AX-1(config-if:ethernet5)#interface ve 1 AX-1(config-if:ve1)#ipv6 address 2309:e90::2/64 AX-1(config-if:ve1)#ip allow-promiscuous-vip AX-1(config-if:ve1)#interface ve 22 AX-1(config-if:ve22)#ipv6 address 2409:c90::1/64 AX-1(config-if:ve22)#interface ve 56 AX-1(config-if:ve56)#ipv6 address 2509:c90::1/64 AX-1(config-if:ve56)#ip address 3.3.3.2 255.255.255.0 AX-1(config-if:ve56)#exit

Note:

P e r f o r m a n c e

b y

The u-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 11/3/2010

323 of 960

AX Series - Configuration Guide Configuring IPv6 TCS in High Availability Layer 3 Inline Mode On models AX 5100 and AX 5200, when configured in HA inline mode, all traffic going through the system is examined by the U for processing. Packets are not directly forwarded by the Layer 2/3 ASIC before examination by the U. 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. U 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 l3-inline-mode AX-1(config)#ha group 1 priority 200 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 interface ethernet 5 AX-1(config)#ha restart-port-list ethernet 1 ethernet 3 AX-1(config)#ha conn-mirror ip 3.3.3.3 AX-1(config)#ha preemption-enable 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 612.) The custom ICMP health monitor configured above is also used.

324 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring IPv6 TCS in High Availability Layer 3 Inline Mode AX-1(config)#slb server up-router 2309:e90::1 AX-1(config-real server)#health-check icmp AX-1(config-real server)#exit AX-1(config)#slb server down-router 2309:e90::3 AX-1(config-real server)#health-check icmp AX-1(config-real server)#exit

The following commands configure real servers for the cache servers: AX-1(config)#slb server cache1-ipv6 2409:c90::5 AX-1(config-real server)#spoofing-cache AX-1(config-real server)#health-check icmp AX-1(config-real server)#port 80 t AX-1(config-real server-node port)#exit AX-1(config-real server)#exit AX-1(config)#slb server cache2-ipv6 2409:c90::6 AX-1(config-real server)#spoofing-cache AX-1(config-real server)#health-check icmp AX-1(config-real server)#port 80 t 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 (cache servers): AX-1(config)#slb service-group cache-ipv6 t AX-1(config-slb svc group)#member cache1-ipv6:80 AX-1(config-slb svc group)#member cache2-ipv6:80 AX-1(config-slb svc group)#exit

The following commands configure the virtual server: AX-1(config)#slb virtual-server wildcard-ipv6 :: ipv6-acl ipv6-101 AX-1(config-slb vserver)#ha-group 1 AX-1(config-slb vserver)#port 80 t AX-1(config-slb vserver-vport)#service-group cache-ipv6 AX-1(config-slb vserver-vport)#no-dest-nat AX-1(config-slb vserver-vport)#ha-conn-mirror

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

325 of 960

AX Series - Configuration Guide Configuring IPv6 TCS in High Availability Layer 3 Inline Mode

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)#trunk 1 AX-2(config-trunk:1)#ethernet 5 to 6 AX-2(config-trunk:1)#vlan 21 AX-2(config-vlan:21)#untagged ethernet 1 to 3 AX-2(config-vlan:21)#router-interface ve 1 AX-2(config-vlan:21)#vlan 22 AX-2(config-vlan:22)#untagged ethernet 2 AX-2(config-vlan:22)#router-interface ve 22 AX-2(config-vlan:22)#vlan 56 AX-2(config-vlan:56)#untagged ethernet 5 to 6 AX-2(config-vlan:56)#router-interface ve 56 AX-2(config-vlan:11)#interface ethernet 1 AX-2(config-if:ethernet1)#u-process AX-2(config-if:ethernet1)#interface ethernet 2 AX-2(config-if:ethernet2)#u-process AX-2(config-if:ethernet2)#ip cache-spoofing-port AX-2(config-if:ethernet2)#interface ethernet 3 AX-2(config-if:ethernet3)#u-process AX-2(config-if:ethernet3)#interface ethernet 5 AX-2(config-if:ethernet5)#u-process AX-2(config-if:ethernet5)#interface ve 1 AX-2(config-if:ve1)#ipv6 address 2309:e90::4/64 AX-2(config-if:ve1)#ip allow-promiscuous-vip AX-2(config-if:ve1)#interface ve 22 AX-2(config-if:ve22)#ipv6 address 2409:c90::2/64 AX-2(config-if:ve22)#interface ve 56 AX-2(config-if:ve56)#ipv6 address 2509:c90::2/64 AX-2(config-if:ve56)#ip address 3.3.3.3 255.255.255.0 AX-2(config-if:ve56)#exit AX-2(config)#ipv6 route 2309:d90::/32 2309:e90::1 AX-2(config)#ipv6 route 2309:f90::/32 2309:e90::3

326 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring IPv6 TCS in High Availability Layer 3 Inline Mode 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 l3-inline-mode AX-2(config)#ha group 1 priority 100 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 interface ethernet 5 AX-2(config)#ha restart-port-list ethernet 1 ethernet 3 AX-2(config)#ha conn-mirror ip 3.3.3.2 AX-2(config)#ha preemption-enable 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-real server)#health-check icmp AX-2(config-real server)#exit AX-2(config)#slb server down-router 2309:e90::3 AX-2(config-real server)#health-check icmp AX-2(config-real server)#exit AX-2(config)#slb server cache1-ipv6 2409:c90::5 AX-2(config-real server)#spoofing-cache AX-2(config-real server)#health-check icmp AX-2(config-real server)#port 80 t AX-2(config-real server-node port)#exit AX-2(config-real server)#exit AX-2(config)#slb server cache2-ipv6 2409:c90::6 AX-2(config-real server)#spoofing-cache AX-2(config-real server)#health-check icmp AX-2(config-real server)#port 80 t AX-2(config-real server-node port)#exit AX-2(config-real server)#exit AX-2(config)#slb service-group cache-ipv6 t AX-2(config-slb svc group)#member cache1-ipv6:80 AX-2(config-slb svc group)#member cache2-ipv6:80 AX-2(config-slb svc group)#exit AX-2(config)#slb virtual-server wildcard-ipv6 :: ipv6-acl ipv6-101 AX-2(config-slb vserver)#ha-group 1 AX-2(config-slb vserver)#port 80 t AX-2(config-slb vserver-vport)#service-group cache-ipv6 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

327 of 960

AX Series - Configuration Guide Configuring TCS for FTP AX-2(config-slb vserver-vport)#no-dest-nat AX-2(config-slb vserver-vport)#ha-conn-mirror

Configuring TCS for FTP You can configure the AX device to use cache servers for FTP traffic. Figure 115 shows an example. 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.

328 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring TCS for FTP 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: 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. • 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 U processing on each interface. On these AX models, U processing is automatically used. 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 an FTP port to the server. If the cache server will spoof client IP addresses when requesting content from content servers, enable cache spoofing . 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

329 of 960

AX Series - Configuration Guide Configuring TCS for FTP 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. 7. Configure a virtual server with virtual IP address 0.0.0.0 (the wildcard VIP address) and bind it to the ACL. 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)#interface ethernet 1 AX(config-if:ethernet1)#enable AX(config-if:ethernet1)#ip address 10.10.10.254 255.255.255.0 AX(config-if:ethernet1)#u-process AX(config-if:ethernet1)#exit AX(config)#interface ethernet 2 AX(config-if:ethernet2)#enable AX(config-if:ethernet2)#ip address 192.168.19.254 255.255.255.0 AX(config-if:ethernet2)#ip allow-promiscuous-vip AX(config-if:ethernet2)#u-process AX(config-if:ethernet2)#exit AX(config)#interface ethernet 5 AX(config-if:ethernet5)#enable AX(config-if:ethernet5)#ip address 12.12.12.254 255.255.255.0 AX(config-if:ethernet5)#ip cache-spoofing-port AX(config-if:ethernet5)#u-process AX(config-if:ethernet5)#exit AX(config)#interface ethernet 6 AX(config-if:ethernet6)#enable AX(config-if:ethernet6)#ip address 11.11.11.254 255.255.255.0

330 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Configuring TCS for FTP AX(config-if:ethernet6)#ip cache-spoofing-port AX(config-if:ethernet6)#u-process AX(config-if:ethernet6)#exit

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 T port 21 is added to each real server. AX(config)#slb server ftps1 11.11.11.10 AX(config-real server)#spoofing-cache AX(config-real server)#port 21 t AX(config-real server-node port)#no health-check AX(config-real server-node port)#exit AX(config)#slb server ftps2 11.11.11.11 AX(config-real server)#spoofing-cache AX(config-real server)#port 21 t AX(config-real server-node port)#no health-check AX(config-real server-node port)#exit

The following commands configure an FTP service group for the cache server: AX(config)#slb service-group sg-ftps t AX(config-slb svc group)#member ftps1:21 AX(config-slb svc group)#member ftps2:21 AX(config-slb svc group)#exit

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 virtual-server wildcard 0.0.0.0 acl 198 AX(config-slb vserver)#port 21 ftp AX(config-slb vserver-vport)#service-group sg-ftps AX(config-slb vserver-vport)#no-dest-nat

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

331 of 960

AX Series - Configuration Guide Configuring TCS for FTP

332 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Overview

Firewall Load Balancing This chapter describes how to configure Firewall Load Balancing (FWLB).

Overview AX Series devices Firewall Load Balancing (FWLB). FWLB load balances server-client sessions across firewalls. Figure 116 shows an example FWLB topology. FIGURE 116

P e r f o r m a n c e

b y

Example FWLB Topology

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

333 of 960

AX Series - Configuration Guide 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.

334 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview Health Monitors To monitor the health of a firewall, use a Layer 3 monitor with the ICMP method, and with transparent mode enabled. This type of health monitor verifies a firewall’s health by ing 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

P e r f o r m a n c e

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 11/3/2010

335 of 960

AX Series - Configuration Guide 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 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 through at Layer 2. Interfaces to Clients and Servers This topology is ed 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.

336 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

337 of 960

AX Series - Configuration Guide FWLB Parameters

FWLB Parameters Table 6 lists the FWLB parameters. TABLE 6

FWLB Parameters

Parameter

Description and Syntax

ed Values

Firewall

Configures the firewall.

Default: None configured

(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 ed 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

health-check monitor-name Config > Service > Firewall > Firewall Node 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). Config > Service > Firewall > Firewall Node

Firewall Group Parameters Firewall service group (Required) Member (Required)

Load balancing method (Optional)

Configures the firewall group.

Default: None configured

fwlb service-group group-name Config > Service > Firewall > Firewall Group Adds a firewall to the firewall group.

Default: None

member fwall-name [priority num] 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. Config > Service > Firewall > Firewall Group 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.

When you configure one, the default priority is 1.

Default: round robin

[no] method least-connection Config > Service > Firewall > Firewall Group

338 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide FWLB Parameters TABLE 6

FWLB Parameters (Continued)

Parameter Statistics collection

Description and Syntax Enables or disables collection of statistical data for the firewall service group.

(Optional)

stats-data-enable

ed Values 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). Config > Service > Firewall > Firewall Group

Firewall Virtual Server Parameters Virtual firewall state

State of the firewall virtual server

Enabled or disabled Default: Enabled

Service ports

[no] disable [no] enable Config > Service > Firewall > Firewall Virtual server Specifies the service ports to load balance.

(Optional)

port port-number {t | udp} Config > Service > Firewall > Firewall Virtual 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

Config > Service > Firewall > Firewall Virtual server Specifies the HA group to use for the virtual firewall’s traffic.

(Optional)

[no] ha-group group-id

Session synchronization (Optional)

Config > Service > Firewall > Firewall Virtual 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 Config > Service > Firewall > Firewall Virtual server

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

339 of 960

AX Series - Configuration Guide FWLB Parameters TABLE 6

FWLB Parameters (Continued)

Parameter Source-IP persistence template

Description and Syntax Sends all traffic from a given source address to the same firewall.

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

T idle timeout (Optional)

[no] template persist source-ip template-name Config > Service > Firewall > Firewall Virtual server Specifies the number of seconds a T session through a firewall can remain idle before the AX device terminates the session.

60-15000 seconds Default: 300 seconds

[no] t-idle-timeout seconds Config > Service > Firewall > Firewall Virtual 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 “T and UDP Session Aging” on page 342. Specifies the number of seconds a UDP session through a firewall can remain idle before the AX device terminates the session.

60-15000 seconds Default: 300 seconds

[no] udp-idle-timeout seconds Config > Service > Firewall > Firewall Virtual server Note: The idle timeout applied to a session can come from the idle timeout configured here, the idle timeout configured on the virtual firewall port, or the idle time configured in SLB. See “T and UDP Session Aging” on page 342.

340 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide FWLB Parameters TABLE 6

FWLB Parameters (Continued)

Parameter Statistics collection

Description and Syntax Enables or disables collection of statistical data for the virtual firewall.

(Optional)

stats-data-enable

ed Values 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). Config > Service > Firewall > Firewall Virtual server

Firewall Virtual Service Port Parameters Port state

State of the virtual port.

Enabled or disabled

(Optional)

[no] disable [no] enable Config > Service > Firewall > Firewall Virtual server - Port Specifies the firewall group to use.

Default: Enabled

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

Firewall group (Optional)

Name of a configured firewall group

[no] service-group group-name

(Optional)

Config > Service > Firewall > Firewall Virtual server - Port Synchronizes active sessions onto the standby AX in the HA pair, to prevent the sessions from being interrupted if an HA failover occurs.

Source-IP persistence template

[no] ha-conn-mirror Config > Service > Firewall > Firewall Virtual server - Port Sends all traffic from a given source address to the same firewall.

Session synchronization

(Optional)

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.

Enabled or disabled Default: Disabled

Name of a configured source-IP persistence template Default: not set

[no] template persist source-ip template-name Config > Service > Firewall > Firewall Virtual server - Port

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

341 of 960

AX Series - Configuration Guide FWLB Parameters TABLE 6

FWLB Parameters (Continued)

Parameter T/UDP idle timeout (Optional)

Description and Syntax Specifies the number of seconds a session through a firewall on this service port can remain idle before the AX device terminates the session.

ed Values 60-15000 seconds Default: 300 seconds

[no] idle-timeout seconds Config > Service > Firewall > Firewall Virtual server - Port

Statistics collection

Note: The idle timeout applied to a session can come from the idle timeout configured here, the idle timeout configured on the virtual firewall, or the idle time configured in SLB. See “T and UDP Session Aging” on page 342. Enables or disables collection of statistical data for the virtual port.

(Optional)

stats-data-enable

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). Config > Service > Firewall > Firewall Virtual server - Port

T and UDP Session Aging By default, the AX device allows T or UDP connections through a firewall to be idle for 300 seconds (5 minutes). The idle timeout for a T 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. • For service-type T (Layer 4), the idle-timeout in the default SLB

T 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

T-proxy template is used. Unless the default template has been changed, the idle-timeout is 600 seconds.

342 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FWLB In the current release, the T idle-timeout settings in FWLB are never used. The AX device allows you to configure them but they are not used.

Note:

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:

P e r f o r m a n c e

b y

The essential steps are described in this section. For the complete list of FWLB settings you can configure, see Table 6 on page 338.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

343 of 960

AX Series - Configuration Guide Configuring FWLB

USING THE GUI To configure a health check for a firewall path 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 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

344 of 960

Config > Service > Health Monitor

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

Config > Service > Firewall > Firewall Node

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

345 of 960

AX Series - Configuration Guide Configuring FWLB FIGURE 120

Config > Service > Firewall > Firewall Group

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. b. Enter the protocol port number in the Port field. c. Select the transport protocol (T 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.

346 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FWLB g. Repeat for each protocol port. h. Click OK to complete the firewall virtual server configuration.

P e r f o r m a n c e

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 11/3/2010

347 of 960

AX Series - Configuration Guide Configuring FWLB

USING THE CLI 1. To configure HA parameters, use the following commands at the global configuration level of the CLI: 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: health monitor monitor-name [interval seconds | retry number | timeout seconds] Enter this command at the global Config level. 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 global Config level. health-check monitor-name 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 Enter this command at the global Config level. member fwall-name [priority num] method least-connection

348 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 This command changes the CLI to the configuration level for the virtual firewall named "default". The "default" virtual firewall is the only one ed in the current release. Enter this command at the global Config level. port port-number {t | udp} ha-group {1 | 2} Enter these commands at the configuration level for the virtual firewall. The port command specifies the service port that is being protected by the firewall. This is the virtual port configured on the VIP in the SLB configuration. The ha-group command specifies the HA group the 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

349 of 960

AX Series - Configuration Guide Configuring FWLB

CLI CONFIGURATION EXAMPLE—TOPOLOGY 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 333. 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 333, 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

350 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 svc group)#member fw1 AX-Ext-A(config-fwlb svc group)#member fw2 AX-Ext-A(config-fwlb svc group)#exit

The following commands configure the virtual firewall: AX-Ext-A(config)#fwlb virtual-firewall default AX-Ext-A(config-fwlb vfw)#ha-group 1 AX-Ext-A(config-fwlb vfw)#port 80 t AX-Ext-A(config-fwlb vfw-vport)#service-group fwsg AX-Ext-A(config-fwlb vfw-vport)#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 svc group)#member fw1 AX-Ext-S(config-fwlb svc group)#member fw2 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

351 of 960

AX Series - Configuration Guide Configuring FWLB AX-Ext-S(config-fwlb svc group)#exit AX-Ext-S(config)#fwlb virtual-firewall default AX-Ext-S(config-fwlb vfw)#ha-group 1 AX-Ext-S(config-fwlb vfw)#port 80 t AX-Ext-S(config-fwlb vfw-vport)#service-group fwsg AX-Ext-S(config-fwlb vfw-vport)#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 svc group)#member fw1 AX-Int-A(config-fwlb svc group)#member fw2 AX-Int-A(config-fwlb svc group)#exit AX-Int-A(config)#fwlb virtual-firewall default AX-Int-A(config-fwlb vfw)#ha-group 1 AX-Int-A(config-fwlb vfw)#port 80 t AX-Int-A(config-fwlb vfw-vport)#service-group fwsg AX-Int-A(config-fwlb vfw-vport)#ha-conn-mirror

352 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 svc group)#member fw1 AX-Int-S(config-fwlb svc group)#member fw2 AX-Int-S(config-fwlb svc group)#exit AX-Int-S(config)#fwlb virtual-firewall default AX-Int-S(config-fwlb vfw)#ha-group 1 AX-Int-S(config-fwlb vfw)#port 80 t AX-Int-S(config-fwlb vfw-vport)#service-group fwsg AX-Int-S(config-fwlb vfw-vport)#ha-conn-mirror

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

353 of 960

AX Series - Configuration Guide Configuring FWLB

CLI CONFIGURATION EXAMPLE—TOPOLOGY WITHOUT LAYER 2 SWITCHES The following sections show the CLI commands for configuring interfaces, FWLB, and HA on each of the AX devices shown in Figure 117 on page 335. 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 Ext-AX1(config-vlan:10)#untagged ethernet 1 Ext-AX1(config-vlan:10)#router-interface ve 1 Ext-AX1(config-vlan:10)#exit Ext-AX1(config)#interface ve 1 Ext-AX1(config-if:ve1)#ip address 10.1.1.10 255.255.255.0 Ext-AX1(config-if:ve1)#exit

The following commands configure the VE interface to the firewalls: Ext-AX1(config)#vlan 20 Ext-AX1(config-vlan:20)#untagged ethernet 2 ethernet 4 ethernet 13 Ext-AX1(config-vlan:20)#router-interface ve 2 Ext-AX1(config-vlan:20)#exit Ext-AX1(config)#interface ve 2 Ext-AX1(config-if:ve2)#ip address 20.1.1.10 255.255.255.0 Ext-AX1(config-if:ve2)#exit

The following commands configure the static routes: Ext-AX1(config)#ip route 40.1.1.0 /24 20.1.1.1 Ext-AX1(config)#ip route 30.1.1.0 /24 20.1.1.1

354 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FWLB The following commands configure global HA parameters: 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 interface ethernet 2 Ext-AX1(config)#ha interface ethernet 4 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 node fw2 20.1.1.2 Ext-AX1(config-firewall node)#health-check tsping Ext-AX1(config-firewall node)#exit Ext-AX1(config)#fwlb node fw3 20.1.1.3 Ext-AX1(config-firewall node)#health-check tsping Ext-AX1(config-firewall node)#exit Ext-AX1(config)#fwlb node fw4 20.1.1.4 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 svc group)#member fw1 Ext-AX1(config-fwlb svc group)#member fw2 Ext-AX1(config-fwlb svc group)#member fw3 Ext-AX1(config-fwlb svc group)#member fw4 Ext-AX1(config-fwlb svc group)#exit Ext-AX1(config)#fwlb virtual-firewall default Ext-AX1(config--fwlb vfw)#ha-group 1 Ext-AX1(config--fwlb vfw)#service-group fwsg Ext-AX1(config--fwlb vfw)#ha-conn-mirror Ext-AX1(config--fwlb vfw)#port 80 t P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

355 of 960

AX Series - Configuration Guide Configuring FWLB Ext-AX1(config-fwlb vfw-vport)#service-group fwsg Ext-AX1(config-fwlb vfw-vport)#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 Ext-AX2(config-vlan:50)#untagged ethernet 9 to 10 Ext-AX2(config-vlan:50)#router-interface ve 5 Ext-AX2(config-vlan:50)#exit Ext-AX2(config)#interface ve 5 Ext-AX2(config-if:ve5)#ip address 50.1.1.2 255.255.255.0 Ext-AX2(config-if:ve5)#exit Ext-AX2(config)#vlan 10 Ext-AX2(config-vlan:10)#untagged ethernet 1 Ext-AX2(config-vlan:10)#router-interface ve 1 Ext-AX2(config-vlan:10)#exit Ext-AX2(config)#interface ve 1 Ext-AX2(config-if:ve1)#ip address 10.1.1.20 255.255.255.0 Ext-AX2(config-if:ve1)#exit Ext-AX2(config)#vlan 20 Ext-AX2(config-vlan:20)#untagged ethernet 2 ethernet 4 ethernet 13 Ext-AX2(config-vlan:20)#router-interface ve 2 Ext-AX2(config-vlan:20)#exit Ext-AX2(config)#interface ve 2 Ext-AX2(config-if:ve2)#ip address 20.1.1.20 255.255.255.0 Ext-AX2(config-if:ve2)#exit Ext-AX2(config)#ip route 40.1.1.0 /24 20.1.1.1 Ext-AX2(config)#ip route 30.1.1.0 /24 20.1.1.1 Ext-AX2(config)#ha id 2 Ext-AX2(config)#ha group 1 priority 100

356 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring FWLB Ext-AX2(config)#ha interface ethernet 1 Ext-AX2(config)#ha interface ethernet 2 Ext-AX2(config)#ha interface ethernet 4 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

357 of 960

AX Series - Configuration Guide Configuring FWLB The following commands configure the VE interface to the servers: Int-AX1(config)#vlan 40 Int-AX1(config-vlan:40)#untagged ethernet 2 Int-AX1(config-vlan:40)#router-interface ve 2 Int-AX1(config-vlan:40)#exit Int-AX1(config)#interface ve 2 Int-AX1(config-if:ve2)#ip address 40.1.1.10 255.255.255.0 Int-AX1(config-if:ve2)#exit

The following commands configure the VE interface to the firewalls: Int-AX1(config)#vlan 30 Int-AX1(config-vlan:30)#untagged ethernet 1 ethernet 3 ethernet 13 Int-AX1(config-vlan:30)#router-interface ve 1 Int-AX1(config-vlan:30)#exit Int-AX1(config)#interface ve 1 Int-AX1(config-if:ve1)#ip address 30.1.1.10 255.255.255.0 Int-AX1(config-if:ve1)#exit

The following commands configure the static routes: Int-AX1(config)#ip route 10.1.1.0 /24 30.1.1.1 Int-AX1(config)#ip route 20.1.1.0 /24 30.1.1.1

The following commands configure global HA parameters: 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 interface ethernet 2 Int-AX1(config)#ha interface ethernet 3 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.

358 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 Int-AX2(config-vlan:60)#untagged ethernet 9 to 10 Int-AX2(config-vlan:60)#router-interface ve 60 Int-AX2(config-vlan:60)#exit Int-AX2(config)#interface ve 60 Int-AX2(config-if:ve60)#ip address 60.1.1.2 255.255.255.0 Int-AX2(config-if:ve60)#exit Int-AX2(config)#vlan 40 Int-AX2(config-vlan:40)#untagged ethernet 2 Int-AX2(config-vlan:40)#router-interface ve 2 Int-AX2(config-vlan:40)#exit Int-AX2(config)#interface ve 2 Int-AX2(config-if:ve2)#ip address 40.1.1.20 255.255.255.0 Int-AX2(config-if:ve2)#exit Int-AX2(config)#vlan 30 Int-AX2(config-vlan:30)#untagged ethernet 1 ethernet 3 ethernet 13 Int-AX2(config-vlan:30)#router-interface ve 1 Int-AX2(config-vlan:30)#exit Int-AX2(config)#interface ve 1 Int-AX2(config-if:ve1)#ip address 30.1.1.20 255.255.255.0 Int-AX2(config-if:ve1)#exit Int-AX2(config)#ip route 10.1.1.0 /24 30.1.1.1 Int-AX2(config)#ip route 20.1.1.0 /24 30.1.1.1 Int-AX2(config)#ha id 2 Int-AX2(config)#ha group 1 priority 100 Int-AX2(config)#ha interface ethernet 1 Int-AX2(config)#ha interface ethernet 2 Int-AX2(config)#ha interface ethernet 3 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

359 of 960

AX Series - Configuration Guide Configuring FWLB

360 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Server and Port Templates This chapter describes how to configure parameters for multiple servers and service ports using server and port templates.

Overview The AX device s 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

361 of 960

AX Series - Configuration Guide 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 390.) Connection limit Specifies the maximum number of connections allowed on any server that uses the template. (See “Connection Limiting” on page 370.) 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 372.) Slow start Provides time for servers that use the template to ramp-up after T/UDP service is enabled, by temporarily limiting the number of new connections on the server. (See “SlowStart” on page 374.) 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 895.) 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.

362 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 390.) 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 410. Specifies the maximum number of connections allowed on any real port that uses the template. (See “Connection Limiting” on page 370.) 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 372.) Enables destination Network Address Translation (NAT). Destination NAT is enabled by default, but is disabled in Direct Server Return (DSR) configurations.

DS

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 101. Sets the differentiated services code point (DS) 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 . (See “Dynamic Real Server Creation Using DNS” on page 895.) Provides time for real ports that use the template to ramp-up after T/UDP service is enabled, by temporarily limiting the number of new connections on the ports. (See “SlowStart” on page 374.) Specifies the IP NAT pool to use for asg a source IP address to client traffic addressed to the port. For information about NAT, see “Network Address Translation” on page 615 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 169. (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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

363 of 960

AX Series - Configuration Guide Overview TABLE 7

SLB Port and Server Template Parameters (Continued)

Template Type Virtual Server

Parameter Connection limit

Connection rate limiting ICMP rate limiting

Virtual Server Port

Gratuitous ARPs for subnet VIPs Connection limit

Connection rate limiting Reset unknown connections

Description Specifies the maximum number of connections allowed on any VIP that uses the template. (See “Connection Limiting” on page 370.) Limits the rate of new connections the AX is allowed to send to any VIP that uses the template. (See “Connection Rate Limiting” on page 372.) Limits the rate at which ICMP packets can be sent to the VIP. (See “ICMP Rate Limiting” on page 734.) Enables gratuitous ARPs for all VIPs in a subnet VIP. (See “Gratuitous ARPs for Subnet VIPs” on page 377.) Specifies the maximum number of connections allowed on any virtual service port that uses the template. (See “Connection Limiting” on page 370.) Limits the rate of new connections the AX is allowed to send to any virtual service port that uses the template. (See “Connection Rate Limiting” on page 372.) Enables sending of a T Reset (RST) in response to a session mismatch. (See “T Reset Option for Session Mismatch” on page 378.)

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.

364 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 1. Select Config > Service > SLB. 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

365 of 960

AX Series - Configuration Guide 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)#slb server rs1 10.1.1.99 AX(config-real server)#template server rs-tmplt1 AX(config-real server)#exit AX(config)#slb server rs2 10.1.1.100 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 366.

Applying a Server or Service Port Template 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 ed for server and port templates.

366 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Applying a Server or Service Port Template 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 . For configuration examples, see the feature sections referred to in Table 7 on page 362.

Binding a Server Template to a Real Server USING THE GUI 1. Select Config > Service > SLB. 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

367 of 960

AX Series - Configuration Guide Applying a Server or Service Port Template

Binding a Server Port Template to a Real Server Port USING THE GUI 1. Select Config > Service > SLB. 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. 6. When finished, click OK.

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 1. Select Config > Service > SLB. 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. 5. When finished, click OK.

USING THE CLI Enter the following command at the configuration level for the virtual server: [no] template virtual-server template-name

368 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Applying a Server or Service Port Template

Binding a Virtual Server Port Template to a Virtual Service Port USING THE GUI 1. Select Config > Service > SLB. 2. Click Virtual Server on the menu bar. 3. Click on the virtual server name. 4. In the Port section, select the port and click Edit. 5. Select the template from the Virtual Server Port Template drop-down list. 6. Click OK. 7. When finished, 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 1. Select Config > Service > SLB. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

369 of 960

AX Series - Configuration Guide 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-8000000 (8 million). 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. • 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:

370 of 960

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 P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

371 of 960

AX Series - Configuration Guide 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)#slb template server rs-tmplt1 AX(config-rserver)#conn-limit 500000 AX(config-rserver)#exit AX(config)#slb server rs1 10.1.1.99 AX(config-real server)#template server rs-tmplt1 AX(config-real server)#exit AX(config)#slb server rs2 10.1.1.100 AX(config-real server)#template server rs-tmplt1

Connection Rate Limiting 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 T/UDP service comes up on a service port. See “Slow-Start” on page 374. 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.

372 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Connection Rate Limiting

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 T 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 T 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: P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

373 of 960

AX Series - Configuration Guide 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)#slb template server rs-tmplt1 AX(config-rserver)#conn-rate-limit 50000 AX(config-rserver)#exit AX(config)#slb server rs1 10.1.1.99 AX(config-real server)#template server rs-tmplt1 AX(config-real server)#exit AX(config)#slb server rs2 10.1.1.100 AX(config-real server)#template server rs-tmplt1

Slow-Start The slow-start feature allows time for a server or real service port to ramp up after T/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. 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. TABLE 9

Default Slow-Start Ramp-Up

Number of Seconds After Server Restart 0-9 10-19 20-29 30-39

374 of 960

Total Maximum Concurrent Connections Allowed After Server Restart 128 256 512 1024

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Slow-Start TABLE 9

Default Slow-Start Ramp-Up (Continued)

Number of Seconds After Server Restart 40-49 50-59 60+

Total Maximum Concurrent Connections Allowed After Server Restart 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. 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 370), and the normal connection limit is smaller than the slow-start ending connection

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

375 of 960

AX Series - Configuration Guide Slow-Start limit, the AX device limits slow-start connections to the maximum allowed by the normal connection limit. Behavior When Slow Start Is Also Configured on the Real Server Itself Alternatively, you can enable slow-start on individual real servers. 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. It is recommended to configure slow start only in a server template or port template, not on the real server. If you do configure slow-start both on the real server itself and in a real server template or real port template, the actual slow-start behavior can differ from the behavior configured in the template. • – If slow start is configured on the real server and in a real server tem-

plate, the slow-start settings on the real server are used and the settings in the template are ignored. It is recommended to configure slow start only in a real server template or real port template. • – If slow start is configured on the real server and in a real port template,

the lower number of connections allowed by either of the configurations at a given interval is used.

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.

376 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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)#slb template server rs-tmplt1 AX(config-rserver)#slow-start AX(config-rserver)#exit AX(config)#slb server rs1 10.1.1.99 AX(config-real server)#template server rs-tmplt1 AX(config-real server)#exit AX(config)#slb server rs2 10.1.1.100 AX(config-real server)#template server rs-tmplt1

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:

P e r f o r m a n c e

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 11/3/2010

377 of 960

AX Series - Configuration Guide T Reset Option for Session Mismatch

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

T Reset Option for Session Mismatch Virtual port templates have an option that enables sending of a T Reset (RST) in response to a session mismatch. A session mismatch occurs when the AX device receives a T packet for a T 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.

378 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide T Reset Option for Session Mismatch When this option is enabled, T 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 T RST. Instead, the AX device reactivates the session and allows it to age out normally.

Note:

USING THE GUI To enable sending of T 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 T RSTs in response to a session mismatch, use the following command at the configuration level for a virtual port template: [no] reset-unknown-conn

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

379 of 960

AX Series - Configuration Guide T Reset Option for Session Mismatch

380 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 server’s IP address. The server es 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 T – Every 5 seconds, the AX device sends a connection

request (T SYN) to the specified T port on the server. The port es the health check if it replies to the AX device by sending a T 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 es 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, T, 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:

P e r f o r m a n c e

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

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

381 of 960

AX Series - Configuration Guide Health Method Timers

Health Method Timers Health methods operate based on the following timers: • Interval – Number of seconds between health check attempts.

Determination of the server or port’s health is not made within the interval. Instead, determination of health is made after the server or port es 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 385.) • 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 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 414.) Note:

382 of 960

The timeout does not apply to externally configured health monitors.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Health Method Timers

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

383 of 960

AX Series - Configuration Guide Health Method Timers 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

384 of 960

Health Checks Using Default Settings – Server or Port

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Health Method Types

Health Method Types Table 11 lists the internal health method types ed 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:

P e r f o r m a n c e

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

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

385 of 960

AX Series - Configuration Guide 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 check’s 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 server’s 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 request to the specified port. If anonymous is not used, the name also must be specified in the health check configuration.

386 of 960

(For more information, see “Customizing DNS Health Monitors” on page 399.) Server replies with FTP OK message or message. If the server sends the message, the AX Series sends the specified in the health check configuration. In this case, the AX Series expects the server to reply with another OK message.

Requested name and must be valid on the server.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 T 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 396.) If a name and 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.

Configuration Required 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 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 server’s IP address is placed in the request header’s Host: field. You can configure a different value if needed.

ICMP

The following types of authentication are ed: basic, digest and NT LAN Manager (NTLM) authentication. If you specify a name and , 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

387 of 960

AX Series - Configuration Guide Health Method Types TABLE 11 Internal Health Method Types (Continued) 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 , 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 request with the specified parameter.

Server replies with an OK message.

AX Series sends a Authentication Protocol (PAP) request to authenticate the name and specified in the health check configuration.

Configuration Required on Target Server If a Distinguished Name and are sent in the health check, they must match these values on the LDAP server.

The AX Series then sends the 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. Requested name and must be valid on the server.

Requested name and must be configured in the server’s 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 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 the health check. Requested OID and the SNMP community must both be valid on the server.

388 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Health Method Types TABLE 11 Internal Health Method Types (Continued) Type T

Description AX Series sends a connection request (T SYN) to the specified T port on the server.

Successful If... Server replies with a T SYN ACK. By default, the AX device completes the T handshake with the server:

Configuration Required on Target Server Destination T 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

389 of 960

AX Series - Configuration Guide 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 416.) After you bind the health monitor to a real server port, health checks using the monitor are addressed to the real server port number instead of the port number specified in the health monitor’s configuration. In this case, you can override the IP address or port using the override options described in “Overriding the Target IP Address or Protocol Port Number” on page 402.

Configuring and Applying a Health Method 1. Create a new health monitor and configure its settings for the type of service you are monitoring. If you created the monitor externally with a script, import the script. 2. Apply the monitor to the real server (for Layer 3 checks) or service port. You can apply a health monitor to a server or port in either of the 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 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 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 385.) 6. Enter or select settings for the monitor. 7. Click OK. The new monitor appears in the Health Monitor table.

390 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method To import an externally configured monitor 1. Create a script for the monitor. (For an example, see “Using External Health Methods” on page 428.) 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 1. Select Config > Service > SLB. 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 361.) 6. Click OK. To apply a health monitor to a real service port template 1. Select Config > Service > SLB. 2. On the menu bar, select Template > Server Port. 3. To edit an existing template, click on the template name. To create a new template, click Add. The Server Port Template section appears. 4. Select the health monitor from the Health Monitor drop-down list.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

391 of 960

AX Series - Configuration Guide Configuring and Applying a Health Method 5. Configure other settings if needed. (See “Server and Port Templates” on page 361.) 6. Click OK. To apply the monitor to an individual real server or service port 1. Select Config > Service > SLB. 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 1. Select Config > Service > SLB. 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 406.)

392 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method

USING THE CLI To configure an internal monitor 1. Use the following command at the global configuration level of the CLI: health monitor monitor-name [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 385. 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 428.) 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, name (if required), and directory path. You can enter the entire URL on the command line or press Enter to display a prompt for each part of the URL. If you enter the entire URL and a is required, you will still be prompted for the . To enter the entire URL: tftp://host/program-name ftp://[@]host[:port]/program-name s://[@]host/program-name r://[@]host/program-name

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

393 of 960

AX Series - Configuration Guide Configuring and Applying a Health Method 3. Create a new health monitor to use the script by entering the following command at the global config level: health monitor monitor-name 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 ed 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.

394 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method 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 T and UDP health monitors or configure new health monitors. This example uses the default T 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 73.

Note:

USING THE GUI To configure a Layer 3 health method targeted to a virtual IP address: 1. Select Config > Service > Health Monitor. 2. Select Health Monitor on the menu bar. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

395 of 960

AX Series - Configuration Guide Configuring and Applying a Health Method

USING THE CLI To configure a Layer 3 health method targeted to a virtual IP address: Use the following commands: health monitor monitor-name [interval seconds | retry number | timeout seconds] 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 1. Select Config > Service > Health Monitor. 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.

396 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method 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: [no] health monitor monitor-name [interval seconds] [retry number] [timeout seconds] [up-retry num]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

397 of 960

AX Series - Configuration Guide Configuring and Applying a Health Method 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}] [name 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}] [name 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

398 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method 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 es the health check. By default, the expect list is empty, in which case the AX device expects status code 0 (No error condition). • Recursion setting (enabled or disabled) – Recursion specifies whether

the tested DNS server is allowed to send the health check’s request to another DNS server if the tested server can not fulfill the request using its own database. Recursion is enabled by default. • Record type expected from the server – You can specify one of the fol-

lowing record types: • A – IPv4 address record • CNAME – Canonical name record for a DNS alias • SOA – Start of authority record • PTR – Pointer record for a domain name • MX – Mail Exchanger record • TXT – Text string • AAAA – IPv6 address record P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

399 of 960

AX Series - Configuration Guide Configuring and Applying a Health Method By default, the AX device expects the DNS server to respond to the health check with an A record.

USING THE GUI 1. Select Config > Service > Health Monitor. 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 ing 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.

400 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method FIGURE 126

DNS Health

USING THE CLI To configure a DNS health monitor, use the following commands: [no] health monitor monitor-name [interval seconds] [retry number] [timeout seconds] [up-retry num] This command creates the health monitor, but does not configure the health method used by the monitor. If you enter the monitor-name without entering any other options, the CLI changes to the configuration level for the 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:

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

401 of 960

AX Series - Configuration Guide Configuring and Applying a Health Method [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 server’s configuration. For GSLB service IPs, the AX device sends the health check to the service IP address. For example, if the configuration has a Layer 3 health monitor used by service IPs 192.168.100.100-102, the AX device addresses the health checks those IP addresses. You can specify an override IP address or protocol port number in the health monitor. In this case, the AX device always addresses the health check to the override address or port. This option is particularly useful for testing the health of a remote link, as in the following example.

402 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method 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 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,

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

403 of 960

AX Series - Configuration Guide Configuring and Applying a Health Method 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 1. Select Config > Service > Health Monitor. 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

404 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring and Applying a Health Method The following commands configure a health monitor for the service IPs shown in Figure 127 on page 403, 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-health:monitor)#exit 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 gslb-srvc2 192.168.100.101 AX(config-gslb service-ip)#health-check site1-hm AX(config-gslb service-ip)#exit AX(config)#gslb service-ip gslb-srvc3 192.168.100.102 AX(config-gslb service-ip)#health-check site1-hm

Basing a Port’s Health Status on Another Port’s Health Status You can configure the AX device to base a real port’s health status on the health status of another port number. Both the real port and the port to use for the real port’s health status must be the same type, T 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 T 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, T or UDP.

USING THE CLI Use the following command at the configuration level for the real port: [no] health-check follow-port port-num

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

405 of 960

AX Series - Configuration Guide Service Group Health Checks

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 their health checks, and clients of those sites will be sent to the server. Figure 128 shows an example. FIGURE 128

Service Group Health Checks

In this example, a single server provides content for the following sites: • www.media-rts.com • www.media-tuv.com • www.media-wxyz.com

All sites can be reached on HTTP port 80 on the server. The health check configured on the port in the real server configuration results in the same health status for all three sites. All of them either are up or are down.

406 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Group Health Checks 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 asg each site to a separate service group, and asg 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 their health checks, on the same real port. In this example, a separate HTTP health method is configured for each of the services. The health monitors test the health of a site by sending an HTTP request to a URL specific to the site. In this way, even though the server’s HTTP port is up, a site will fail its health check if the URL requested by its health check is unavailable. Priority of Health Checks Service group health status applies only within the context of the service group. For example, a health check of the same port from another service group can result in a different health status, depending on the resource requested by the health check. Health checks can be applied to the same resource (real server or port) at the following levels: • In a service group that contains the server and port as a member • In a server or server port configuration template that is bound to the

server or port • Directly on the individual server or port

In cases where health checks are applied at multiple levels, they have the following priority: 1. Health check on real server 2. Health check on real server’s port 3. Health check on service group If a health check at the real server level (1) fails, the corresponding real server, real server port, and service group 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

407 of 960

AX Series - Configuration Guide Service Group Health Checks

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)#exit AX(config)#health monitor tuv AX(config-health:monitor)#method http url GET /media-tuv/index.html AX(config-health:monitor)#exit AX(config)#health monitor wxyz AX(config-health:monitor)#method http url GET /media-wxyz/index.html AX(config-health:monitor)#exit

The following commands configure the real server: AX(config)#slb server media-rs 10.10.10.88 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#exit

408 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Disable Following Failed Health Check The following commands configure the service groups: AX(config)#slb service-group qrs t AX(config-slb svc group)#member media-rs:80 AX(config-slb svc group)#health-check qrs AX(config-slb svc group)#exit AX(config)#slb service-group tuv t AX(config-slb svc group)#member media-rs:80 AX(config-slb svc group)#health-check tuv AX(config-slb svc group)#exit AX(config)#slb service-group wxyz t AX(config-slb svc group)#member media-rs:80 AX(config-slb svc group)#health-check wxyz AX(config-slb svc group)#exit

The following commands configure the virtual servers: AX(config)#slb virtual-server media-qrs 192.168.1.10 AX(config-slb vserver)#port 80 http AX(config-slb vserver-vport)#service-group qrs AX(config-slb vserver-vport)#exit AX(config-slb vserver)#exit AX(config)#slb virtual-server media-tuv 192.168.1.11 AX(config-slb vserver)#port 80 http AX(config-slb vserver-vport)#service-group tuv AX(config-slb vserver-vport)#exit AX(config-slb vserver)#exit AX(config)#slb virtual-server media-wxyz 192.168.1.12 AX(config-slb vserver)#port 80 http AX(config-slb vserver-vport)#service-group wxyz AX(config-slb vserver-vport)#exit AX(config-slb vserver)#exit

Disable Following Failed Health Check You can configure the AX device to disable a server, port, or service group if the server, port, or service group fails a health check. This option applies to all servers, ports, or service groups that use the health monitor. When a server, port, or service group is disabled based on this command, the server, port, or service group’s state is changed to disable in the running-config. If you save the configuration while the server, port, or service group is disabled, the state change is written to the startup-config. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

409 of 960

AX Series - Configuration Guide 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 1. Select Config > Service > Health Monitor. 2. On the menu bar, select Health Monitor, if not already selected. 3. Click on the health monitor name or click Add to create a new one. 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 Monitoring 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 client’s traffic to another server and port if necessary. An in-band health check can also mark a port down. In the current release, in-band health monitoring is ed for the following service types: • T • HTTP • HTTPS

410 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide In-Band Health Monitoring 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 T, the standard health check works as follows by default: Every 30 seconds, the AX device sends a connection request (T SYN) to the specified T port on the server. The port es the health check if the server replies to the AX device by sending a T 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 T watches client-server SYN handshake traffic, and increments the following counters if the server does not send a SYN ACK in reply to a SYN: • Retry counter – Each client-server session has its own retry counter. The

AX device increments a session’s retry counter each time a SYN ACK is late. If the retry counter exceeds the configured maximum number of retries allowed, the AX device sends the next SYN for the session to a different server. The AX device also resets the retry counter to 0. You can set the retry counter to 0-7 retries. The default is 2 retries. • Reassign counter – Each real port has its own reassign counter. Each

time the retry counter for any session is exceeded, the AX device 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 es a standard health check. Once the port es 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

411 of 960

AX Series - Configuration Guide In-Band Health Monitoring 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: 1. Select Config > Service > SLB. 2. On the menu bar, select Template > Server Port. 3. Click on the template name or click Add to create a new one. 4. Select Inband Health Check 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.

412 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide In-Band Health Monitoring 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 368.

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-rport)#exit AX(config)#slb server rs1 10.1.1.99 AX(config-real server)#port 80 t AX(config-real server-node port)#template port rp-tmplt2 AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server rs2 10.1.1.100 AX(config-real server)#port 80 t AX(config-real server-node port)#template port rp-tmplt2 AX(config-real server-node port)#exit AX(config-real server)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

413 of 960

AX Series - Configuration Guide 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 the health check. By default, a server or port needs to successfully reply to a given health check only one time in order to 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 es 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 1. Select Config > Service > Health Monitor. 2. Select Health Monitor on the menu bar. 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 Req’d field, enter the number of consecutive times the target must 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.

414 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 server’s health status to “Maintenance”. When a server’s 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 server’s health status to Maintenance. To leave maintenance mode, the server must do one of the following: • Successfully reply to a health check, but without including the mainte-

nance code. In this case, the server’s health status changes to Up. • Fail a health check. In this case, the server’s status changes to Down.

The Maintenance health status applies to server ports and service-group . When a port’s status changes to Maintenance, this change applies to all service-group 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 1. Select Config > Service > Health Monitor. 2. On the menu bar, select Health Monitor, if not already selected. 3. Click on the health monitor name or click Add to create a new one. 4. In the Maintenance Code field, enter the response code to use to trigger the AX device to change the server’s status to Maintenance. 5. When finished configuring the health monitor, click OK.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

415 of 960

AX Series - Configuration Guide 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).

On-Demand Health Checks You can easily test the health of a server or individual service at any time, using the default Layer 3 health monitor (ICMP ping) or a configured health monitor.

USING THE GUI 1. Select Monitor > Service > Health Monitor. 2. Enter the IP address of the server to be tested in the IP Address field. 3. Select the health monitor to use from the Health Monitor drop-down list. 4. To test a specific service, enter the protocol port number for the service in the Port field. 5. Click Start. The status of the server or service appears in the Status message area. Note:

416 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide On-Demand Health Checks

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

417 of 960

AX Series - Configuration Guide 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 server’s HTTP port does not reply to the first health check attempt with the expected string, the AX device immediately marks the port Down. To force the AX device to wait until all retries are unsuccessful before marking a server or port down, enable strict retries. You can enable strict retries on an individual health monitor basis.

USING THE GUI On the configuration page for the health monitor, select the Strictly Retry checkbox.

USING THE CLI Use the following command at the configuration level for the health 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

418 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Globally Changing Health Monitor Parameters

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 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: health global { interval seconds | retry number | timeout seconds | up-retry number } You can change one or more parameters on the same command line. Note:

P e r f o r m a n c e

b y

To change a global parameter back to its factory default, use the health global form of the command and specify the parameter value to use.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

419 of 960

AX Series - Configuration Guide Globally Changing Health Monitor Parameters CLI Example The following command globally changes the default number of retries to 5: AX(config)#health global retry 5

The following command globally changes the timeout to 10 seconds and default number of retries to 4: AX(config)#health global timeout 10 retry 4

Globally Disabling Layer 3 Health Checks Layer 3 health checks (ICMP pings) are enabled by default. For very large deployments (1000 or more servers), A10 Networks recommends disabling the default Layer 3 health check, and using only Layer 4-7 health checks. To globally disable Layer 3 health checks, disable health monitoring in the server templates used to configure the servers. If you did not configure a customized server template, the default server template is used. Note:

If a custom Layer 3 health monitor is enabled on an individual server, the health monitor is still used.

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

420 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Compound Health Monitors Use the following command to disable Layer 3 health monitoring in the template: no health-check CLI Example The following commands disable Layer 3 health monitoring in the default server template: AX(config)#slb template server default AX(config-rserver)#no health-check

Compound Health Monitors 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 ed 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 ed: • 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.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

421 of 960

AX Series - Configuration Guide Compound Health Monitors For example, to construct a health monitor that ANDs two health monitors, use the following syntax: method compound sub hm1 sub hm2 AND This is logically equivalent to the following expression: hm1 & hm2 Note:

In the CLI, you must enter method compound at the beginning, and sub in front of each health-monitor name. In the GUI, do not enter method compound. The GUI automatically enters sub in front of each health monitor name when you select it.

Note:

The equivalent expressions are shown for clarity but are not valid syntax on the AX device. Similarly, to construct a health monitor that ORs two health monitors, use the following syntax: 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 ed 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

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

422 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Compound Health Monitors • 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 monitor’s result will always be Down. For example, if monitor1 gives a result after 2 seconds, but a compound monitor that uses monitor1 times out in 1 second, the resulting health status will always be Down, regardless of the Boolean expression. • 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 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 421.) 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

423 of 960

AX Series - Configuration Guide Compound Health Monitors 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 421.) 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 AX(config-health:monitor)#exit

424 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

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

Displaying Health Status The AX device begins sending health checks to a real server’s IP address and service ports as soon as you finish configuring the server. You can 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 server’s 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

425 of 960

AX Series - Configuration Guide Displaying Health Status To display the health of real servers and service ports: 1. Select Monitor > Service > Server. 2. On the menu bar, select Server. The state of health of each real server is shown by an icon next to the server name. 3. To display more specific health information for a real server’s service ports, click on the server name. Real server health status is also displayed in the real server list displayed by Config > Service > SLB > Server. For information about the real server health state icons, see the “Monitor > Service > Server” section in the “Monitor Mode” chapter of the AX Series GUI Reference.

USING THE CLI To display the health of virtual servers and service ports: Use the following command. The health is shown in the State field. For descriptions of each health state, see the AX Series CLI Reference. show slb virtual-server virtual-server-name [virtual-port-num service-type [group-name]] 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 t 1 server 1:80/Down 0 0

0

0

Virtual Port:1 / service: / state:Unkn port 1 t Persist Source IP:tmpl persist srcip 1 Virtual Port:2 / service: / state:Unkn port 2 t Persist SSL session ID:tmpl persist sslid 1

426 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Displaying Health Status Virtual Port:3 / service: / state:Unkn port 3 t Template t tmpl t 1 Virtual Port:4 / service: / state:Unkn ...

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/t

0

0

0

0

Down

s1:53/udp

0

0

0

0

Down

s1:85/udp

0

0

0

0

Down

s1: Total

0

0

0

0

Down

...

To display health monitoring statistics: Use the following command: show health stat Here is an example: AX#show health stat Health monitor statistics Total run time: 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

P e r f o r m a n c e

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 11/3/2010

427 of 960

AX Series - Configuration Guide 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.

Using External Health Methods 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 ed: • Perl • Shell • Tcl

Utility commands such as ping, ping6, wget, dig, and so on are ed.

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.

428 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Using External Health Methods

USING THE GUI To import an external health-check script onto the AX device: 1. Select Config > Service > Health Monitor. 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: 1. Select Config > Service > SLB. 2. On the menu bar, select Server. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

429 of 960

AX Series - Configuration Guide Using External Health Methods 5. In the Port section: a. If adding a new port, enter the port number in the Port field. b. Select the external health monitor from the Health Monitor field. 6. Click OK.

USING THE CLI To import an external health-check script onto the AX device: Use the following command at the global configuration level: health external import [use-mgmt-port] [description] url To configure an external health monitor: Use the following command at the global configuration level: health monitor monitor-name 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: health-check monitor-name

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 and set the others as fail. TCL script filenames must use the “.tcl” extension.

430 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Using External Health Methods 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 }

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

431 of 960

AX Series - Configuration Guide Using External Health Methods

Perl Script Example For other external scripts (non-Tcl), environment variables are used to the server IP address (HM_SRV_IPADDR) and the port number (HM_SRV_PORT). The script returns 0 as 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

432 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Using External Health Methods

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

433 of 960

AX Series - Configuration Guide Using External Health Methods

434 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Global Server Load Balancing 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 experience by directing

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

435 of 960

AX Series - Configuration Guide 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

436 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 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 ed on this port for both T 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 client’s local DNS server then sends the reply to the client. The client now can access the requested host. In today’s redundant data centers and multiple service provider sites, a host name can reside at multiple data centers or sites, with different IP addresses. When this is the case, the authoritative DNS server for the host sends 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

437 of 960

AX Series - Configuration Guide 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 health checks are preferred. 2. weighted-ip – Service IP addresses with higher istratively assigned weights are used more often than service IP addresses with lower weights. (See “Weighted-IP and Weighted-Site” on page 440.) 3. weighted-site – Sites with higher istratively assigned weights are preferred. Sites with higher istratively assigned weights are used more often than sites with lower weights. (See “Weighted-IP and Weighted-Site” on page 440.) 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. ive-rtt – Services with faster response times to clients are preferred.

438 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview 8. geographic – Services located within the client’s geographic region are preferred. 9. connection-load – Sites that are not exceeding their thresholds for new connections are preferred. 10. num-session – Sites that are not exceeding available session capacity threshold compared to other sites are treated as having the same preference. 11. -preference – The site with the highest istratively 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 istratively 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 440.) 15. round-robin – Sites are selected in sequential order. (See “Tie-Breaker” on page 440.) 16. alias--preference – Selects the DNS CNAME record with the highest istratively set preference. This metric is similar to the 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 es the subset of addresses that the metric’s criteria to the next metric, and so on, to sort (re-order) the list of addresses. The GSLB AX device then replaces the IP address list in the DNS reply with the re-ordered list before sending the reply to the client. The metric order and the configuration of each metric are specified in a GSLB policy. Policies can be applied to GSLB zones and to individual 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:

P e r f o r m a n c e

b y

Metric order does not apply to the alias--preference and weightedalias metrics. When enabled, alias--preference always has high priority.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

439 of 960

AX Series - Configuration Guide 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 metric’s 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.

440 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview GSLB s health check methods for the following services: ICMP (Layer 3 health check), T, 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 381.)

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 467. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

441 of 960

AX Series - Configuration Guide 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 As an extension to geo-location , you can configure GSLB to send a Canonical Name (CNAME) record instead of an Address record in DNS replies to clients. A CNAME record maps a domain name to an alias for that domain. For example, you can configure aliases such as the following for domain “a10.com”, and associate the aliases with different geo-locations: • www.a10.co.cn • www.1.a10.com • ftp.a10.com

If a client’s IP address is within a geo-location associated with www.1.a10.com, GSLB places a CNAME record for www.1.a10.com in the DNS reply to the client. To configure CNAME : • 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--preference and Weighted-alias The Alias 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

442 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

their health checks. • dns addition-mx – Appends MX records in the Additional section in

replies for A records, when the device is configured for DNS proxy or cache mode. • dns best-only – Removes all IP addresses from DNS replies except for

the address selected as the best address by the GSLB policy metrics. • dns cache – Caches DNS replies and uses them when replying to clients,

instead of sending a new DNS request for every client query. • dns cname-detect – For IP addresses that have Canonical Name

(CNAME) records, applies the GSLB policy to the CNAME record instead of the Address record. (This applies only if the CNAME records are for the zone and application requested by the DNS proxy on the GSLB AX device.) • dns external-ip – Returns the external IP address configured for a ser-

vice IP. If this option is disabled, the internal address is returned instead. • dns geoloc-action – Performs the DNS traffic handling action specified

for the client’s geo-location. The action is specified as part of service configuration in a zone. • dns geoloc-alias – Replaces the IP address with its alias configured on

the GSLB AX Series. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

443 of 960

AX Series - Configuration Guide Overview • dns geoloc-policy – Returns the alias name configured for the client’s

geo-location. • dns ip-replace – Replaces the IP addresses with the set of addresses

istratively assigned to the service in the zone configuration. • dns ipv6 – Enables 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 444.) 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.

444 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 zone’s TTL setting is used. By default, the TTL override is not set in either of these places.

Metrics That Require the GSLB Protocol on Site AX Devices AX devices use the GSLB protocol for GSLB management traffic. The 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 • ive-rtt • connection-load • num-session • least-response

The GSLB protocol is required in order to collect the site information provided for these metrics. Note:

P e r f o r m a n c e

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

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

445 of 960

AX Series - Configuration Guide Configuration Overview

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 438). 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 443.) 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.

446 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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 487. 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 487. Each of the following configuration sections shows the CLI and GUI methods for configuration. For complete configuration examples, see “Configuration Examples” on page 514.

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

447 of 960

AX Series - Configuration Guide Configuration Overview 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 381.

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

448 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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: slb server server-name ipaddr 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: health-check monitor-name (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, use the following commands: slb service-group group-name udp Use this command at the global configuration level of the CLI. The 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: slb virtual-server name ipaddr Use this command at the global configuration level of the CLI. The 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: service-group group-name gslb-enable

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

449 of 960

AX Series - Configuration Guide Configuration Overview

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 487.) 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 467 later in this section.)

Enabling / Disabling Metrics To enable or disable a metric, use either of the following methods. Using the GUI 1. Select Config > Service > GSLB. 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 Preference metric and you want this metric to be used first, drag-anddrop the metric to the top of the In Use column.

450 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 6. In the DNS Options section, configure the DNS options, if applicable to your deployment. (For descriptions, see “DNS Options” on page 443 and Table 13, “GSLB Policy Parameters,” on page 502.) 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 -preference metric, enter the following command: AX(config gslb-policy)#-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 443 and Table 13, “GSLB Policy Parameters,” on page 502.) [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 }

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

451 of 960

AX Series - Configuration Guide Configuration Overview

Changing the Metric Order To change the metric order, use either of the following methods. Using the GUI 1. Select Config > Service > GSLB. 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 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 -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 • -preference • bw-cost • capacity • connection-load • geographic • health-check • least-response • num-session • ordered-ip

452 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview • ive-rtt • weighted-ip • weighted-site

Metric order does not apply to the alias--preference or weightedalias metrics.

Note:

Configuring RTT Settings If you are planning to use the active-RTT or ive-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 client’s 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 client’s 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

453 of 960

AX Series - Configuration Guide Configuration Overview • 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 global configuration level of the CLI: [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 domain’s local DNS. The GSLB AX device averages the RTT times of the 5 samples. Single Sample (Single Shot) To take a single sample and use that sample indefinitely, use the single-shot option. This option instructs each site AX device to send a single DNS query to the GSLB local DNS. The single-shot option is useful if you do not want to frequently update the active RTT measurements. For example, if the GSLB domain's clients tend to remain logged on for long periods of time, using the single-shot option ensures that clients are not frequently sent to differing sites based on active RTT measurements.

454 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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 457.) 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 of active RTT. You can adjust the tolerance to any value from 0-100 percent.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

455 of 960

AX Series - Configuration Guide Configuration Overview Enabling Active RTT To enable active RTT, use either of the following methods.

USING THE GUI 1. Select Config > Service > GSLB. 2. On the menu bar, select Policy. 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 domain’s local DNS. The GSLB AX device averages the RTT times of the 5 samples. The active RTT measurements are regularly updated. You can use the samples option to change the number of samples to 1-8.

456 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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 454) 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 domain’s local DNS, and wait 3 seconds (the default) for a reply. The site AX devices will then send their RTT measurements to the GSLB AX device. However, if more than 3 site AX devices fail to send their RTT 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

457 of 960

AX Series - Configuration Guide Configuration Overview • 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. 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.

458 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview

USING THE CLI To configure an IP list using the CLI, use the following command at the global configuration level of the CLI: [no] gslb ip-list list-name 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 761. 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:

ive RTT ive RTT measures the round-trip-time between when the site AX device receives a client’s T connection (SYN) and the time when the site AX device receives acknowledgement (ACK) back from the client for the connection. Enabling ive RTT To enable ive RTT, use either of the following methods.

USING THE GUI 1. Select Config > Service > GSLB. 2. On the menu bar, select Policy. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

459 of 960

AX Series - Configuration Guide Configuration Overview 3. Click on the policy name or click Add to create a new one. 4. Drag-and-drop ive RTT from the Not In Use column to the In Use column. 5. Click the plus sign to display the ive RTT configuration fields. 6. To change sample settings, edit the values in the Samples and Tolerance fields. (These parameters work the same as they do for active RTT. See “Multiple Samples” on page 455 and “Tolerance” on page 455.) 7. Click OK.

USING THE CLI Enter the following command at the configuration level for the GSLB policy: [no] ive-rtt [difference num] [samples num-samples] [tolerance num-percentage] [fail-break] Changing ive RTT Settings for a Site You can adjust ive RTT settings on individual sites. The types of settings used by ive RTT settings are the same as those used for Active RTT. See “Changing Active RTT Settings for a Site” on page 457.

USING THE GUI Note:

In the current release, ive RTT settings for a site cannot be changed using the GUI.

USING THE CLI Use the following command at the configuration level for the site: [no] ive-rtt aging-time minutes | bind-geoloc | limit num | mask {/mask-length | mask-ipaddr} | range-factor num | smooth-factor num

460 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview

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. How Bandwidth Cost Is Measured To compare sites based on bandwidth utilization, the GSLB AX device sends SNMP GET requests for a specified MIB interface object, such as ifInOctets, to each site. • If the SNMP object value has incremented less than or equal to the

bandwidth limit configured for the site, the site is eligible to be selected as the best site. • If the SNMP object value has incremented more than the bandwidth

limit configured for the site, the site is ineligible. The GSLB AX device sends the SNMP requests at regular intervals. Once a site is ineligible, the site can become eligible again at the next interval if the utilization incrementation is below the configured limit minus the threshold percentage. (See below.) Configuration Requirements To use the bw-cost metric, an SNMP template must be configured and bound to each site. The GSLB SNMP template specifies the SNMP version and other information necessary to access the SNMP agent on the site AX device, and the Object Identifier (OID) of the MIB object to request. In addition, the following bw-cost parameters must be configured on each site: • Bandwidth limit – The bandwidth limit specifies the maximum value by

which the requested MIB object can increment, for the site to be eligible for selection as the best site. • Bandwidth threshold – For a site to regain eligibility when bw-cost is

being compared, the SNMP object’s incremental value must be below the threshold-percentage of the limit value. For example, if the limit value is 80000 and the threshold is 90, the limit value must increment by 72000 or less, in order for the site to become eligible again based on bandwidth cost. Once a site again becomes eligible, the SNMP object’s value is again allowed to increment by as much as the bandwidth limit value (80000, in this example). P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

461 of 960

AX Series - Configuration Guide Configuration Overview 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 ed in the GUI. Use the CLI to configure the template, then use the following GUI procedures.

USING THE CLI To Configure a GSLB SNMP Template Use the following commands: [no] gslb template snmp template-name This command adds the template and changes the CLI to the configuration level for the template, where the following template-related commands are available: [no] version {v1 | v2c | v3} The version command specifies the SNMP version running on the site AX device. [no] host ipaddr [no] oid oid-value The host command specifies the IP address of the site AX device. The oid command specifies the interface MIB object to query on the site AX device. Note:

462 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview SNMPv1 / v2c Commands: [no] community community-string The community command specifies the community string required for authentication. SNMPv3 Commands: [no] name name This command specifies the SNMPv3 name 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

463 of 960

AX Series - Configuration Guide Configuration Overview 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 Use the following command at the configuration level for the site: [no] template template-name To Configure the Bandwidth Limit and Threshold on a Site Use the following command at the configuration level for the 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 site’s limit value must not increment more than limit*threshold-percentage. You can specify 0-100. There is no default. To Enable the Bandwidth Cost Metric in a GSLB Policy Use the following command at the configuration level for the policy: [no] bw-cost

464 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

465 of 960

AX Series - Configuration Guide Configuration Overview 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)#name 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 465.

Configuring Alias Preference To configure the Alias Preference metric: 1. At the configuration level for the GSLB service, assign an istrative preference to the DNS CNAME record for the service. 2. At the configuration level for the GSLB policy: • Enable the Alias 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 this feature in the GUI.

USING THE CLI 1. To assign an istrative preference to the DNS CNAME record for a service, use the following command at the configuration level for the service: [no] -preference preference The preference can be 0-255. A higher value is preferred over a lower value. The default is 0 (not set).

466 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 2. To enable the Alias Preference metric, use the following command at the configuration level for the policy: [no] alias--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 The current release does not this feature in 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

467 of 960

AX Series - Configuration Guide Configuration Overview 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 470 • “Manually Configuring Geo-Location Mappings” on page 473

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 client’s 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.

468 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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 ed. If you use bin4 format, the AX

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

469 of 960

AX Series - Configuration Guide Configuration Overview 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.

470 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview

USING THE GUI Configuring the CSV Template 1. Select Config > Service > GSLB. 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 field’s 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

471 of 960

AX Series - Configuration Guide Configuration Overview

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

472 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file

(For information about the use-mgmt-port option, see “Using the Management Interface as the Source for Management Traffic” on page 939.) 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 483.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

473 of 960

AX Series - Configuration Guide Configuration Overview

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 1. Select Config > Service > GSLB. 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.

474 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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 469. 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: Address or name of remote host []?192.168.1.100 name []?2 []?********* 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

475 of 960

AX Series - Configuration Guide Configuration Overview 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 1. Select Config > Service > GSLB. 2. On the menu bar, select Service IP. 3. Click Add. 4. Enter the service name and IP address.

476 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview 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 (T 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: port port-num {t | udp} To enable health monitoring of the service, use the following command: health-check monitor-name

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 site’s 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 gateway health checks again.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

477 of 960

AX Series - Configuration Guide Configuration Overview 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 gateway’s 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 router’s 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 site’s 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.

478 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview

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 device—To 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 controller—To specify the site’s 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 device—To 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 controller—To specify the site’s 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

479 of 960

AX Series - Configuration Guide Configuration Overview 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 the following command: 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 Example—Site 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 = istrative 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.

480 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview

CLI Example—Site 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)#slb server 2.2.2.1 Site-AX(config-real server)#exit Site-AX(config)#slb server 3.3.3.1

On the GSLB controller, the following commands enable gateway health checking for each of the site’s 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)#gateway 2.2.2.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 GSLB-AX(config-slb dev)#gateway 3.3.3.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 s 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 es the health check. It is not required for all ports to 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 T 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

481 of 960

AX Series - Configuration Guide Configuration Overview 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 The current release does not this feature in 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 gslb-srvc2 192.168.20.99 AX(config-gslb service-ip)#port 80 AX(config-gslb service-port)#health-check http AX(config-gslb service-ip)#port 8080 AX(config-gslb service-port)#health-check http AX(config-gslb service-ip)#port 8081 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 481.) 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

482 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview

Configure Sites To configure GSLB sites, use either of the following methods.

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

483 of 960

AX Series - Configuration Guide Configuration Overview 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 476.

Configure a Zone To configure a GSLB zone, use either of the following methods.

USING THE GUI 1. Select Config > Service > GSLB. 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 524.) 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 487.) e. Click OK. f. Repeat for each service. 9. Click OK. The zone appears in the GSLB zone list.

484 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Overview

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 1. Select Config > Service > GSLB. 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 device’s function in the GSLB configuration: • Run GSLB as Controller • Run GSLB as Site SLB Device

If you are planning to use the ive RTT metric, select the ive RTT checkbox to enable collection of ive 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

485 of 960

AX Series - Configuration Guide Configuration Overview 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-ive-rtt] The no-ive-rtt option disables collection of ive RTT data on this site AX device. If you are planning to use the ive RTT metric, do not use this option.

486 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters

GSLB Parameters Table 12 lists the GSLB parameters. TABLE 12 GSLB Parameters Parameter

Description and Syntax

protocol enable

Enables the GSLB protocol. The protocol must be enabled on the GSLB AX device and on the site AX devices.

ed Values

Global GSLB Parameters (Required)

[no] gslb protocol {enable {controller | device [no-ive-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 device’s 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

487 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter policy (Optional)

Description and Syntax 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.

ed 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 site’s services.

The site-name can be up to 31 alphanumeric characters. Default: None

[no] gslb site site-name Config > Service > GSLB > Site zone (Required)

488 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter Active-RTT settings (Optional)

Description and Syntax Configures the following Active RTT options:

ed Values The following values are ed:

• 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 client’s 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 client’s 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

489 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter Handling of DNS queries from the local DNS

Description and Syntax 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.

ed 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 configuration of this option using the GUI. Logging of DNS messages.

Default: Not set

[no] gslb dns logging {both | query | response} Note: The current release does not configuration of this option using the GUI. 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)

Note: The current release does not configuration of this option using the GUI. 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)

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

490 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter

Description and Syntax

ed 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 Config > Service > GSLB > Service-IP 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] Config > Service > GSLB > Service-IP 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 {t | udp} Config > Service > GSLB > Service-IP 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 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 Note: The current release does not configuration of this option using the GUI.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

491 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter

Description and Syntax

ed Values

Site Parameters active-rtt

Configures options for the Active RTT metric.

(Optional)

[no] active-rtt aging-time minutes | bind-geoloc | ignore-count num | limit num | mask {/mask-length | mask-ipaddr} | 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.)

492 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter active-rtt

Description and Syntax

(Optional) (cont.) bw-cost

Configures options for the bw-cost metric:

(Optional)

[no] bw-cost limit limit threshold percentage Config > Service > GSLB > Site - Options

ed 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 specify 1-100. The default is 10. limit – Specifies the maximum amount the SNMP object queried by the GSLB AX device can increment since the previous query, in order for the site to remain eligible for selection as the best site. You can specify 0-2147483647. There is no default. If a site becomes ineligible due to being over the limit, the percentage parameter is used. In order to become eligible for selection again, the site’s limit value must not increment more than limit*threshold-percentage. You can specify 0-100. There is no default. threshold percentage – For a site to regain eligibility when bw-cost is being compared, the SNMP object’s incremental value must be below the threshold-percentage of the limit value.

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 object’s 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.

[no] geo-location location-name

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

493 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter ip-server

Description and Syntax Associates a real server with this site.

(Optional)

[no] ip-server service-name

ed Values Default: None

Config > Service > GSLB > Site - IP Server

ive-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 ive RTT metric. The options are the same as those for active-rtt. (See above.)

See the description for active-rtt, above.

[no] ive-rtt aging-time minutes | bind-geoloc | limit num | mask {/mask-length | mask-ipaddr} | range-factor num | smooth-factor num slb-device (Required)

Config > Service > GSLB > Site - Options 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

494 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter

Description and Syntax

ed Values

SLB Device Parameters -preference (Optional)

Assigns a preference value to the SLB device. If the -preference metric is enabled in the policy and all metrics before this one result in a tie, the SLB device with the highest -preference value is preferred.

You can specify from 0 – 255. Default: 100

[no] -preference num gateway (Optional)

gateway health check (Optional)

max-client (Optional)

ive-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 Config > Service > GSLB > Site - SLB-Device Allows GSLB to use a Layer 3 health monitor to check the health of the SLB device’s gateway. [no] gateway health-check Note: The current release does not configuration of this option using the GUI. Specifies the maximum number of clients for which the GSLB AX device (controller) saves data such as active and ive RTT measurements. [no] max-client number Config > Service > GSLB > Site - SLB-Device For ive 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] ive-rtt-timer num To prevent samples from being taken for this device, use the no ive-rtt-timer command. Config > Service > GSLB > Site - SLB-Device 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.)

Config > Service > GSLB > Site - SLB-Device

Default: None

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

495 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter

Description and Syntax

ed 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)

496 of 960

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 Config > Service > GSLB > Zone - Click Add on 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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter dns-soa-record (Optional)

Description and Syntax 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.

ed 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

Note: The current release does not configuration of this option using the GUI. Applies a GSLB policy to the zone.

(Optional)

[no] policy policy-name Config > Service > GSLB > Zone See “Policy Parameters” on page 502.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

The policy-name can be up to 31 alphanumeric characters. Default: The “default” GSLB policy is used, unless you configure another policy and apply it to the zone.

497 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter service (Required)

Description and Syntax 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.

ed 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 443.) ttl seconds [no] Config > Service > GSLB > Zone The health check must be assigned to the individual service. See “Service Parameters” below.

Service Parameters action

Specifies the action to perform for DNS traffic.

You can specify one of the following:

(Optional)

Note: Use of the actions configured for services also must be enabled in the GSLB policy, using the DNS action option. See Table 13, “GSLB Policy Parameters,” on page 502.

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

498 of 960

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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter dns-a-record (Optional)

Description and Syntax 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} Config > Service > GSLB > Zone - Click Add in the 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.

ed 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 ...] Config > Service > GSLB > Zone - Click Add in the Service section to display the DNS CName Record section.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

Default: None Default: None

499 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter dns-mx-record (Optional)

Description and Syntax 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 Config > Service > GSLB > Zone - Click Add on 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] Config > Service > GSLB > Zone - Click Add on 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 Config > Service > GSLB > Zone - Click Add on 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 Note: The current release does not configuration of this option using the GUI. Maps an alias to the specified geographic location for this service. [no] geo-location location-name alias url Config > Service > GSLB > Zone - Click Add in the Service section to display the Geo-location section. This CNAME overrides any CNAME globally configured for the zone.

500 of 960

ed 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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 12 GSLB Parameters (Continued) Parameter ip-order (Optional)

Description and Syntax Specifies the order in which to list the service IP addresses (VIPs) for this service in the DNS replies to clients.

ed 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

Config > Service > GSLB > Zone - Click Add in the 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 alphanumeric characters.

Config > Service > GSLB > Zone - Click Add in the 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

501 of 960

AX Series - Configuration Guide GSLB Parameters

Policy Parameters Table 13 lists the GSLB policy parameters. TABLE 13 GSLB Policy Parameters Parameter

Description and Syntax

ed 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] [samples num-samples] [single-shot] [skip count] [timeout seconds] [tolerance num-percentage] Config > Service > GSLB > Policy - Metrics

active-servers

-preference

502 of 960

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

The state is one of the following: • 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] Config > Service > GSLB > Policy - Metrics Load balancing metric that selects the service with the highest istratively set preference.

• Disabled – This is the default.

[no] -preference Config > Service > GSLB > Policy - Metrics

• Disabled – This is the default.

The state is one of the following: • Enabled The preference can be from 0 to 255. The default is 100 for each site.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter alias--preference

bw-cost

capacity

Description and Syntax Load balancing metric that selects the DNS CNAME record with the highest istratively set preference. This metric is similar to the Preference metric, but applies only to DNS CNAME records. [no] alias--preference Note: The current release does not configuration of this metric in the GUI. Load balancing metric that selects sites based on bandwidth utilization on the site AX links. The fail-break option enables GSLB to stop if the current bw-cost value is over the limit. [no] bw-cost [fail-break] Config > Service > GSLB > Policy - Metrics Sites that have not exceeded their thresholds for their respective maximum T/UDP sessions are preferred over sites that have exceeded their thresholds. Example:

ed Values The state is one of the following: • Enabled • Disabled – This is the default.

The state is one of the following: • Enabled • Disabled – This is the default.

The state is one of the following: • Enabled • Disabled – This is the default. The threshold can be from 0 to 100 percent. The default is 90.

Site A’s maximum session capacity is 800,000 and Site B’s maximum session capacity is 500,000. If the session-capacity threshold is set to 90, then for Site A the capacity threshold is 90% of 800,000, which is 720,000. Likewise, the capacity threshold for Site B is 90% of 500,000, which is 450,000. The fail-break option enables GSLB to stop if the session utilization on all site SLB devices is over the threshold. [no] capacity [threshold num] [fail-break] Config > Service > GSLB > Policy - Metrics 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 445.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

503 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter connection-load

Description and Syntax Sites that are at or below their thresholds of average new connections per second are preferred over sites that are above their thresholds. The fail-break option enables GSLB to stop if the connection load for all sites is over the limit. [no] connection-load [limit average-load] | [samples num interval seconds] [fail-break] Config > Service > GSLB > Policy - Metrics

geographic

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 445.) Service IP addresses for the geographic region where the client is located are preferred over addresses from other regions.

ed Values The state is one of the following: • Enabled • Disabled – This is the default. 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.

The state is one of the following: • Enabled – This is the default. • Disabled

The GSLB AX Series selects the geographic region by matching the client’s IP address with the GSLB address ranges configured using geo-location options.

health-check

[no] geographic Config > Service > GSLB > Policy - Metrics Service IP addresses that their health checks are preferred over addresses that do not their health checks.

The state is one of the following: • Enabled – This is the default. • 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 Config > Service > GSLB > Policy - Metrics Note: This metric requires the GSLB protocol to be enabled on the site AX devices, if the default health checks are used on the service IPs. (See “Health Checks” on page 440.)

504 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter least-response

num-session

Description and Syntax Service IP addresses with the fewest hits are preferred over addresses with more hits.

ed Values The state is one of the following:

[no] least-response Config > Service > GSLB > Policy - Metrics

• Disabled – This is the default.

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

The state is one of the following: • Enabled • Disabled – This is the default. 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] Config > Service > GSLB > Policy - Metrics

ordered-ip

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 445.) Service IP addresses are re-ordered in DNS replies to match the order istratively configured for the service.

The state is one of the following: • Enabled • Disabled – This is the default.

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] Config > Service > GSLB > Policy - Metrics

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

505 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter ive-rtt

Description and Syntax Sites with faster round-trip times (RTTs) between a client and the site are preferred over sites with slower times. The ive RTT is the time between when the site AX device receives a client’s T connection (SYN) and the time when the site AX device receives acknowledgement (ACK) back from the client for the connection. ive RTT measurements are taken for client addresses in each /24 subnet range.

ed Values The state is one of the following: • Enabled • Disabled – This is the default. When you enable the ive-rtt metric, the default number of samples is 5. The default store-by is slb-device. The default tolerance is 10 percent.

ive RTT tolerance is a percentage from 0 to 100. It specifies how much the RTT values of sites must differ in order for GSLB to prefer one site over the other based on RTT. Example: Site A’s RTT value is 0.3 seconds and Site B’s RTT value is 0.32 seconds. If the ive RTT tolerance is 10% then the two sites are treated as having the same ive RTT preference. The fail-break option enables GSLB to stop if the configured RTT limit in a policy is reached. [no] ive-rtt [difference num] [samples num-samples] [tolerance num-percentage] [fail-break] Config > Service > GSLB > Policy - Metrics

round-robin

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

The state is one of the following: • Enabled – This is the default. • Disabled

[no] round-robin Config > Service > GSLB > Policy - Metrics

506 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter weighted-alias

weighted-ip

Description and Syntax 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 configuration of this metric in the GUI. Service IP addresses with higher weight values are used more often than addresses with lower weight values.

ed Values The state is one of the following: • Enabled • Disabled – This is the default.

The state is one of the following: • Enabled • Disabled – This is the default.

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] Config > Service > GSLB > Policy - Metrics 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).

The state is one of the following: • Enabled • Disabled – This is the default.

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] Config > Service > GSLB > Policy - Metrics

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

507 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter metric-order

Description and Syntax 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 ...] Config > Service > GSLB > Policy - Metrics

ed Values You can specify one or more of the following metrics (listed alphabetically): • active-rtt • active-servers • -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 • ive-rtt • weighted-ip • weighted-site Default metric order: See “GSLB Policy” on page 438. The state is one of the following: • Enabled • Disabled – This is the default. The state is one of the following: • Enabled • Disabled – This is the default.

DNS Parameters action

508 of 960

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

The state is one of the following: • Enabled • Disabled – This is the default.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter active-only

addition-mx

backup-alias

best-only

cache

cname-detect

Description and Syntax Removes IP addresses from DNS replies when those addresses fail a health check.

ed Values The state is one of the following:

Note: If none of the IP addresses in the DNS reply the health check, the GSLB AX Series does not use this metric, since it would result in an empty IP address list.

• Disabled – This is the default.

[no] dns active-only Config > Service > GSLB > Policy - DNS Options 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 Config > Service > GSLB > Policy - DNS Options 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 Config > Service > GSLB > Policy - DNS Options Removes all IP addresses from DNS replies except for the address selected as the best address by the GSLB policy metrics.

• Enabled

The state is one of the following: • Enabled • Disabled – This is the default.

The state is one of the following: • Enabled • Disabled – This is the default.

The state is one of the following: • Enabled • Disabled – This is the default.

[no] dns best-only [max-answers] Config > Service > GSLB > Policy - DNS Options Caches DNS replies and uses them when replying to clients, instead of sending a new DNS request for every client query.

The state is one of the following:

[no] dns cache [aging-time seconds | ttl] Config > Service > GSLB > Policy - DNS Options

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

Default: TTL set by the DNS server in the reply

Applies GSLB to CNAME records. [no] dns cname-detect Config > Service > GSLB > Policy - DNS Options

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

• Enabled • Disabled – This is the default.

Note: If you change the value and later want to restore it to the default, use the ttl option. The state is one of the following: • Enabled – This is the default. • Disabled

509 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter external-ip

Description and Syntax Returns the external IP address configured for a service IP. If this option is disabled, the internal address is returned instead.

ed Values The state is one of the following: • Enabled – This is the default. • Disabled

[no] dns external-ip Config > Service > GSLB > Policy - DNS Options

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 487. Performs the DNS traffic handling action specified for the client’s geo-location. The action is specified as part of service configuration in a zone.

The state is one of the following: • Enabled • Disabled – This is the default.

[no] dns geoloc-action Config > Service > GSLB > Policy - DNS Options

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 487. Returns the alias name configured for the client’s geo-location. [no] dns geoloc-alias Config > Service > GSLB > Policy - DNS Options Uses the GSLB policy assigned to the client’s geolocation. [no] dns geoloc-policy Config > Service > GSLB > Policy - DNS Options Replaces the IP addresses in the DNS reply with the service IP addresses configured for the service. [no] dns ip-replace Config > Service > GSLB > Policy - DNS Options

510 of 960

The state is one of the following: • Enabled • Disabled – This is the default. The state is one of the following: • Enabled • Disabled – This is the default. The state is one of the following: • Enabled • Disabled – This is the default.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter ipv6

Description and Syntax Enables for IPv6 AAAA records. You can configure the following options:

ed 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 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 configuration of these options using the GUI.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

511 of 960

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter server

Description and Syntax 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 server’s IP address in the Additional section, when the device is configured for DNS server mode.

ed Values The state is one of the following: • Enabled • Disabled – This is the default. 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] Config > Service > GSLB > Policy - DNS Options For more information on this option, see “Order in Which Sticky, Server, Cache, and Proxy Options Are Used” on page 444.

512 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide GSLB Parameters TABLE 13 GSLB Policy Parameters (Continued) Parameter sticky

Description and Syntax 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. Config > Service > GSLB > Policy - DNS Options 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

For more information on this option, see “Order in Which Sticky, Server, Cache, and Proxy Options Are Used” on page 444. 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.

ed Values The state is one of the following: • Enabled • Disabled – This is the default. 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 Config > Service > GSLB > Policy - DNS Options

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. [no] geo-location location-name start-ip-addr [mask ip-mask] [end-ip-addr] This parameter cannot be configured using the GUI. [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 alphanumeric characters. 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

513 of 960

AX Series - Configuration Guide Configuration Examples

Configuration Examples These examples implement the GSLB configuration shown in Figure 130 on page 436. The examples assume that the default GSLB policy is used, without any changes to the policy settings.

CLI Example Configuration on the GSLB AX Device (GSLB Controller) The following commands configure a health monitor for the local DNS server to be proxied: AX-Controller(config)#health monitor dns-53 AX-Controller(config-health:monitor)#method dns domain example.com AX-Controller(config-real server)#exit

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

The following commands configure the service IP addresses. The VIP address and virtual port number of the virtual server in the site AX Series device’s SLB configuration are used as the service IP address and port 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 t 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 t 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

514 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples 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 client’s IP address is in the range for the China geo-location, GSLB sends the CNAME www.a10.co.cn in the DNS reply. The following command enables the GSLB protocol: AX-Controller(config)#gslb protocol enable controller

Configuration on Site AX Device AX-A The following commands configure SLB on site AX device AX-A in Figure 130 on page 436: Site-AX-A(config)#slb server www 2.1.1.2 Site-AX-A(config-real server)#port 80 t 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 t Site-AX-A(config-real server-node port)#exit Site-AX-A(config-real server)#exit Site-AX-A(config)#slb service-group www t 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

515 of 960

AX Series - Configuration Guide Configuration Examples 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 t 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 t Site-AX-B(config-real server-node port)#exit Site-AX-B(config-real server)#exit Site-AX-B(config)#slb service-group www t 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 1. Select Config > Service > Health Monitor. 2. On the menu bar, select Health Monitor. 3. Click Add. 4. Enter a name for the monitor in the Name field.

516 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples 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 d 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 518.) 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 server’s real IP address in the Server field, and enter the DNS port number in the port field. d. Click Add. The DNS port appears in the list. (See Figure 133 on page 518.) 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 519.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

517 of 960

AX Series - Configuration Guide Configuration Examples 3. Finish configuration of the proxy: a. Click OK. The Proxy section reappears. (See Figure 135 on page 519.) b. Click OK. The DNS proxy appears in the DNS Proxy table. (See Figure 136 on page 519.) FIGURE 132

Configure > Service > GSLB > DNS Proxy

FIGURE 133 Configure > Service > GSLB > DNS Proxy - service group configuration

518 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples

P e r f o r m a n c e

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 11/3/2010

519 of 960

AX Series - Configuration Guide Configuration Examples Load the IANA Geo-location Database 1. Select Config > Service > GSLB. 2. On the menu bar. select Geo-location > Import. 3. In the Load/Unload section, enter “iana” in the File field. Leave the Template field blank. 4. Click Add. Configure Services 1. Select Config > Service > GSLB. 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 (T or UDP). b. Optionally, select a health monitor. c. Click Add. The service port appears in the service port list. For this example, add T port 80 and leave the health monitor unselected. (See Figure 137 on page 521.) 7. Click OK. 8. Repeat for each service IP.

520 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples FIGURE 137

Config > Service > GSLB > Service IP

Configure Sites 1. Select Config > Service > GSLB. 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.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

521 of 960

AX Series - Configuration Guide Configuration Examples • 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

522 of 960

Configure > Service > GSLB > Site - SLB Device

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples FIGURE 139

Configure > Service > GSLB > Site - site parameters selected

Configure a Zone 1. Select Config > Service > GSLB. 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 524.) The service configuration sections appear. 6. In the Service field, enter the service name. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

523 of 960

AX Series - Configuration Guide Configuration Examples 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 487.) e. Click OK. f. Repeat for each service. 9. Click OK. The zone appears in the GSLB zone list. FIGURE 140

524 of 960

Configure > Service > GSLB > Zone

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Examples FIGURE 141

Configure > Service > GSLB > Zone

Enable the GSLB Protocol 1. Select Config > Service > GSLB. 2. On the menu bar, select Global. 3. Select Enabled next to Run GSLB as Controller. 4. Click OK.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

525 of 960

AX Series - Configuration Guide Configuration Examples

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: 1. Select Config > Service > GSLB. 2. On the menu bar, select Global. 3. Select Enabled next to Run GSLB as Site SLB Device. 4. Click OK.

526 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

RAM Caching You can use the AX device as a transparent cache server, along with the device’s many other uses.

Overview The RAM Cache is a high-performance, in-memory Web cache that by default caches HTTP responses (RFC 2616 compliant). The RAM Cache can store a variety of static and dynamic content and serve this content instantly and efficiently to a large number of s. 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 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 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

527 of 960

AX Series - Configuration Guide Overview However, if there is no Content-Length header, the response will not be cached. Warning headers are not ed.

If-Modified-Since Header The AX device s 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.

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, 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 for the headers.

528 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Insertion of Age and Via Headers into Cached Responses RAM caching s 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

529 of 960

AX Series - Configuration Guide 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 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 s 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 s 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 s that request it. • The response is usable by only a single but the 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 s 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

530 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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”.

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

USING THE GUI To Configure RAM Caching 1. Select Config > Service > Template. 2. On the menu bar, select Application > RAM Caching. 3. Click on the template name or click Add to create a new one. 4. Enter a name for the template, if you are creating a new one. 5. Enter or change any settings for which you do not want to use the default settings.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

531 of 960

AX Series - Configuration Guide Configuring RAM Caching 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: a. In the URI field, enter the portion of the URI string to match on. b. Select No Cache from the Action drop-down list. c. Click Add. To configure an invalidate policy: a. In the URI field, enter the portion of the URI string to match on. 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.

532 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring RAM Caching 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 for the following Cache-Control headers: • Cache-Control: no-cache • Cache-Control: max-age=0

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

533 of 960

AX Series - Configuration Guide Configuring RAM Caching • 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 530.) [no] replacement-policy LFU This command specifies the policy used to make room for new objects when the RAM cache is full. The policy ed 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 ed option in the current release.

534 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring RAM Caching 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 ed in RAM Caching policies. For example, if the string pattern contains “*”, it is interpreted literally, as the “*” character.

Note:

Host Verification Command [no] -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: P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

535 of 960

AX Series - Configuration Guide Configuring RAM Caching 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 T 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-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server 192.168.90.35 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#port 443 t AX(config-real server-node port)#exit AX(config-real server)#exit

536 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring RAM Caching 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 AX(config-slb service group)#member 192.168.90.34:443 AX(config-slb service group)#member 192.168.90.35:80 AX(config-slb service group)#member 192.168.90.35:443

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)#port 80 http 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 -------------------------------------------T Established 4328 T Half Open 39026 UDP 0 Non T/UDP IP sessions 0 Other 0 Reverse NAT T 0 Reverse NAT UDP 0 Free Buff Count 0 Curr Free Conn 1923655 Conn Count 5287134 Conn Freed 5113720 t syn half open 0 Prot Forward Source Forward Dest Reverse Source Reverse Dest Age --------------------------------------------------------------------------------------T 10.10.10.61:25058 10.10.10.10:80 * * 600 T 10.10.10.60:9239 10.10.10.11:80 * * 600 T 10.10.10.61:1838 10.10.10.10:80 * * 600 T 10.10.10.65:47834 10.10.10.11:80 * * 600 T 10.10.10.62:55613 10.10.10.11:80 * * 600 T 10.10.10.57:9233 10.10.10.11:80 * * 600

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

537 of 960

AX Series - Configuration Guide Configuring RAM Caching The following command shows RAM caching statistics. AX(config-slb virtual server-slb virtua...)#show slb cache Total --------------------------------------------------------------Cache Hits

0

Cache Misses

6

Memory Used

27648

Bytes Served

0

Entries Cached

6

Entries Replaced

0

Entries Aged Out

0

Entries Cleaned

0

Total Requests

0

Cacheable Requests

0

No-cache Requests

0

No-cache Responses

0

IMS Requests

0

304 Responses

0

Revalidation Successes

0

Revalidation Failures

0

Policy URI nocache

0

Policy URI cache

0

Policy URI invalidate

0

Content Too Big

0

Content Too Small

0

Srvr Resp - Cont Len

220

Srvr Resp - Chnk Enc

37

Srvr Resp - 304 Status

0

Srvr Resp - Other

0

Cache Resp - No Comp

383579

Cache Resp - Gzip

0

Cache Resp - Deflate

0

Cache Resp - Other

0

Entry create failures

0

538 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring RAM Caching 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?=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 s and therefore should be cached, so long as the content is current. However, the /private URI contain private data for a specific , 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

539 of 960

AX Series - Configuration Guide Configuring RAM Caching 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”.

540 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 ed only on AX devices that are deployed in route mode. Active-Standby is ed on AX devices deployed in transparent mode or route mode. Note:

P e r f o r m a n c e

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

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

541 of 960

AX Series - Configuration Guide Overview

Layer 3 Active-Standby HA Figure 142 shows an example of an Active-Standby configuration. FIGURE 142

542 of 960

Active-Standby HA

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview In this example, each AX device provides SLB for two virtual servers, VIP1 and VIP2. Each AX device has the following HA configuration elements: • HA ID – The HA ID of AX1 is 1 and the 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 559.) • 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 of the HA group. Each HA group must be configured with a priority. The priority can be used as a tie breaker to select the Active AX device for a VIP. Each HA group has a shared MAC address, 021f.a0000.00xx. The xx portion of the address is unique to the HA group. The shared MAC address is used for all IP addresses for which HA is provided (SLB VIPs, source NAT addresses, the floating IP address, and so on). • Session synchronization – Also called connection mirroring, session

synchronization sends information about active client sessions to the Standby AX device. If a failover occurs, the client sessions are maintained without interruption. (For a complete list of configurable HA parameters, see “HA Configuration Parameters” on page 564.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

543 of 960

AX Series - Configuration Guide 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.

544 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

545 of 960

AX Series - Configuration Guide Overview

Layer 2 Active-Standby HA (Inline Deployment) AX devices 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 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 ed 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.

546 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview Each real server is connected to the router pair through a Layer 2 switch. Neither the Layer 2 switches nor the routers are running Spanning Tree Protocol (STP). The network does not have any Layer 2 loops because the Layer 2 switches are not connected directly together, and the routers do not forward Layer 2 traffic. If a pair of AX switches in transparent mode are added, the AX switches can add redundant Layer 2 paths, which cause Layer 2 loops. To prevent loops in this deployment, without making any configuration changes on the other devices in the network, you can enable HA inline mode on the AX devices. Inline mode automatically blocks redundant paths through the Standby AX device, without the need to enable STP on any devices.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

547 of 960

AX Series - Configuration Guide Overview FIGURE 145

Layer 2 Inline HA Deployment

Restrictions • ed for Active-Standby HA deployments only. Not ed 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.

548 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview • In order to prevent Layer 2 loops in a Layer 2 host-standby environ-

ment, the Standby AX does not forward traffic. In addition, the Active AX in the HA pair is designed to not forward packets destined for the Standby AX. Depending on the network topology, certain traffic to the Standby AX might be dropped if it must first 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 548, Ethernet interface 5 on each AX has been configured as the preferred HA port. The AX selects the Active AX device’s preferred HA port as follows: 1. Is a preferred port specified with the inline configuration, and is the port up? If so, use the port. 2. If no preferred HA port is specified in the configuration or that port is down, the first HA interface that comes up on the AX is used as the preferred HA port. 3. If the preferred HA port selected by 1. or 2. above goes down, the HA interface with the lowest port number is used. If that port also goes down, the HA interface with the next-lowest port number is used, and so on. HA heartbeat messages are not restricted to the preferred HA port. Heartbeat messages are sent out all HA interfaces unless you disable the messages on specific interfaces. Note:

P e r f o r m a n c e

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 11/3/2010

549 of 960

AX Series - Configuration Guide Overview

Port Restart When a transition from Standby to Active occurs because the formerly Active AX device becomes unavailable, the other devices that are directly connected to the unavailable AX detect that their links to the AX have gone down. The devices then flush their cached MAC entries on the down links. For example, in Figure 145 on page 548, 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 istratively 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.

550 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Layer 3 Active-Standby HA (Inline Deployment) Inline mode HA is also ed 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 shows an example. 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

551 of 960

AX Series - Configuration Guide Overview Normally, this topology would introduce a traffic loop. However, the HA inline mode prevents loops by logically blocking through traffic on the standby AX device. Spanning Tree Protocol (STP) is not required in order to prevent loops. A dedicated link between the AX devices is used for HA management traffic. In this example, the dedicated link is in another subnet. Comparison to Layer 2 Inline Mode Layer 3 inline configuration is similar to Layer 2 inline mode configuration, with the following exceptions: • Layer 3 inline mode does not require designation of a preferred port or

configuration of port restart. • U processing must be enabled on the Ethernet interfaces that will

receive server replies to client requests. U processing is required on these interfaces in order to change the source IP address from the server’s real IP address back into the VIP address. Restrictions • ed for Active-Standby HA deployments only. Not ed 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 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

552 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

HA Heartbeat Messages Each of the AX devices regularly sends HA heartbeat messages out its HA interfaces. The Standby AX device listens for the heartbeat messages. If the Standby AX device stops receiving heartbeat messages from the Active AX device, the Standby AX device transitions to Active and takes over networking and SLB operations from the other AX device. By default, heartbeat messages are sent every 200 milliseconds. If the Standby AX device does not receive a heartbeat message for 1 second (5 times the heartbeat interval), the Standby AX device transitions to Active. The heartbeat interval and retry count are configurable. (See “HA Configuration Parameters” on page 564.)

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

553 of 960

AX Series - Configuration Guide 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 though a Layer 2 switch, the switch must be able to UDP IP multicast packets.

Note:

If a tracked interface is a member of a trunk, only the lead port in the trunk is shown in the tracking configuration and in statistics. For example, if a trunk contains ports 1-3 and you configure tracking of port 3, the configuration will show that tracking is enabled on port 1. Likewise, tracking statistics will show port 1, not port 3. Similarly, if port 1 goes down but port 3 is still up, statistics still will show that port 1 is up since it is the lead port for the trunk. Changes to the state of an HA interface can trigger a failover. By default, the HA state of an interface can be Up or Down. Optionally, you can specify the HA interface type as one of the following: • Server interface – A real server can be reached through the interface. • Router interface – An upstream router (and ultimately, clients) can be

reached through the interface. • Both – Both a server and upstream router can be reached through the

interface. If you specify the HA interface type, the HA status of the AX device is based on the status of the AX link with the real server and/or upstream router. The HA status can be one of the following: • 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.

554 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview • Down – All router interfaces, or all server interfaces, or both are down.

The status also is Down if both router interfaces and server interfaces are not configured and an HA interface goes down. If both types of interfaces (router interfaces and server interfaces) are configured, the HA interfaces for which a type has not been configured are not included in the HA interface status determination. During selection of the active AX, the AX with the highest state becomes the active AX and all HA interfaces on that AX become active. For example, if one AX is UP and the other AX is only Partially Up, the AX that is UP becomes the active AX. If each AX has the same state, the active AX is selected as follows: • If HA pre-emption is disabled (the default), the first AX to come up is

the active AX. • If HA pre-emption is enabled, the AX with the higher HA group priority

becomes active for that group. If the group priorities on the two AX devices are also the same, the AX that has the lowest HA ID (1 or 2) becomes active. 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 NATted ICMP sessions or to any static NAT sessions. Synchronization of these sessions is not needed since the newly Active AX device will create a new flow for the session following failover. To enable session synchronization, see “Enabling Session Synchronization” on page 603.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

555 of 960

AX Series - Configuration Guide Overview Session synchronization is required for config sync. Config sync uses the session synchronization link. (For more information, “Synchronizing Configuration Information” on page 606.) Note:

Session synchronization is also called “connection mirroring”.

Optional Failover Triggers In addition to HA interface-based failover, you can configure failover based one any of the following: • Inactive VLAN (VLAN-based failover) • Unresponsive gateway router (gateway-based failover) • Unresponsive real servers (VIP-based failover)

VLAN-based Failover You can enable HA checking for individual VLANs. When HA checking is enabled for a VLAN, the active AX device in the HA pair monitors traffic activity on the VLAN. If there is no traffic on the VLAN for half the duration of a configurable timeout, the AX device attempts to generate traffic by issuing ping requests to servers if configured, or broadcast ARP requests through the VLAN. If the AX device does not receive any traffic on the VLAN before the timeout expires, a failover occurs. The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default, A10 recommends trying 30 seconds. This HA checking method provides a ive 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 596.

Gateway-based Failover Gateway-based failover uses ICMP health monitors to check the availability of the gateways. If any of the active AX device’s gateways fails a health check, the AX device changes its HA status to Down. If the HA status of the other AX device is higher than Down, a failover occurs.

556 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview Likewise, if the gateway becomes available again and all gateways their health checks, the AX device recalculates its HA status according to the HA interface counts. If the new HA status of the AX device is higher than the other AX device’s HA status, a failover occurs. Configuration of gateway-based failover requires the following steps: 1. Configure a health monitor that uses the ICMP method. 2. Configure the gateway as an SLB real server and apply the ICMP health monitor to the server. 3. Enable HA checking for the gateway. For a configuration example, see “Gateway-Based Failover Example” on page 597.

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 ed in this release (static and OSPF). If the priority of an HA group falls below the priority for the same group on the other AX device in an HA pair, a failover can be triggered. Notes • This feature applies only to routes in the data route table. The feature

does not apply to routes in the management route table. • For failover to occur due to HA priority changes, the HA pre-emption

option must be enabled. For a configuration example, see “Route-Based Failover Example” on page 599.

Real Server or Port Health-based Failover You can configure the AX device to decrease the HA priority of an HA group, if a real server or port’s health status changes to Down.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

557 of 960

AX Series - Configuration Guide Overview You can configure this feature on individual real servers and ports. The feature is disabled by default. To enable the feature, assign an HA weight to the server or port. If the server or port’s health status changes to Down, the weight value is subtracted from the priority value of the HA group. You can specify a single HA group or allow the priority change to apply to all HA groups. If the server or port’s status changes back to Up, the weight value is added back to the HA group’s priority value. If the HA priority of a group falls below the priority of the same group on the other AX device, HA failover can be triggered. Notes • The lowest HA priority value a server or port can have is 1. • If HA weights for an HA group are assigned to both the server and an

individual port, and both health checks are unsuccessful, only the server weight is subtracted from the HA group’s priority. • For failover to occur due to HA priority changes, the HA pre-emption

option must be enabled.

VIP-based Failover VIP-based failover allows service for a VIP to be transferred from one AX device in an HA pair to the other AX device based on HA status changes of the real servers. When you configure an HA group ID, you also specify its priority. If HA pre-emption is enabled, the HA group’s priority can be used to determine which AX device in the HA pair becomes the Active AX for the HA group. In this case, the AX device that has a higher value for the group’s priority becomes the Active AX device for the group. If you enable the dynamic HA option on a virtual server, the AX device reduces the HA priority of the group assigned to the virtual server, if a real server becomes unavailable. (A real server is unavailable if it is marked Down by the AX device because the server failed its health check.) If the priority value is reduced to a value that is lower than the group’s priority value on the other AX device in the HA pair, and HA pre-emption is enabled, service of the virtual serve is failed over to the other AX device. When a real server becomes available again, the weight value that was subtracted from the HA group’s priority is re-added. If this results in the priority value being higher than on the other AX device, the virtual server is

558 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview failed over again to the AX device with the higher priority value for the group. 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 601.

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

P e r f o r m a n c e

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 11/3/2010

559 of 960

AX Series - Configuration Guide 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.

560 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview FIGURE 148

P e r f o r m a n c e

b y

HA Failover

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

561 of 960

AX Series - Configuration Guide Overview

HA Pre-Emption By default, a failover occurs only in the following cases: • The Standby AX device stops receiving HA heartbeat messages form

the other AX device in the HA pair. • HA interface state changes give the Standby AX device a better HA

state than the Active AX device. (See “HA Interfaces” on page 554.) • VLAN-based failover is configured and the VLAN becomes inactive.

(See “VLAN-based Failover” on page 556.) • Gateway-based failover is configured and the gateway becomes unavail-

able. (See “Gateway-based Failover” on page 556.) • VIP-based failover is configured and the unavailability of real servers

causes the Standby AX to have the greater HA priority for the VIP’s HA group. (See “VIP-based Failover” on page 558.) 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:

562 of 960

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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 ed 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 564.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

563 of 960

AX Series - Configuration Guide Overview

HA Configuration Parameters Table 14 lists the HA parameters. TABLE 14 HA Parameters Parameter

Description and Syntax

ed Values

HA ID

HA ID of the AX device, and HA set to which the AX device belongs.

HA ID: 1 or 2

The HA ID uniquely identifies the AX device within the HA pair.

Default: Neither parameter is set

Global HA Parameters and HA set ID

HA set ID: 1-7

The HA set ID specifies the HA set to which the AX device belongs. This parameter is applicable to configurations that use multiple AX pairs. [no] ha id {1 | 2} [set-id num] HA group ID

Config > HA > Setting > HA Global - General Uniquely identifies the HA group on an individual AX device.

HA group ID: 1-31

The priority value can be used during selection of the Active AX device. (See“How the Active AX Device Is Selected” on page 559.)

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

564 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview TABLE 14 HA Parameters (Continued) Parameter HA interfaces

Description and Syntax Interfaces used for HA management.

ed 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 554 and “How the Active AX Device Is Selected” on page 559.) [no] ha interface ethernet port-num [router-interface | server-interface | both] [no-heartbeat | vlan vlan-id]

VLAN-based HA

Config > Network > Interface > LAN - Select the interface and then click HA. Enables the AX device to change its HA status based on the health of a VLAN. When HA checking is enabled for a VLAN, the active AX device in the HA pair monitors traffic activity on the VLAN. If there is no traffic on the VLAN for half the duration of a configurable timeout, the AX device attempts to generate traffic by issuing ping requests to servers if configured, or broadcast ARP requests through the VLAN.

Valid VLAN ID Default: not set The timeout can be 2-600 seconds. Although there is no default timeout, A10 recommends trying 30 seconds.

If the AX device does not receive any traffic on the VLAN before the timeout expires, a failover occurs. [no] ha check vlan vlan-id timeout seconds Gateway-based HA

Config > HA > Setting > HA Global - Status Check Enables the AX device to change its HA status based on the health of a gateway router.

IP address of the gateway

If the gateway fails a Layer 3 (ICMP) health check, the AX device changes its HA status to Down. If the HA status of the other AX device is higher than Down, a failover occurs.

Additional configuration is required. (See “Gateway-based Failover” on page 556.)

Default: not set

[no] ha check gateway ipaddr Config > HA > Setting > HA Global - Status Check

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

565 of 960

AX Series - Configuration Guide Overview TABLE 14 HA Parameters (Continued) Parameter Session synchronization (Also called “connection mirroring”)

Description and Syntax Enables the AX devices to share information about active client sessions. If a failover occurs, client sessions continue uninterrupted. The Standby AX device, when it becomes Active, uses the session information it received from the Active AX device before the failover to continue the sessions without terminating them.

ed Values IP address of the other AX device Default: not set

To enable session synchronization, specify the IP address of the other AX device in the HA pair. Session synchronization does not apply to DNS sessions. Since these sessions are typically very short lived, there is no benefit to synchronizing them. Note: This option also requires session synchronization to be enabled on the individual virtual service ports. (See “HA Parameters for Virtual Service Ports” below.) [no] ha conn-mirror ip ipaddr Pre-emption

Config > HA > Setting > HA Global - General Controls whether failovers can be caused by configuration changes to HA priority or HA ID.

Enabled or disabled Default: disabled

[no] ha preemption-enable HA heartbeat interval

Config > HA > Setting > HA Global - General Interval at which the AX device sends HA heartbeat messages on its HA interfaces. [no] ha time-interval 100-msec-units

Retry count

Config > HA > Setting > HA Global - General Number of HA heartbeat intervals the Standby device will wait for a heartbeat message from the Active AX device before failing over to become the Active AX device.

1-255 units of 100 milliseconds (ms) each Default: 200 ms

2-255 Default: 5

[no] ha timeout-retry-count num ARP repeat count

566 of 960

Config > HA > Setting > HA Global - General Number of additional gratuitous ARPs, in addition to the first ones, an AX sends after transitioning from Standby to Active in an HA configuration. [no] ha arp-retry num Config > HA > Setting > HA Global - General

1-255 Default: 4 additional gratuitous

ARPs, for a total of 5

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview TABLE 14 HA Parameters (Continued) Parameter Forced failover

Layer 2/3 forwarding of Layer 4 traffic on the Standby AX device

Description and Syntax Forces HA groups to change from Active to Standby status. [no] ha force-self-standby [group-id] Note: This option provides a simple method to force a failover, without the need to change HA group priorities and enable pre-emption. The option is not added to the configuration and does not persist across reboots. Note: The current release does not 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 configuration of this parameter using the GUI.

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

AX Ethernet interfaces Default: not set

[no] ha restart-port-list ethernet port-list Port restart time

Config > HA > Setting - HA Inline Mode Amount of time interfaces in the restart port list remain disabled following a failover. [no] ha restart-time 100-msec-units

1-100 units of 100 milliseconds (ms) Default: 20 units of 100 ms (2 seconds)

Config > HA > Setting - HA Inline Mode

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

567 of 960

AX Series - Configuration Guide Overview TABLE 14 HA Parameters (Continued) Parameter

Description and Syntax

ed Values

Global HA Parameters for Layer 3 Inline Mode Inline mode state

OSPF on Standby AX device

Enables Layer 3 inline mode.

Enabled or disabled

[no] ha l3-inline-mode

Default: disabled

Config > HA > Setting - HA Inline Mode Leaves OSPF enabled on the Standby AX device.

Enabled or disabled

[no] ha ospf-inline vlan vlan-id Note: This option is not configurable using the GUI.

Default for all HA modes except Layer 3 inline: disabled. OSPF is disabled on the Standby AX device. Default for Layer 3 inline mode: enabled. OSPF is allowed to run on all VLANs by default. 100 milliseconds (ms) to 10000 ms, in increments of 100 ms Default: 3000 ms (3 seconds)

Link event delay

Change the delay waited by the AX device before changing the HA state (Up, Partially Up, or Down) in response to link-state changes on HA interfaces. [no] ha link-event-delay 100-ms-unit Config > HA > Setting - HA Inline Mode

HA group ID

HA group ID for a virtual server.

1-31

This is required to enable HA for the VIP.

Default: not set

HA Parameters for Virtual Servers

[no] ha-group group-id Server weight

Config > Service > SLB > Virtual Server Weight value assigned to real servers bound to the virtual server.

1-255 Not set

The weight is used for VIP-based failover. (See “VIP-based Failover” on page 558.) [no] ha-dynamic server-weight

Link event delay

568 of 960

Config > Service > SLB > Virtual Server - Select the HA group, then select the Dynamic Server Weight. Change the delay waited by the AX device before changing the HA state (Up, Partially Up, or Down) in response to link-state changes on HA interfaces. [no] ha link-event-delay 100-ms-unit Config > HA > Setting - HA Inline Mode

100 milliseconds (ms) to 10000 ms, in increments of 100 ms Default: 3000 ms (3 seconds)

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview TABLE 14 HA Parameters (Continued) Parameter

Description and Syntax

ed Values

HA Parameters for Virtual Service Ports Session synchronization

Enables active client sessions on this virtual port to continue uninterrupted following a failover.

(Also called “connection mirroring”)

Note: This option also requires session synchronization to be enabled globally. (See “Global HA Parameters” above.)

Enabled or disabled Default: disabled

[no] ha-conn-mirror Config > Service > SLB > Virtual Server - Port

HA Parameters for Real Servers Priority cost

Decreases the HA priority of an HA group, if the real server’s health status changes to Down. [no] ha-priority-cost weight [ha-group group-id] Note: The current release does not configuration of this option using the GUI.

Weight: 1-255 HA group: 1-31. If no group is specified, the weight applies to all HA groups. Default: not set

HA Parameters for Real Ports Priority cost

Decreases the HA priority of an HA group, if the real port’s health status changes to Down. [no] ha-priority-cost weight [ha-group group-id] Note: The current release does not configuration of this option using the GUI.

Weight: 1-255 HA group: 1-31. If no group is specified, the weight applies to all HA groups. Default: not set

HA Parameters for Firewall Load Balancing (FWLB) Note: For an example of an FWLB HA configuration, see “Firewall Load Balancing” on page 333. HA group ID HA group ID for a virtual firewall or virtual firewall 1-31 port. Default: not set [no] ha-group group-id Config > Service > Firewall > Firewall Virtual Server (for virtual firewall)

Session synchronization

Config > Service > Firewall > Firewall Virtual Server - Port (for virtual firewall port) Enables active client sessions on this virtual firewall port to continue uninterrupted following a failover.

Enabled or disabled Default: disabled

Note: This option also requires session synchronization to be enabled globally. (See “Global HA Parameters” above.) [no] ha-conn-mirror Config > Service > Firewall > Firewall Virtual Server (for virtual firewall) Config > Service > Firewall > Firewall Virtual Server - Port (for virtual firewall port)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

569 of 960

AX Series - Configuration Guide Overview TABLE 14 HA Parameters (Continued) Parameter

Description and Syntax

ed Values

HA Parameters for IP Network Address Translation (NAT) Pools HA group ID

HA group ID for IP NAT.

1-31

Option with ip nat pool, ipv6 nat pool, or ip nat inside command: ha-group group-id

Default: not set

Config > Service > IP Source NAT > IPv4 Pool Config > Service > IP Source NAT > IPv6 Pool Config > Service > IP Source NAT > NAT Range

HA Parameters for IP Routes Priority cost

Reduces the HA priority of all HA groups on the AX device, if the specified route is missing from the IPv4 or IPv6 route table.

Default: not set

For IPv4 routes: [no] ha check route destination-ipaddr /mask-length priority-cost weight [gateway ipaddr] [protocol {static | dynamic}] [distance num] For IPv6 routes: [no] ha check route destination-ipv6addr/mask-length priority-cost weight [gateway ipv6addr] [protocol {static | dynamic}] [distance num] Note: The current release does not configuration of this option using the GUI.

570 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide HA Status Indicators

HA Status Indicators The HA status of an AX device is displayed in the GUI and CLI. The HA status indicators provide the following information: • Current HA status of the AX device: Active or Standby • Configuration status: • Most recent configuration update – The system time and date when

the most recent configuration change was made. • Most recent configuration save – The system time and date when the configuration was saved to the startup-config. • Most recent config-sync – The system time and date when the most recent configuration change was made. If the AX device is configured with multiple Role-Based istration (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#

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

571 of 960

AX Series - Configuration Guide 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

Configuring Layer 3 HA To configure Layer 3 HA: 1. Configure the following global HA parameters: • HA ID • HA group ID and priority. For an Active-Standby configuration, configure one group ID. For Active-Active, configure multiple HA group IDs. • Floating IP address (optional) • Session synchronization (optional) • HA pre-emption (optional) 2. Configure the HA interfaces. 3. Add each virtual server to an HA group. 4. If session synchronization is globally enabled, enable it on the individual virtual ports whose client sessions you want to synchronize. 5. If IP NAT pools are configured, add each pool to an HA group.

572 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

573 of 960

AX Series - Configuration Guide Configuring Layer 3 HA Configuring HA Interfaces 1. Select Config > Network > Interface. 2. On the menu bar, select LAN. The list of the AX device’s physical Ethernet data interfaces appears. 3. Perform the following steps for each HA interface. (For information, see “HA Interfaces” on page 554.) a. Click on the interface number. b. In the HA section, select Enabled next to HA Enabled. c. To specify the interface type, select one of the following or leave the setting None: • Router-Interface • Server-Interface • Both d. To enable HA heartbeat messages, select Enabled next to Heartbeat. e. To restrict the HA heartbeat messages to a specific VLAN, enter the VLAN ID in the VLAN field. f. Click OK. Configuring HA Parameters on a Virtual Server 1. Select Config > Service > SLB. 2. On the menu bar, select Virtual Server. 3. Click on the virtual server name or click Add to add a new one. 4. In the General section, select the HA group ID from the HA Group drop-down list. Note:

The Dynamic Server Weight option is used for VIP-based failover. For information, see “VIP-based Failover” on page 558. 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.

574 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA The GUI does not 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

P e r f o r m a n c e

b y

Config > HA > Setting > HA Global

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

575 of 960

AX Series - Configuration Guide Configuring Layer 3 HA 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

576 of 960

Config > Service > Network > LAN (Ethernet interface 1)

Config > Service > SLB > Virtual Server (VIP1)

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA FIGURE 153

Config > Service > SLB > Virtual Server (VIP2)

HA Configuration of AX2 FIGURE 154

P e r f o r m a n c e

b y

Config > HA > Setting

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

577 of 960

AX Series - Configuration Guide Configuring Layer 3 HA FIGURE 155

Config > Service > SLB > Virtual Server (VIP1)

FIGURE 156

Config > Service > SLB > Virtual Server (VIP2)

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

578 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA 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 564.) Commands on AX1 This examples shows the CLI commands to implement the Active-Active configuration shown in Figure 143 on page 544. The following commands configure the HA ID and HA groups. Since this is an Active-Active configuration, both HA groups are configured. The priority for group 1 is set to a low value. The same group will be set to a higher priority value on the other AX device. Likewise, the priority of group 2 is set to a high value on this AX device but will be set to a lower value on the other AX device. Later in the configuration, each virtual server will need to be added to one or the other of the HA groups. AX1(config)#ha id 1 AX1(config)#ha group 1 priority 1 AX1(config)#ha group 2 priority 255

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

The following commands configure the HA interfaces. The interface types are specified, so that the HA state of the AX device can be more precisely calculated based on HA interface state. (See “HA Interfaces” on page 554.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

579 of 960

AX Series - Configuration Guide Configuring Layer 3 HA Heartbeat messages are disabled on all HA interfaces except the dedicated HA link between the AX devices. AX1(config)#ha interface ethernet 1 router-interface no-heartbeat AX1(config)#ha interface ethernet 2 router-interface no-heartbeat AX1(config)#ha interface ethernet 3 server-interface no-heartbeat AX1(config)#ha interface ethernet 4 server-interface no-heartbeat AX1(config)#ha interface ethernet 5

The following command enables session synchronization (connection mirroring). The feature also will need to be enabled on individual virtual ports, later in the configuration. The IP address is the real address of the other AX device. AX1(config)#ha conn-mirror ip 10.10.30.2

The following command enables HA pre-emption, to ensure that the Active and Standby for each virtual server are chosen based on the configuration. By default, when HA is first configured, Active and Standby are selected based on which AX device comes up first. AX1(config)#ha preemption-enable

The following commands add each of the virtual servers to an HA group, and enables session synchronization on the virtual ports. (For brevity, this example does not show the complete SLB configuration, only the HA part of the SLB configuration.) AX1(config)#slb virtual-server VIP1 AX(config-slb virtual server)#ha-group 1 AX(config-slb virtual server)#port 80 t AX(config-slb virtual server-slb virtua...)#ha-conn-mirror AX(config-slb virtual server-slb virtua...)#exit AX(config-slb virtual server)#exit AX1(config)#slb virtual-server VIP2 AX1(config-slb virtual server)#ha-group 2 AX1(config-slb virtual server)#port 80 t AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror AX1(config-slb virtual server-slb virtua...)#exit AX1(config-slb virtual server)#exit

580 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA Commands on AX2 Here are the commands for AX2. The priority values for the groups are different from the values set on AX1, so that group 1 has higher priority on this AX device than on AX1. Likewise, the priority of group 2 is set so that its priority is higher on AX1. AX2(config)#ha id 2 AX2(config)#ha group 1 priority 255 AX2(config)#ha group 2 priority 1

The floating IP addresses must be the same as the ones set on AX1. AX2(config)#floating-ip 10.10.10.1 ha-group 1 AX2(config)#floating-ip 10.10.10.100 ha-group 2 AX2(config)#ha interface ethernet 1 router-interface no-heartbeat AX2(config)#ha interface ethernet 2 router-interface no-heartbeat AX2(config)#ha interface ethernet 3 server-interface no-heartbeat AX2(config)#ha interface ethernet 4 server-interface no-heartbeat AX2(config)#ha interface ethernet 5

The IP address for session synchronization is the address of AX1. AX2(config)#ha conn-mirror ip 10.10.30.1 AX2(config)#ha preemption-enable

The HA configuration for virtual servers and virtual ports is identical to the configuration on AX1. AX2(config)#slb virtual-server VIP1 AX2(config-slb virtual server)#ha-group 1 AX2(config-slb virtual server)#port 80 t AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror AX2(config-slb virtual server-slb virtua...)#exit AX2(config-slb virtual server)#exit AX2(config)#slb virtual-server VIP2 AX2(config-slb virtual server)#ha-group 2 AX2(config-slb virtual server)#port 80 t AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror AX2(config-slb virtual server-slb virtua...)#exit AX2(config-slb virtual server)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

581 of 960

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode)

Configuring Layer 2 HA (Inline Mode) To configure Layer 2 HA: 1. Configure the following global HA parameters: • HA ID • HA group ID and priority. Configure only one group ID. Configure the same ID on both AX devices. • Floating IP address (optional) • Inline mode and optional preferred port • Restart port list and time (optional) • HA interfaces • Session synchronization (optional) • HA pre-emption (optional) 2. Add each virtual server to the HA group. 3. If session synchronization is globally enabled, enable it on the individual virtual ports whose client sessions you want to synchronize. 4. If IP NAT pools are configured, add each pool to the HA group. Note:

If source NAT is not configured for the VIP, but real servers send responses to a gateway IP address other than the AX floating IP address, U 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 U 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 548. In addition to the inline features described in this section, the sample configuration also uses the following HA features: • Identification of HA interface type: server or router – The interface

types affect the AX device’s summary link state for HA. (See “HA Interfaces” on page 554.) • 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

582 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode) default gateway after an HA failover, without the need for the gateway address to be changed to the Standby AX device’s address.

USING THE GUI Configuring Global HA Parameters 1. Select Config > HA > Setting. a. In the General section, select the HA ID for the AX device from the Identifier drop-down list. b. Select Yes next to HA Status. c. To enable pre-emption, select Yes next to Preempt Status. d. To enable connection mirroring, enter the IP address of the other AX device in the HA Mirroring IP Address field. 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 1. Select Config > Network > Interface. 2. On the menu bar, select LAN. The list of the AX device’s physical Ethernet data interfaces appears. 3. Perform the following steps for each HA interface. (For information, see “HA Interfaces” on page 554.) a. Click on the interface number. b. In the HA section, select Enabled next to HA Enabled. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

583 of 960

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode) 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 U 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 U processing is not valid and is not required. g. Click OK. Configuring Inline Parameters 1. Select Config > HA > Setting. 2. Select HA Inline Mode on the menu bar. 3. Select Enabled next to Inline Mode Status. 4. Select the preferred port. 5. In Restart Port List section, select the HA interfaces. 6. Click >> to move them to the Selected list. 7. Click OK. The following GUI screens configure HA on AX1 in Figure 145 on page 548.

584 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode) FIGURE 157

P e r f o r m a n c e

b y

Config > HA > Setting

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

585 of 960

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode) 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

586 of 960

Config > Service > Network > LAN (Ethernet interface 1)

Config > HA > Setting > HA Inline Mode

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode)

USING THE CLI Commands on AX1 The following commands configure the HA ID and set the HA priority. HA priority is associated with an HA group. Since inline mode is ed only in Active-Standby configurations, only one HA group is used. Later in the configuration, the VIP is assigned to this HA group. AX1(config)#ha id 1 AX1(config)#ha group 1 priority 255

The following command enables inline HA mode and specifies the preferred HA port. AX1(config)#ha inline-mode preferred-port 5

The following commands configure the HA interfaces. Each interface that is connected to a server, a router, or the other AX can be configured as an HA interface. Make sure to add the preferred HA port as one of the HA interfaces. AX1(config)#ha interface ethernet 1 router-interface no-heartbeat AX1(config)#ha interface ethernet 2 router-interface no-heartbeat AX1(config)#ha interface ethernet 3 server-interface AX1(config)#ha interface ethernet 4 server-interface AX1(config)#ha interface ethernet 5

The following command enables restart of the HA ports connected to the routers, to occur if the AX transitions to Standby. AX1(config)#ha restart-port-list ethernet 1 to 2

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 u-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 U 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 istrative changes to the HA configuration. (For example, if you change the HA priority so that the other AX has higher priority, this will trigger a failover, but only if pre-emption mode is enabled.) AX1(config)#ha preemption-enable

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

587 of 960

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode) The following command specifies the IP address of the other AX, to use for session synchronization. AX1(config)#ha conn-mirror ip 172.168.10.3

The following command configures the floating IP address for the real servers to use as their default gateway address. AX1(config)#floating-ip 172.168.10.1 ha-group 1

The following commands configure a health method, real servers, a server group, and a VIP for an HTTP service. AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX1(config-health:monitor)#method http url HEAD /index.html AX1(config-health:monitor)#exit AX1(config)#slb server s1 172.168.10.30 AX1(config-real server)#port 80 t AX1(config-real server-node port)#health-check myHttp AX1(config-real server-node port)#exit AX1(config-real server)#exit AX1(config)#slb server s2 172.168.10.31 AX1(config-real server)#port 80 t 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 t AX1(config-slb service group)#member s1:80 AX1(config-slb service group)#member s2:80 AX1(config-slb service group)#exit AX1(config)#slb virtual-server v1 172.168.10.80 AX1(config-slb virtual server)#ha-group 1 AX1(config-slb virtual server)#port 80 t AX1(config-slb virtual server-slb virtua...)#service-group g80 AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror

588 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 2 HA (Inline Mode) Commands on AX2 Here are the commands for implementing HA on the standby AX, AX2. Most of the commands are the same as those on AX1, with the following exceptions: • The HA ID is 2. • The HA priority is 1. • The session synchronization (conn-mirror) IP address is the address of

the Active AX. (On the Active AX, the session synchronization IP address is the address of the Standby AX.) AX2(config)#ha id 2 AX2(config)#ha group 1 priority 1 AX2(config)#ha interface ethernet 1 router-interface no-heartbeat AX2(config)#ha interface ethernet 2 router-interface no-heartbeat AX2(config)#ha interface ethernet 3 server-interface AX2(config)#ha interface ethernet 4 server-interface AX2(config)#ha interface ethernet 5 AX2(config)#ha inline-mode preferred-port 5 AX2(config)#ha restart-port-list ethernet 1 to 2 AX2(config)#ha preemption-enable AX2(config)#ha conn-mirror ip 172.168.10.2 AX2(config)#floating-ip 172.168.10.1 ha-group 1 AX2(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX2(config-health:monitor)#method http url HEAD /index.html AX2(config-health:monitor)#exit AX2(config)#slb server s1 172.168.10.30 AX2(config-real server)#port 80 t AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb server s2 172.168.10.31 AX2(config-real server)#port 80 t AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb service-group g80 t AX2(config-slb service group)#member s1:80 AX2(config-slb service group)#member s2:80 AX2(config-slb service group)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

589 of 960

AX Series - Configuration Guide Configuring Layer 3 HA (Inline Mode) AX2(config)#slb virtual-server v1 172.168.10.80 AX2(config-slb virtual server)#ha-group 1 AX2(config-slb virtual server)#port 80 t AX2(config-slb virtual server-slb virtua...)#service-group g80 AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror

Configuring Layer 3 HA (Inline Mode) To configure Layer 3 HA: 1. Configure the following global HA parameters: • HA ID • HA group ID and priority. Configure only one group ID. Configure the same ID on both AX devices. • Floating IP address (optional) • Inline mode • HA interfaces • Session synchronization (optional) • HA pre-emption (optional) 2. Enable U processing on the Ethernet interfaces that will receive server replies to client requests. 3. Add each virtual server to the HA group. 4. If session synchronization is globally enabled, enable it on the individual virtual ports whose client sessions you want to synchronize. 5. If IP NAT pools are configured, add each pool to the HA group.

590 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA (Inline Mode)

Layer 3 Inline HA Configuration Example The following configuration example implements the deployment shown in Figure 146 on page 551. The GUI does not 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 U processing on an interface, use the following command at the configuration level for the interface: u-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, U processing is enabled on those interfaces. AX1(config)#interface ethernet 1 AX1(config-if:ethernet1)#enable AX1(config-if:ethernet1)#interface ethernet 2 AX1(config-if:ethernet2)#enable AX1(config-if:ethernet2)#interface ethernet 3 AX1(config-if:ethernet3)#enable AX1(config-if:ethernet3)#u-process AX1(config-if:ethernet3)#interface ethernet 4 AX1(config-if:ethernet4)#enable AX1(config-if:ethernet4)#u-process AX1(config-if:ethernet4)#interface ethernet 5 AX1(config-if:ethernet5)#enable AX1(config-if:ethernet5)#exit AX1(config)#vlan 100 AX1(config-vlan:100)#untagged ethernet 1 to 4 AX1(config-vlan:100)#router-interface ve 1 AX1(config-vlan:100)#exit P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

591 of 960

AX Series - Configuration Guide Configuring Layer 3 HA (Inline Mode) AX1(config)#vlan 5 AX1(config-vlan:5)#untagged ethernet 5 AX1(config-vlan:5)#router-interface ve 5 AX1(config-vlan:5)#exit AX1(config)#interface ve1 AX1(config-if:ve1)#ip address 172.168.10.2 /24 AX1(config-if:ve1)#interface ve5 AX1(config-if:ve5)#ip address 172.168.20.2 /24 AX1(config-if:ve5)#exit

The following commands configure the HA ID and set the HA priority. HA priority is associated with an HA group. Later in the configuration, the VIP is assigned to this HA group. AX1(config)#ha id 1 AX1(config)#ha group 1 priority 255

The following command enables Layer 3 inline HA mode. AX1(config)#ha l3-inline-mode

The following commands configure the HA interfaces. Each interface that is connected to a server, a router, or the other AX can be configured as an HA interface. (Make sure to add the dedicated HA link between the AX devices as one of the HA interfaces.) AX1(config)#ha interface ethernet 1 router-interface no-heartbeat AX1(config)#ha interface ethernet 2 router-interface no-heartbeat AX1(config)#ha interface ethernet 3 server-interface AX1(config)#ha interface ethernet 4 server-interface AX1(config)#ha interface ethernet 5

The following command enables restart of the HA ports connected to the routers, to occur if the AX transitions to Standby. AX1(config)#ha restart-port-list ethernet 1 to 2

The following command enables HA pre-emption mode, which causes failover to occur in response to istrative changes to the HA configuration. (For example, if you change the HA priority so that the other AX has higher priority, this will trigger a failover, but only if pre-emption mode is enabled.) AX1(config)#ha preemption-enable

The following command specifies the IP address of the other AX, to use for session synchronization. AX1(config)#ha conn-mirror ip 172.168.10.3

592 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA (Inline Mode) The following command configures the floating IP address for the real servers to use as their default gateway address. AX1(config)#floating-ip 172.168.10.1 ha-group 1

The following commands configure a health method, real servers, a server group, and a VIP for an HTTP service. AX1(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX1(config-health:monitor)#method http url HEAD /index.html AX1(config-health:monitor)#exit AX1(config)#slb server s1 172.168.10.30 AX1(config-real server)#port 80 t AX1(config-real server-node port)#health-check myHttp AX1(config-real server-node port)#exit AX1(config-real server)#exit AX1(config)#slb server s2 172.168.10.31 AX1(config-real server)#port 80 t 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 t AX1(config-slb service group)#member s1:80 AX1(config-slb service group)#member s2:80 AX1(config-slb service group)#exit AX1(config)#slb virtual-server v1 172.168.10.80 AX1(config-slb virtual server)#ha-group 1 AX1(config-slb virtual server)#port 80 t AX1(config-slb virtual server-slb virtua...)#service-group g80 AX1(config-slb virtual server-slb virtua...)#ha-conn-mirror

Commands on AX2 Here are the commands for implementing HA on AX2. Most of the commands are the same as those on AX1, with the following exceptions: • The IP interfaces are different. • The HA ID is 2. • The HA priority is 1.

The session synchronization (conn-mirror) IP address is the address of AX1. (On AX1, the session synchronization IP address is the address of AX2.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

593 of 960

AX Series - Configuration Guide Configuring Layer 3 HA (Inline Mode) AX2(config)#interface ethernet 1 AX2(config-if:ethernet1)#enable AX2(config-if:ethernet1)#interface ethernet 2 AX2(config-if:ethernet2)#enable AX2(config-if:ethernet2)#interface ethernet 3 AX2(config-if:ethernet3)#enable AX1(config-if:ethernet3)#u-process AX2(config-if:ethernet3)#interface ethernet 4 AX2(config-if:ethernet4)#enable AX1(config-if:ethernet4)#u-process AX2(config-if:ethernet4)#interface ethernet 5 AX2(config-if:ethernet5)#enable AX2(config-if:ethernet5)#exit AX2(config)#vlan 100 AX2(config-vlan:100)#untagged ethernet 1 to 4 AX2(config-vlan:100)#router-interface ve 1 AX2(config-vlan:100)#exit AX2(config)#vlan 5 AX2(config-vlan:5)#untagged ethernet 5 AX2(config-vlan:5)#router-interface ve 5 AX2(config-vlan:5)#exit AX2(config)#interface ve1 AX2(config-if:ve1)#ip address 172.168.10.23 /24 AX2(config-if:ve1)#interface ve5 AX2(config-if:ve5)#ip address 172.168.20.3 /24 AX2(config-if:ve5)#exit AX2(config)#ha id 2 AX2(config)#ha group 1 priority 1 AX2(config)#ha interface ethernet 1 router-interface no-heartbeat AX2(config)#ha interface ethernet 2 router-interface no-heartbeat AX2(config)#ha interface ethernet 3 server-interface AX2(config)#ha interface ethernet 4 server-interface AX2(config)#ha interface ethernet 5 AX2(config)#ha l3-inline-mode AX2(config)#ha restart-port-list ethernet 1 to 2 AX2(config)#ha preemption-enable AX2(config)#ha conn-mirror ip 172.168.10.2 AX2(config)#floating-ip 172.168.10.1 ha-group 1 AX2(config)#health monitor myHttp interval 10 retry 2 timeout 3 AX2(config-health:monitor)#method http url HEAD /index.html AX2(config-health:monitor)#exit

594 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Layer 3 HA (Inline Mode) AX2(config)#slb server s1 172.168.10.30 AX2(config-real server)#port 80 t AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb server s2 172.168.10.31 AX2(config-real server)#port 80 t AX2(config-real server-node port)#health-check myHttp AX2(config-real server-node port)#exit AX2(config-real server)#exit AX2(config)#slb service-group g80 t AX2(config-slb service group)#member s1:80 AX2(config-slb service group)#member s2:80 AX2(config-slb service group)#exit AX2(config)#slb virtual-server v1 172.168.10.80 AX2(config-slb virtual server)#ha-group 1 AX2(config-slb virtual server)#port 80 t AX2(config-slb virtual server-slb virtua...)#service-group g80 AX2(config-slb virtual server-slb virtua...)#ha-conn-mirror

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

595 of 960

AX Series - Configuration Guide Configuring Optional Failover Triggers

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

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.

596 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Optional Failover Triggers

USING THE CLI To enable HA checking for a VLAN, use the following command at the global configuration level of the CLI: [no] ha check vlan vlan-id timeout seconds The timeout can be 2-600 seconds. You must specify the timeout. Although there is no default, A10 recommends trying 30 seconds. The following command enables VLAN-based failover for VLAN 10 and sets the timeout to 30 seconds: AX(config)#ha check vlan 10 timeout 30

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

USING THE GUI 1. Configure a health monitor that uses the ICMP method: a. Select Config > Service > Health Monitor. b. Select Health Monitor on the menu bar. c. Click Add. d. In the Health Monitor section, enter a name for the monitor. e. In the Method section, select ICMP from the Type drop-down list. f. Click OK. 2. Configure the gateway as an SLB real server and apply the ICMP health monitor to the server: a. Select Config > Service > SLB. b. Select Server on the menu bar. c. Click Add. The General section appears. d. In the General section, enter a name for the gateway in the Name field. e. In the IP Address field, enter the IP address of the gateway.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

597 of 960

AX Series - Configuration Guide Configuring Optional Failover Triggers 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] health monitor monitor-name Enter this command at the global Config level. [no] method icmp Enter this command at the configuration level for the health monitor. 2. To configure the gateway as an SLB real server and apply the health monitor to the server, use the following command. [no] slb server server-name ipaddr [no] health-check monitor-name 3. To enable HA health checking for the gateway, use the following command at the global configuration level. [no] ha check gateway ipaddr CLI Example The following commands configure an ICMP health method: AX(config)#health monitor gatewayhm1 AX(config-health:monitor)#method icmp AX(config-health:monitor)#exit

598 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Optional Failover Triggers The following commands configure a real server for the gateway and apply the health monitor to it: AX(config)#slb server gateway1 10.10.10.1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit

The following command enables HA health checking for the gateway: AX(config)#ha check gateway 10.10.10.1

Route-Based Failover Example You can configure HA route awareness for IPv4 routes and IPv6 routes. The current release does not this feature in the GUI.

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 priority-cost weight [gateway ipaddr] [protocol {static | dynamic}] [distance num] The destination-ipaddr /mask-length option specifies the destination IPv4 subnet of the route. The priority-cost weight option specifies the value to subtract from the HA priority of each HA group, if the IP route table does not have a route to the destination subnet. The gateway addr option specifies the next-hop gateway for the route. The protocol option specifies the source of the route: • static – The route was added by an . • 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

599 of 960

AX Series - Configuration Guide Configuring Optional Failover Triggers Omitting an optional parameter matches on all routes. For example, if you do not specify the next-hop gateway, routes that match based on the other parameters can have any next-hop gateway. HA Route Awareness for IPv6 Routes To configure HA route awareness for an IPv6 route, use the following command at the global configuration level of the CLI: [no] ha check route destination-ipv6addr/mask-length priority-cost weight [gateway ipv6addr] [protocol {static | dynamic}] [distance num] 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

600 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Optional Failover Triggers

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 573 and “Configuring HA Interfaces” on page 574. (For a description of the feature, see “VIP-based Failover” on page 558.)

USING THE GUI To configure VIP-based failover on a virtual server: 1. Configure HA global and interface parameters, if you have not already done so. 2. Select Config > Service > SLB. 3. On the menu bar, select Virtual Server. 4. Click on the virtual server name or click Add to create a new one. 5. Select the HA group from the HA Group drop-down list. The Dynamic Server Weight field appears. 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 573.

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: [no] ha-group group-id Enter this command at the configuration level for a virtual server, to assign the virtual server to the HA group. The group-id can be 1-31. [no] ha-dynamic server-weight P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

601 of 960

AX Series - Configuration Guide Configuring Optional Failover Triggers Enter this command at the configuration level for the virtual server to enable VIP-based failover. The server-weight specifies the amount to subtract from the HA group's priority value for each real server that becomes unavailable. The weight can be 1-255. The default is 1. CLI Example The following command configures HA group 6 on AX-1 and assigns priority 100 to the group: AX-1(config)#ha group 6 priority 100

The following command enables HA pre-emption. HA pre-emption must be enabled in order for failover to occur based on HA group priority changes. AX-1(config)#ha preemption-enable

The following command configures a floating IP address and assigns it to HA group 6: AX-1(config)#floating-ip 192.168.10.1 ha-group 6

The following commands assign virtual server VIP2 to HA group 6 and enable VIP-based failover for the virtual server. (For simplicity, this example does not show configuration of the real servers or non-HA virtual server options.) AX-1(config)#slb virtual VIP2 192.168.10.22 AX-1(config-slb virtual server)#ha-group 6 AX-1(config-slb virtual server)#ha-dynamic 10

The following commands configure the HA settings on AX-2. The priority for HA group 6 is set to 80. The server weight for HA group 6 on VIP2 is set to 10, the same weight value set on AX-1. Up to 2 real servers bound to VIP2 can become unavailable on AX-1 without triggering a failover. However, if a third real server becomes unavailable, the priority of HA group 6 is reduced to 70, which is lower than the priority value set on AX-2 for the group. In this case, a failover does occur for VIP2. AX-2(config)#ha group 6 priority 80 AX-2(config)#ha preemption-enable AX-2(config)#floating-ip 192.168.10.1 ha-group 6 AX-2(config)#slb virtual VIP2 192.168.10.22 AX-2(config-slb virtual server)#ha-group 6 AX-2(config-slb virtual server)#ha-dynamic 10

602 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

ed 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: 1. Select Config > HA > Setting. 2. On the menu bar, select HA Global.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

603 of 960

AX Series - Configuration Guide 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. 2. On the menu bar, select Virtual Server. 3. Click on the virtual server name. 4. On the Port tab, select the port and click Edit. 5. Select Enabled next to HA Connection Mirror. Note:

If the HA Connection Mirror option is not displayed, session synchronization is not ed for this service type. 6. Click OK to redisplay the Port tab. 7. Click OK again.

USING THE CLI To globally enable session synchronization, use the following command at the global configuration level of the CLI: [no] ha conn-mirror ip ipaddr The ipaddr must be an IP address 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:

604 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring OSPF-Related HA Parameters AX(config)#slb virtual-server vip1 10.10.10.100 AX(config-slb virtual server)#port 80 t 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 on Standby AX in Layer 3 Inline Mode” on page 606.)

Note:

You can assign an additional cost to an AX device’s OSPF interfaces when the HA status for any group on the device is Standby. If failover of one or more HA groups from Active to Standby occurs, the AX device does the following: • Updates the cost of all its OSPF interfaces • Sends Link-State ment (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 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

605 of 960

AX Series - Configuration Guide 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 device’s OSPF interfaces, if the HA status of one or more of the device’s HA groups is Standby. You can specify 1-65535. If the resulting cost value is more than 65535, the cost is set to 65535. Enter the command on each of the AX devices in the HA pair.

OSPF on Standby AX in Layer 3 Inline Mode In HA Layer 3 inline mode deployments, OSPF adjacencies are automatically formed between the Active and Standby AX devices and all OSPF routers on all VLANs. To limit OSPF adjacency formation to a specific VLAN only, explicitly configure adjacency formation for that VLAN. In this case, OSPF adjacency formation does not occur for any other VLANs. Use the following command at the global configuration level of the CLI: ha ospf-inline vlan vlan-id

Synchronizing Configuration Information You can use config-sync options to synchronize some or all of the following: • Startup-config, to the other AX device’s startup-config or running-con-

fig • Running-config, to the other AX device’s running-config or startup-con-

fig)

606 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Synchronizing Configuration Information • 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 603. SSH management access must be enabled on both ends of the link. (See “Securing Access by Ethernet” on page 687.)

Configuration Items That Are Backed Up The following configuration items are backed up during HA configuration synchronization: • s 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:

P e r f o r m a n c e

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 11/3/2010

607 of 960

AX Series - Configuration Guide Synchronizing Configuration Information

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

Access by Ethernet” on page 687) • AX Hostname • MAC addresses • Management IP addresses • Trunks or VLANs • Interface settings • OSPF 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 Role Root or Super (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.

608 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Synchronizing Configuration Information An who is logged on with Root or Read-Write (Super ) privileges can synchronize for all Role-Based istration (RBA) partitions or for a specific partition. An who is logged on with Partition Write privileges can synchronize only for the partition to which the 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 s. Caveats Before synchronizing the Active and Standby AX devices, 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 ed in the older version. The HA configuration synchronization process does not check 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

609 of 960

AX Series - Configuration Guide Synchronizing Configuration Information

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 and fields, enter the name and for logging onto the other AX device. 3. If Role-Based istration (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 822.) 4. Next to Operation, select the information to be copied to the other AX device: • All – Copies all the following to the other AX device: • Floating IP addresses • IP NAT configuration • Access control lists (ACLs) • Health monitors • Policy-based SLB (black/white lists) • SLB • FWLB • GSLB • Data files (see below) The items listed above that appear in the configuration file are copied to the other AX device’s running-config. • Data Files – Copies only the SSL certificates and private-key files, aFleX files, External health check files, and black/white-list files to the other AX device • Running-config – Copies everything listed for the All option, except the data files, from this AX device’s running-config • Startup-config – Copies everything listed for the All option, except the data files, from this AX device’s startup-config 5. Next to Peer Option, select the target for the synchronization: • To Running-config – Copies the items selected in step 4 to the other AX device’s running-config • To Startup-config – Copies the items selected in step 4 to the other AX device’s startup-config

610 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Synchronizing Configuration Information 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 608.

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 istration (RBA). For information, see “Role-Based istration” on page 807.

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

Note:

To synchronize the Active AX device’s startup-config to the Standby AX device’s startup-config or running-config, without also synchronizing the data files, use the following command: ha sync startup-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] To synchronize the Active AX device’s running-config to the Standby AX device’s running-config or startup-config, without also synchronizing the data files, use the following command: ha sync running-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] To synchronize the data files by copying the Active AX device’s data files to the Standby AX device, use the following command: P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

611 of 960

AX Series - Configuration Guide Tip for Ensuring Fast HA Failover ha sync data-files [all-partitions | partition partition-name]

Tip for Ensuring Fast HA Failover You can use health checking of the upstream and downstream routers to help ensure rapid HA failover. The time it takes for traffic to reconverge following HA failover can vary based on the network environment, and depends on the following: • How fast the ARPs (typically, ARPs of the default gateways) are learned

on the newly active AX device • How fast the MAC tables in the devices along the traffic paths are

updated To help reconvergence occur faster, you can create a real server configuration for each router, and use an ICMP health monitor for checking the health of the gateways. The health checks keep the ARP entries for the gateway routers active, which can help to reduce reconvergence time considerably. In a typical SLB configuration that includes a client-side router and a server-side router, configure a real server for each router. 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 301.) 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:

612 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Tip for Ensuring Fast HA Failover CLI Example – IPv4 AX(config)#health monitor gatewayhm1 AX(config-health:monitor)#method icmp interval 1 timeout 1 AX(config-health:monitor)#exit AX(config)#slb server gateway-upstream 192.168.10.1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit AX(config)#slb server gateway-downstream 10.10.10.1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit

To use the default ICMP health monitor instead, the configuration is even simpler: AX(config)#slb server gateway-upstream 192.168.10.1 AX(config-real server)#exit AX(config)#slb server gateway-downstream 10.10.10.1 AX(config-real server)#exit

CLI Example – IPv6 AX(config)#health monitor gatewayhm1 AX(config-health:monitor)#method icmp interval 1 timeout 1 AX(config-health:monitor)#exit AX(config)#slb server up-router 2309:e90::1 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit AX(config)#slb server down-router 2309:e90::3 AX(config-real server)#health-check gatewayhm1 AX(config-real server)#exit

To use the default ICMP health monitor: AX(config)#slb server up-router 2309:e90::1 AX(config-real server)#exit AX(config)#slb server down-router 2309:e90::3 AX(config-real server)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

613 of 960

AX Series - Configuration Guide Tip for Ensuring Fast HA Failover

614 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

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 s traditional Layer 3 NAT, which you can configure if required by your network. Note:

P e r f o r m a n c e

b y

This chapter does not include information about Large-Scale NAT (LSN). For LSN information, see “Large-Scale Network Address Translation” on page 647.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

615 of 960

AX Series - Configuration Guide 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

616 of 960

SLB NAT

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 server’s IP address to the VIP address. The default SLB NAT behavior does not translate the client’s IP address.

SLB Source NAT SLB source NAT is disabled by default. There are some cases where SLB Source NAT is applicable: • Connection reuse. (See “Connection Reuse” on page 617.) • 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 back through the AX device. (See “Source NAT for Servers in Other Subnets” on page 622.)

IP Source NAT Configuration Limits The AX device s the following: • NAT pool addresses – Maximum of 500 NAT pool addresses ed,

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 ed. • NAT pool groups – Maximum of 50 NAT pool groups ed. Each

NAT pool group can contain up to 5 NAT pools.

Connection Reuse Connection reuse enables you to reuse T 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 T connection with the real server each time a client ends its session. Instead, the AX device leaves the T connection established, and reuses the connection for the next client that uses the real server.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

617 of 960

AX Series - Configuration Guide SLB NAT Connection reuse requires SLB source NAT. Since the T connection with the real server needs to remain established after a client’s session ends, the client’s IP address cannot be used as the source address for the connection, Instead, the source address must be an IP address from a NAT pool or pool group configured on the AX device. The pool or pool group must have a unique IP address for each reusable T 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 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 ed. 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:

618 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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: a. Select Config > Service > Template. b. Select Connection Reuse on the menu bar. c. Click New. The Connection Reuse section appears. d. Enter a name for the template. e. Edit the other parameters or leave them at their default settings. f. Click OK. The template appears in the connection reuse template table. 3. To enable source NAT on the virtual port: a. Select Config > Service > Server. b. Select Virtual Server on the menu bar. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

619 of 960

AX Series - Configuration Guide 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]

To configure an IPv6 pool: ipv6 nat pool pool-name start-ipv6-addr end-ipv6-addr netmask mask-length [gateway ipaddr] [ha-group-id group-id]

To configure a pool group, configure a separate IP pool for each 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

620 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 /24 AX(config)#access-list 50 permit ip 192.168.20.69 /24

The following commands configure source NAT pools: AX(config)#ip nat pool pool1 10.10.10.200 10.10.10.100 netmask /16 ha-group-id 1 AX(config)#ip nat pool pool2 10.10.10.200 10.10.10.200 netmask /16 ha-group-id 1

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

621 of 960

AX Series - Configuration Guide SLB NAT The following commands configure a real server and a service group: AX(config)#slb server s1 192.168.19.48 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb service-group group80 t AX(config-slb service group)#method weighted-rr AX(config-slb service group)#member s1:80 AX(config-slb service group)#exit

The following commands configure policy-based source NAT, by binding ACLs to NAT pools on the virtual port. AX(config)#slb virtual-server vs1 10.10.10.100 AX(config-slb virtual server)#port 80 t AX(config-slb virtual server-slb virtua...)#access-list 30 source-nat-pool pool1 AX(config-slb virtual server-slb virtua...)#access-list 50 source-nat-pool 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 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 623 shows an example.

622 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 back through the AX device, the AX device uses IP source NAT. To implement IP source NAT, two pairs of ACL and IP address pool are bound to the virtual port. Each ACL-pool pair contains the following: • An extended ACL whose source IP address matches on client addresses

and whose destination IP address matches on the real server’s subnet. • An IP address pool or pool group containing translation addresses in the

real server’s subnet. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

623 of 960

AX Series - Configuration Guide SLB NAT For example, if SLB selects a real server in the 10.10.10.x subnet, then the source IP address is translated from the client’s address to an address in pool 1. When the server replies, it replies to the address from pool 1. 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 in Figure 161 on page 623. 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. AX(config)#ip nat pool pool1 10.10.10.100 10.10.10.101 netmask /24 AX(config)#ip nat pool pool2 10.10.20.100 10.10.20.101 netmask /24

The following commands bind the ACLs and IP address pools to a virtual port on the VIP: AX(config)#slb virtual-server vip1 192.168.1.100 AX(config-slb virtual server)#port 80 t AX(config-slb virtual server-slb virtua...)#access-list 100 source-nat-pool pool1 AX(config-slb virtual server-slb virtua...)#access-list 110 source-nat-pool pool2

Direct Server Return You can disable destination NAT on a virtual port, to enable Direct Server Return (DSR). DSR enables a real server to respond to clients directly instead of going through the AX device. The AX is not required to return the server’s response traffic to clients, so there is no need to un-NAT traffic. This type of NAT is especially useful for applications that have intensive payload transfers, such as FTP and streaming media.

624 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide SLB NAT When DSR is enabled, only the destination MAC address is translated from the VIP’s MAC address to the real server’s IP address. The destination IP address is still the VIP. To use DSR, the AX device and the real servers must be in the same Layer 2 subnet. The VIP address must be configured as a loopback address on the real servers. To enable DSR on a virtual port, use either of the following methods. Note:

To configure health checking for DSR, see “Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments” on page 394.

Note:

For examples of DSR configurations, see “Network Setup” on page 73.

USING THE GUI 1. Select Config > Service > SLB. 2. Select Virtual Server on the menu bar. 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

625 of 960

AX Series - Configuration Guide SLB NAT

IP NAT for VIPs The AX device s 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 ed. Note:

The current release does not 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 for VIPs, use the following command at the global configuration level of the CLI: [no] slb snat-on-vip

626 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide IP Source NAT To configure IP NAT 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 server’s IP address, and a default gateway is defined for the pool, the AX device forwards the server traffic through the pool’s default gateway. This feature is disabled by default. To enable it, use the following command at the global configuration level of the CLI: [no] slb snat-gwy-for-l3

IP Source NAT Independently of SLB NAT, you can configure traditional, Layer 3 IP source NAT. IP source NAT translates internal host addresses into routable addresses before sending the host’s traffic to the Internet. When reply traffic is received, the AX device then retranslates addresses back into internal addresses before sending the reply to the client. You can configure dynamic or static IP source NAT: • Dynamic source IP NAT – Internal addresses are dynamically translated

into external addresses from a pool. • Static source IP NAT – Internal addresses are explicitly mapped to

external addresses. Configuration Elements for Dynamic NAT Dynamic NAT uses the following configuration elements: • Access Control List (ACL) – to identify the inside host addresses to be

translated • Pool – to identify a contiguous range of external addresses into which to

translate inside addresses P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

627 of 960

AX Series - Configuration Guide 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 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 ed. If a pool group contains pools in different subnets, the AX device selects the pool that matches the outbound subnet. For example, if there are two routes to a given destination, in different subnets, and the pool group has a pool for one of those subnets, the AX selects the pool that is in the subnet for the outbound route. The AX device searches the pools beginning with the first one added to the group, and selects the first match. If none of the pools are in the destination subnet, the AX uses the first pool that has available addresses. • Inside NAT setting on the interface connected to the inside host. • Outside NAT setting on the interface connected to the Internet. Inside

host addresses are translated into external addresses from a pool before the host traffic is sent to the Internet. Note:

The AX device enables you to specify the default gateway for an IP source NAT pool to use. However, the pool’s default gateway can be used only if the data route table already has either a default route or a direct route to the destination of the NAT traffic. In this case, the pool’s default gateway will override the route, for NAT traffic that uses the pool. If the data route table does not have a default route or a direct route to the NAT traffic destination, the pool’s default gateway can not be used. In this case, the NAT traffic can not reach its destination. Configuration Elements for Static NAT Static NAT uses the following configuration elements: • Static mappings or an address range list – A static mapping is a one-to-

one mapping of an inside address to an external address. An address range list is a contiguous range of inside addresses and external addresses to translate them into. • Inside NAT setting on the interface connected to the inside host.

628 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 U 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 s 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

629 of 960

AX Series - Configuration Guide 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.

630 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide IP Source NAT d. Repeat for each interface connected to the Internet. e. Click OK.

P e r f o r m a n c e

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 11/3/2010

631 of 960

AX Series - Configuration Guide 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}}

632 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide IP Source NAT or access-list acl-num {permit | deny} {t | udp} {any | host host-src-ipaddr | net-src-ipaddr {filter-mask | /mask-length}} [eq src-port | gt src-port | lt src-port | range start-src-port end-src-port] {any | host host-dst-ipaddr | net-dst-ipaddr {filter-mask | /mask-length}} [eq dst-port | gt dst-port | lt dst-port | range start-dst-port end-dst-port] 2. To configure a pool of external addresses to use for translation, use one of the following commands at the global configuration level of the CLI. To configure an IPv4 pool: ip nat pool pool-name start-ipaddr end-ipaddr netmask {subnet-mask | /mask-length} [gateway ipaddr] [ha-group-id group-id [ha-use-all-ports]] 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:

To configure an IPv6 pool: ipv6 nat pool pool-name start-ipv6-addr end-ipv6-addr netmask mask-length [gateway ipaddr] [ha-group-id group-id]

To configure a pool group: ip nat pool-group pool-group-name {pool-name ...} 3. To enable inside source NAT and map the ACL to the pool, use the following command: ip nat inside source list acl-name pool {pool-name | pool-group-name}

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

633 of 960

AX Series - Configuration Guide IP Source NAT 4. To enable inside NAT on the interfaces connected to the inside hosts, use the following commands: interface [ethernet port-num | ve ve-num] ip nat inside The interface command changes the CLI to the configuration level for the interface connected to the internal hosts. These are the hosts identified by the ACL configured in step 1 and used by the commands in step 2 and step 3. 5. To enable outside NAT on the interfaces connected to the Internet, use the following commands: interface [ethernet port-num | ve ve-num] ip nat outside

CLI EXAMPLE The following commands configure an ACL to specify the internal hosts to be NATted. In this example, all hosts in the 10.10.10.x subnet are to receive NAT service for traffic to the Internet. AX(config)#access-list 1 permit 10.10.10.0 0.0.0.255

The following command configures an IPv4 pool of external addresses to use for the NAT translations. In this example, 10.10.10.x addresses will be translated into 192.168.1.1 or 192.168.1.2: AX(config)#ip nat pool pool1 192.168.1.1 192.168.1.2 netmask /24

The following command enables inside source NAT and associates the ACL with the pool: AX(config)#ip nat inside source list 1 pool pool1

The following commands enable inside source NAT on the interface connected to the internal hosts: AX(config)#interface ethernet 4 AX(config-if:ethernet4)#ip nat inside

The following commands enable source NAT on the interface connected to the external hosts: AX(config-if:ethernet4)#interface ethernet 6 AX(config-if:ethernet6)#ip nat outside

634 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 ed. However, sessions will

not be interrupted by HA failovers. • Syn-cookies are not ed.

USING THE GUI The GUI s configuring a static NAT range but does not 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

635 of 960

AX Series - Configuration Guide 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 ed: [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]

636 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 : 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, use the following commands: interface [ethernet port-num | ve ve-num] ip nat inside The interface command changes the CLI to the configuration level for the interface connected to the internal hosts. 4. To enable outside NAT on the interfaces connected to the Internet, use the following commands: interface [ethernet port-num | ve ve-num] ip nat outside

CLI EXAMPLE The following commands enable static NAT, configure an IP address range named “nat-list-1” that maps up to 100 local addresses starting from 10.10.10.97 to Internet addresses starting from 192.168.22.50, set Ethernet interface 2 as the inside NAT interface, and set Ethernet interface 4 as the outside NAT interface. AX(config)#ip nat range-list nat-list-1 10.10.10.97 /16 192.168.22.50 /16 count 100 AX(config)#interface ethernet 2 AX(config-if:ethernet2)#ip nat inside AX(config-if:ethernet2)#exit AX(config)#interface ethernet 4 AX(config-if:ethernet4)#ip nat outside

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

637 of 960

AX Series - Configuration Guide IP Source NAT

NAT ALG for PPTP NAT Application Layer Gateway (ALG) 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 T 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 T) 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 T destination port. The AX device does not change the

638 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide IP Source NAT PAC’s Call ID. The PAC then assigns to the client an IP address belonging to the VPN subnet. On the AX device, the GRE session is created after the PNS sends its reply. In the GRE session, the Call ID is used as the Layer 4 port, instead of a T/UDP port number. (See the example of show session output in “CLI Example” on page 641.) In Figure 166 on page 638, 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 T 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 T or UDP destination port. Therefore, GRE packets from the server (10.3.3.2) will use the NAT Call ID. The AX device translates the NAT Call ID back into the client’s original Call ID before sending the packet to the client. One GRE session is ed per control session, which means one call at a time is ed. 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 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 for PPTP is disabled, enable it. (The feature is

enabled by default.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

639 of 960

AX Series - Configuration Guide IP Source NAT Note:

In the current release, NAT ALG for PPTP is not ed with static NAT or NAT range lists.

Note:

In the current release, NAT ALG for PPTP can not be disabled or re-enabled using the GUI.

USING THE CLI To configure dynamic IP source NAT, use the following commands. First, to configure the ACL, use the following command at the global configuration level of the CLI: access-list acl-num permit source-ipaddr {filter-mask | /mask-length} Note:

The ACL must permit IP traffic. The syntax above is for a standard ACL. If you plan to use an extended ACL instead, make sure to use the ip option, instead of icmp, t, or udp. To configure the IP address pool, use the following command at the global configuration level of the CLI: ip nat pool pool-name start-ipaddr end-ipaddr netmask {subnet-mask | /mask-length} [gateway ipaddr] [ha-group-id group-id] To configure an IP source NAT list, use the following command at the global configuration level of the CLI: ip nat inside source list acl-name pool {pool-name | pool-group-name} To enable inside source NAT on an interface, use the following command at the configuration level for the interface: [no] ip nat inside To enable outside source NAT on an interface, use the following command at the configuration level for the interface: [no] ip nat outside To enable or disable NAT ALG 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.

640 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 638. The following commands configure dynamic inside source NAT. AX(config)#access-list 1 permit 10.1.1.0 0.0.0.255 AX(config)#ip nat pool pptp-pool 192.168.1.100 192.168.1.110 netmask /24 AX(config)#ip nat inside source list 1 pool pptp-pool

The following commands specify the inside NAT interface and the outside NAT interface. AX(config)#interface ethernet 1 AX(config-if:ethernet1)#ip address 10.2.2.254 255.255.255.0 AX(config-if:ethernet1)#ip nat inside AX(config-if:ethernet1)#interface ethernet 2 AX(config-if:ethernet2)#ip address 10.3.3.254 255.255.255.0 AX(config-if:ethernet2)#ip nat outside

The following command displays session information: AX(config-if:ethernet2)#show session Prot Forward Source Age Hash

Forward Dest

Reverse Source

Reverse Dest

---------------------------------------------------------------------------------------------------------Gre 10.1.1.1:49152 240 1

10.3.3.2:32799

10.3.3.2:32799

192.168.1.100:2109

T 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 T 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 T session, the number is the T protocol port.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

641 of 960

AX Series - Configuration Guide 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:

0

Truncated PNS Message:

0

Truncated PAC Message:

0

Mismatched PNS Call ID:

1

Mismatched PAC Call ID:

0

Retransmitted PAC Message:

3

Truncated GRE Packets:

0

Unknown GRE Packets:

0

No Matching Session Drops:

4

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:

642 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

T

UDP

ICMP

-----------------------60

300

300

fast

Service 53/udp has fast-aging configured P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

643 of 960

AX Series - Configuration Guide 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 T Resets for NATted T Sessions By default, the AX device does not send T Resets to the client and server when a NATted T session becomes idle. To enable this option, use the following command at the global configuration level of the CLI: ip nat reset-idle-t-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 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 device’s IP address is on the 172.168.101.0/24 subnet. A NAT pool has been configured to reach servers outside of that subnet/VLAN.

644 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 list’s global subnet. You can configure the address on any active data interface on the AX device. This issue does not affect NATted traffic other than ICMP or UDP traffic, or use of an ACL with a NAT pool.

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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

645 of 960

AX Series - Configuration Guide 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 > IPv4 Pool • Config > Service > IP Source NAT > IPv6 Pool • Config > Service > IP Source NAT > NAT Range

USING THE CLI In the CLI, the ha-group-id option is ed with the following NAT commands: [no] ip nat pool pool-name start-ipaddr end-ipaddr netmask {subnet-mask | /mask-length} [gateway ipaddr] [ha-group-id group-id] [no] ipv6 nat pool pool-name start-ipv6-addr end-ipv6-addr netmask mask-length [gateway ipaddr] [ha-group-id group-id] [no] ip nat range-list list-name source-ipaddr /mask-length nat-ipaddr count number [ha-group-id group-id]

646 of 960

P e r f o r m a n c e

b y

/mask-length

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

Large-Scale Network Address Translation This chapter describes Large-scale Network Address Translation (LSN) and how to configure it. 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 T • RFC 5508 – NAT Behavioral Requirements for ICMP

Note:

LSN is ed 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) 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 666.)

Overview LSN provides robust NAT 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

647 of 960

AX Series - Configuration Guide Overview FIGURE 167

Large-Scale NAT

The carrier’s clients are on an internal subnet, 192.168.1.x/24, in the carrier’s network. When a client sends a request, the AX device running LSN creates a mapping of the client’s internal address and protocol port to a public address and protocol port. In this example, LSN creates the following mapping: Client Internal Address 192.168.1.1:10000

648 of 960

Client Public Address 203.0.113.1:10000

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview 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 192.168.1.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

P e r f o r m a n c e

b y

LSN Address Mapping

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

649 of 960

AX Series - Configuration Guide Overview NAT Data Session Aging The client’s 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 T session, the data session is removed when the AX device

observes the FIN or RST 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 T, UDP, and ICMP, using the ip nat translation command. • t-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 670.)

650 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 applications continue to work with

minimal to no impact on customers. • Well defined NAT behavior – LSN’s consistent, deterministic behavior

allows for easy development of new applications. Traditional NAT implementations vary considerably, and may not work for all applications. • Fairness in resource sharing – LSN provides 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 653. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

651 of 960

AX Series - Configuration Guide Overview FIGURE 169

LSN Clients Using P2P File Sharing

In this example, multiple clients are ed with a P2P file-sharing tracker as sharers of file “example.torrent”. All clients are ed 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. Note:

652 of 960

When possible, LSN uses the internal client’s source protocol port number in the external mapping for the client. However, if the protocol port is P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview already used by another client on the same external IP address, LSN selects another protocol port for the new mapping.

Benefits of LSN LSN provides the following benefits not provided by traditional NAT: • Sticky NAT • Application transparency through full-cone NAT to peer-to-peer

(P2P) applications • Hairpinning • Configurable quotas to ensure fair allocation of NAT mappings • Static port reservation

Sticky NAT Once an internal uses a NAT IP, the always uses the same NAT IP for future connections. If all 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 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:

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

653 of 960

AX Series - Configuration Guide Overview • Endpoint-Independent Mapping (See Figure 168 on page 649.) – After

LSN maps an internal client’s source IP address and Layer 4 (T 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 T 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 • Endpoint-Independent Filtering (See Figure 169 on page 652.) – 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:

654 of 960

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 device’s security features can still be used to control access to clients.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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

Quotas When an internal is first mapped by LSN, the is assigned to a NAT IP as part of sticky NAT. Before choosing a NAT IP for a particular internal , LSN checks to ensure there are enough ports free on that NAT IP for the . This guarantees that internal s will be able to use as many ports as possible. LSN 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 T NAT ports. Once a client reaches the quota, the client is not allowed to open additional T sessions. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

655 of 960

AX Series - Configuration Guide Overview You can configure separate quotas for each of the following protocols, on a global or individual LSN Limit-ID (LID) basis: • T • UDP • ICMP

Each NAT IP has 64,000 T ports, 64,000 UDP ports, and 64,000 ICMP ports that can be used for sessions on the address. FIGURE 171

Protocol Ports Available for Per- Quota

The per- quota for a protocol specifies the maximum number of ports a given internal can use at the same time on a NAT IP. For example, if you set the T per - quota to 100 ports, each internal can have a maximum of 100 T sessions on a NAT IP. In Figure 172, 320 internal s are mapped to a NAT IP. Each of the s consumes 100 T ports, leaving 32,000 ports free for new s. In this example, there is room for an additional 320 internal s on the NAT IP.

656 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview FIGURE 172

Per- Quota

Port Reserve In the example above, each internal immediately consumes 100 of the NAT IP’s T ports, as soon as the is mapped to the NAT IP. If typical port consumption per is expected to be lower than the per quota, you can also specify a reserve value. The reserve value is a subset of the per- quota. Specifying a reserve value allows more internal s to be mapped to the NAT IP. When you specify a reserve value, each new internal immediately consumes the number of reserved ports. However, the remaining ports in the ’s quota are not consumed unless the actually needs them. Any remaining ports that are not consumed by the are available, if needed, to new s. FIGURE 173

P e r f o r m a n c e

b y

Per- Quota with Reserve

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

657 of 960

AX Series - Configuration Guide Overview In Figure 173, none of the 320 internal s currently mapped to the NAT IP is using more than their reserve value of 50 T ports each. This leaves the remaining ports in each ’s quota available for new s, if needed. When new s are mapped to the NAT IP, those s receive ports from the free ports. After all free ports are assigned to s, available (unused) ports within existing s’ quotas are assigned to new s if needed. In Figure 174, the external IP address does not have any more free ports. However, none of the s are actually using all of the ports in their 100-port quota. In fact, in this example, none of the s are using more than the 50 reserved ports within the quota. Although there are no more free ports, 32,000 ports are still unused, and therefore available for mapping to new internal s. FIGURE 174

Per- Quota with Reserve - no free ports

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 address must have enough free or available T ports to fulfill the

configured per- T reserve. • The configured per- T reserve must not exceed the number of

free or available ports on the NAT IP address. • The address must have enough free or available UDP ports to fulfill the

configured per- UDP reserve. • The configured per- UDP reserve must not exceed the number of

free or available ports on the NAT IP address.

658 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview There is a difference between available ports and free ports. It is possible to allocate more than the reserve value. However, it is not possible to allocate more than the -quota value.

Note:

All requirements above must be met for any type of session (T, 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. Extended 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 T 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. For quotas, the regular quota is used first, for all applications. The extended quota is used only if all regular quota ports are in use, and only for the specified application. The extended quota is always released before the regular quota. Example: • T quota = 10. • Extended quota for T port 25 (email) = 5.

Table 17 shows an example of how ports are used and released with these quotas. TABLE 17 Extended--Quota Example Connections T 80 (web) No connections No connections opens 4 connections

T 25 (email) No connections opens 1 connection opens 1 more connection

opens 4 more connections (total 8)

Regular Quota Available 10 9 5 4 0

Extended Quota Available 5 5 5 5 5

No more port 80 connections allowed! P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

659 of 960

AX Series - Configuration Guide Overview TABLE 17 Extended--Quota Example (Continued) Connections T 80 (web)

Regular Quota Available 0

T 25 (email) opens 5 more connections (total 7)

frees 4 connections

No more port 25 connections allowed! 4 more connections allowed

Still no more port 80 connections allowed! frees remaining 4 connections

Extended Quota Available 0

0

4

3

5

Maximum 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 wants to a service on a port. For example, an HTTP server will need to port 80. However, since the NAT IP is shared, only one per NAT IP will be able to have port 80. You can allow an inside to reserve a specific NAT port. In this example, the NAT port 80 would be statically assigned to the particular . Note:

660 of 960

This concept of port reservation is sometimes called “port forwarding”.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

LSN Logging The AX device generates logs for LSN operational events and for LSN traffic.

LSN Operational Logging Table 18 lists the types of LSN operational events that are logged. TABLE 18 LSN Operational Logs Severity Level Critical

Warning

Notice

Event -quota creation failure Full-cone session creation failure New inside unable to get NAT IP Current inside on NAT IP can not get new NAT port quota exceeded

Extended quota exceeded

Message String LSN: -quota creation failed (out of memory) for pool... LSN: Full-cone session creation failed (out-ofmemory) for pool... LSN: New could not get a NAT IP on pool.. LSN: NAT port usage exceeded on pool...

LSN: ICMP -quota exceeded on pool... LSN: UDP -quota exceeded on pool... LSN: T -quota exceeded on pool... LSN: UDP extended -quota exceeded on pool... LSN: T extended -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 pool1 (4146 times)

This dicates that a current NAT IP with an external IP address from pool1 could not get a new NAT port session, because no ports were available. The dicates 4146 occurrences of the same event. LSN events are logged to the AX device’s local log buffer based on the log settings for the system.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

661 of 960

AX Series - Configuration Guide 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, T, and UDP

sessions • NAT port mapping logs, to indicate creation or freeing of NAT port

mappings for ICMP, T, and UDP Table 19 lists the LSN traffic logs that can be generated. TABLE 19 LSN Traffic Logs Event ICMP data session created T data session created UDP data session created ICMP data session deleted T data session deleted UDP data session deleted LSN port mapping created for ICMP

Message String Format AX_hostname NAT-ICMP-N: 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-T-N: 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-UDP-N: 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-ICMP-D: 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-T-D: 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-UDP-D: 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-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 T LSN port mapping created for UDP LSN port mapping for ICMP freed LSN port mapping for T freed LSN port mapping for UDP freed

662 of 960

AX_hostname NAT-T-C: inside_ip:inside_port<-->nat_ip:nat_port to dest_ip:dest_port AX_hostname NAT-UDP-C: inside_ip:inside_port<-->nat_ip:nat_port to dest_ip:dest_port AX_hostname NAT-ICMP-F: inside_ip:inside_port<-->nat_ip:nat_port to dest_ip:dest_port AX_hostname NAT-T-F: inside_ip:inside_port<-->nat_ip:nat_port to dest_ip:dest_port AX_hostname NAT-UDP-F: inside_ip:inside_port<-->nat_ip:nat_port to dest_ip:dest_port

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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. AX NAT-UDP-C: 192.168.1.1:20001<-->203.0.210.1:80, 203.0.210.1:80<-->203.0.113.1:20001 AX NAT-UDP-D: 192.168.1.1:20001<-->203.0.210.1:80, 203.0.210.1:80<-->203.0.113.1:20001

The following logs indicate the creation and freeing of an LSN port mapping for UDP. AX NAT-UDP-C: 192.168.1.1:20001 -> 203.0.113.1:20001 to 203.0.210.1:80 AX NAT-UDP-F: 192.168.1.1:20001 -> 203.0.113.1:20001 to 203.0.210.1:80

Remote Logging LSN traffic logs can be sent only to external log servers. LSN traffic logs are not sent to the AX device’s 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 671.) 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

663 of 960

AX Series - Configuration Guide Overview Note:

This release also has a CLI syntax enhancement for LSN pool-group configuration. (See “CLI Syntax Enhancement for LSN Pool-Group Configuration” on page 198.) Maximum LSN Pool IP Addresses By default, the AX models that LSN can 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 • AX 2600 – 2000 outside IPs • AX 2500 – 2000 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 , 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.

664 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview To place a system resource change into effect, you must reload or reboot the AX device.

Note:

If you change the maximum number of Layer 4 sessions (l4-sessioncount), a reboot is required. A reload will not place this change into effect.

Notes and Limitations 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, -quota sessions, or full-cone sessions are created for inside 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. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

665 of 960

AX Series - Configuration Guide Configuring Large-Scale NAT

Configuring Large-Scale NAT 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 quotas for the LID. 3. Configure class lists for the 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. Note:

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. 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 670 • “Enabling Full-Cone for Well-Known Ports” on page 670 • “Configuring External Logging for LSN Traffic Logs” on page 671 • “Configure the IP Selection Method” on page 673 • “Configuring the LSN SYN Timeout” on page 673

666 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Large-Scale NAT

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-s-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--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. LSN pools can not be used for SLB.

Note:

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 Use the following commands: [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: [no] source-nat-pool pool-name This command binds an LSN NAT pool to the LID. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

667 of 960

AX Series - Configuration Guide Configuring Large-Scale NAT [no] -quota {t | udp | icmp} quota-num [reserve reserve-num] This command configures the per- mapping quota for each type of protocol ed for LSN (T, 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 quota. The reserve option allows you to specify how many ports to reserve on a NAT IP for each , 0-64000. If unspecified, the reserve value is the same as the -quota value. [no] extended--quota {t | udp | icmp} service-port portnum sessions num This command configures a per- 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 quota.

Configure a Class List Use the following command at the global configuration level of the CLI: [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. 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]

668 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Large-Scale NAT 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. The AX device discards the comment string when you save the class list.

Note:

Example Class Lists Here is an example of a class list for inside subnet 192.168.1.x/24 using LID 2. 192.168.0.0 /16 lsn-lid 2

Bind the CLass List for Use with LSN Use the following command at the global configuration level of the CLI: [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

Enable New-path Processing Use the following command at the global configuration level: [no] slb new-path-enable

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

669 of 960

AX Series - Configuration Guide Configuring Large-Scale NAT

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.

Enabling Full-Cone for Well-Known Ports By default, LSN does not provide full-cone for sessions initiated from an internal IP address to a well-known T or UDP port (0-1023) on an external address. To enable full-cone 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. The default STUN timeout is 2 minutes. To change the STUN timeout, use the following command at the global configuration level of the CLI: [no] ip nat lsn stun-timeout minutes You can specify 0-60 minutes.

670 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Large-Scale NAT

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 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 676.) 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: [no] service-group group-name 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 661.) [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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

671 of 960

AX Series - Configuration Guide Configuring Large-Scale NAT [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 at the global configuration level of the CLI: [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: [no] ip nat lsn logging pool pool-name template template-name

672 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Large-Scale NAT

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, T, or UDP) used • least-udp-used-strict – Selects the address with the fewest UDP NAT

ports used • least-t-used-strict – Selects the address with the fewest T NAT

ports used • least-reserved-strict – Selects the address with the fewest NAT ports of

any type (ICMP, T, or UDP) reserved • least-reserved-udp-strict – Selects the address with the fewest UDP NAT

ports reserved • least-reserved-t-strict – Selects the address with the fewest T NAT

ports reserved • least-s – Selects the address with the fewest s

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.

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: P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

673 of 960

AX Series - Configuration Guide Displaying LSN Information [no] ip nat lsn syn-timeout seconds Note:

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.

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 -quota-sessions This command shows currently active 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.

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

674 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Example clear ip nat lsn data-sessions clear ip nat lsn all-sessions pool pool-name The last command is required before removing a pool from a pool group.

Note:

Configuration Example The commands in this section implement the LSN configuration shown in Figure 167 on page 648. The following command configures an LSN NAT pool: AX(config)#ip nat pool LSN_POOL1 203.0.113.1 203.0.113.254 netmask /24 lsn

The following commands configure an LSN LID. The LID is bound to pool “LSN_POOL1”. Per- quotas are configured for T, UDP, and ICMP. For UDP, this class of s will reserve only 100 UDP ports instead of 300. An extended quota of sessions per client is allocated for T port 25 (SMTP). AX(config)#lsn-lid 5 AX(config-lsn lid)#source-nat-pool LSN_POOL1 AX(config-lsn lid)#-quota t 100 AX(config-lsn lid)#-quota udp 300 reserve 100 AX(config-lsn lid)#-quota icmp 10 AX(config-lsn lid)#extended--quota t 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)#192.168.0.0 /16 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

The following commands enable inside NAT on the interface connected to the internal clients: AX(config)#interface ethernet 1 AX(config-if:ethernet1)#ip nat inside

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

675 of 960

AX Series - Configuration Guide Configuration Example The following commands enable outside NAT on the interface connected to the Internet: AX(config)#interface ethernet 2 AX(config-if:ethernet2)#ip nat outside AX(config-if:ethernet2)#exit

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 203.0.118.1 AX5200(config-real server)#port 514 udp AX5200(config-real server)#exit 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: 1 Content: 192.168.0.0 /16 lsn-lid 5 AX#show ip nat lsn full-cone-sessions LSN Full Cone Sessions: Prot Inside Address NAT Address Conns Pool U Age -------------------------------------------------------------------------------------------------T 192.168.1.1:20001 203.0.113.1:20001 1 pool1 1 0 T 192.168.2.1:30001 203.0.113.1:30001 1 pool1 4 0 T 192.168.255.1:50001 203.0.113.1:50001 1 pool1 13 0

676 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuration Example AX#show ip nat lsn -quota-sessions LSN -Quota Sessions: Inside Address NAT Address ICMP UDP T Pool LID --------------------------------------------------------------------------------------192.168.1.1:20001 203.0.113.1:20001 0 3 0 pool1 3 192.168.2.1:30001 203.0.113.1:30001 0 3 0 pool1 3 192.168.255.1:50002 203.0.113.1:50001 0 2 0 pool1 3 AX#show ip nat lsn port-reservations LSN Port Reservations Inside Address Start End NAT Address Start End -------------------------------------------------------------------------------------192.168.1.1 80 1024 203.0.113.1 80 1024 AX#show ip nat lsn pool-statistics LSN Address Pool Statistics: ---------------------------pool1 Address s ICMP Freed Total UDP Freed Total Rsvd T Freed Total Rsvd -------------------------------------------------------------------------------------------------------203.0.113.1 0 0 0 0 0 0 0 0 0 0 0 0 203.0.113.2 0 0 0 0 0 0 0 0 0 0 0 0 203.0.113.3 0 0 0 0 0 0 0 0 0 0 0 0

Table 20 describes the fields in the show ip nat lsn pool-statistics output. TABLE 20 show ip nat lsn pool-statistics fields Field Address s 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) Total (UDP)

ICMP column + Freed column = Total column. Number of UDP ports currently in use. Total number of UDP ports freed. Total number of UDP ports allocated.

Rsvd (UDP)

T Freed (T) Total (T)

UDP column + Freed column = Total column. Total of all UDP reserve settings for each that is currently using the NAT IP address. For example, if an LID has the setting “-quota udp 100 reserve 50”, and there are 50 s using the LID d on the NAT IP address, the Rsvd value is 50*50 = 2500. Number of T ports currently in use. Total number of T ports freed. Total number of T ports allocated. T column + Freed column = Total column.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

677 of 960

AX Series - Configuration Guide Configuration Example TABLE 20 show ip nat lsn pool-statistics fields (Continued) Field Rsvd (T)

Description Total of all T reserve settings for each that is currently using the NAT IP address. For example, if an LID has the setting “-quota t 100 reserve 60”, and there are 10 s using the LID d on the NAT IP address, the Rsvd value is 10*60 = 600.

678 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Additional s

Management Security Features In addition to basic security provided by and enable s, AX Series devices the following advanced management access security features: • Multiple s with distinct levels of access • lockout in response to excessive invalid s • 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 ing (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 “” and the enable , A10 Networks recommends that you do so now, before implementing security options described in this chapter.

Note:

Configuring Additional s The AX device comes with one , “”, by default. The “” has Root privileges and cannot be deleted. When logged onto the AX device with the , you can configure additional s. For each , you can configure the following settings: • name and • Privilege level (read or read-write) • IP host or subnet address from which the is allowed to log on • state (enabled or disabled)

Note:

P e r f o r m a n c e

b y

You cannot change the privilege level of the “” or disable it.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

679 of 960

AX Series - Configuration Guide

Configuring an To configure an , use either of the following methods.

USING THE GUI 1. Select Config > System > . 2. Click Add. The section appears. 3. Enter the name in the Name field. 4. Leave Change selected. (If you do not change the , the default is used: “a10”.) 5. Enter the for the new in the and Confirm fields. 6. To restrict access by the 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 – Allows access to all levels of the system. This

is not the “Root” and can be deleted. This cannot configure other s. (Only the that has Root privileges can configure other s.) • Read Only – Allows monitoring access to the system but not configuration access. In the CLI, this can only access the EXEC and Privileged EXEC levels, not the configuration levels. In the GUI, this cannot modify configuration information. • Partition Write – The has read-write privileges within the private partition to which the is assigned. The has read-only privileges for the shared partition. • Partition Read – The has read-only privileges within the private partition to which the is assigned, and read-only privileges for the shared partition.

680 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Additional s • Partition RS Operator – The 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 istration (RBA). For information about this feature, see “Role-Based istration” on page 807.

Note:

8. Leave the Status enabled. 9. Click OK. 10. The new appears in the table.

P e r f o r m a n c e

FIGURE 175

Config > >

FIGURE 176

Config > - new added

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

681 of 960

AX Series - Configuration Guide

USING THE CLI 1. Log on through the CLI and access the global configuration level. 2. Enter the following command to create the new : [no] -name This command changes the CLI to the configuration level for the new . 3. Use the following commands to complete the configuration: string trusted-host ipaddr {subnet-mask | /mask-length} privilege priv-level [partition-name] The command assigns the , which can be 1-63 characters. The default is “a10”. The trusted-host command specifies the host or subnet from which the is allowed to . The default is 0.0.0.0 /0 (any host or subnet). The privilege command specifies the privileges granted to the : • read – The can access the EXEC and Privileged EXEC levels of the CLI only. This is the default. • write – The can access all levels of the CLI but cannot configure other s. • partition-read – The has read-only privileges within the private partition to which the is assigned, and read-only privileges for the shared partition. • partition-write – The has read-write privileges within the private partition to which the is assigned. The has read-only privileges for the shared partition. • partition-enable-disable – The 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 is assigned. This option applies only to s 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 Access” on page 694. 4. To the new , enter the following command: show

682 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Additional s

CLI EXAMPLES The following commands add “2” with “12345678” and read-write privilege: AX(config)# 2 AX(config-:2)# 12345678 AX(config-:2)#privilege write AX(config-:2)#show Name

Status

Privilege Partition

------------------------------------------------------

Enabled

Root

2

Enabled

Read/Write

The following commands add “3” with “abcdefgh” and read-write privilege, and restrict access to the 10.10.10.x subnet only: AX(config)# 3 AX(config-:3)# abcdefgh AX(config-:3)#privilege write AX(config-:3)#trusted-host 10.10.10.0 /24 AX(config-:3)#show Name

Status

Privilege Partition

------------------------------------------------------

Enabled

Root

2

Enabled

Read/Write

3

Enabled

Read/Write

AX(config-:3)#show 3 detail Name ...... 3 Status ...... Enabled Privilege ...... Read/Write Partition ...... Trusted Host(Netmask) ...... 10.10.10.0(255.255.255.0) Lock Status ...... No Lock Time ...... Unlock Time ...... Type ...... Encrypted ...... $1$6334ba07$CKbWL/LuSNdY12kcE.KdS0

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

683 of 960

AX Series - Configuration Guide

Deleting an An with Root privileges can delete other s. If you need to delete an : 1. Display the session table to determine whether the has any active sessions. 2. Clear any sessions the has open. 3. Delete the . Note:

To delete an , you first must terminate any active sessions the has open. The is not deleted if there are any open sessions for the .

USING THE GUI 1. To display the session table, select Monitor > System > . 2. To clear an session, click on the checkbox next to the session to select it, then click Delete. 3. To delete the : a. Select Config > System > . b. Click on the checkbox next to the name. c. Click Delete.

USING THE CLI 1. To display the session table, use the following command at the Privileged EXEC level or any configuration level: show session 2. To clear an session, use the following command at the Privileged EXEC level or any configuration level: clear session session-id The session-id is the ID listed in the ID column of the show session output. 3. To delete the , use the following command at the global configuration level: no -name

684 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Lockout

Configuring Lockout By default, there is no limit to the number of times an incorrect can be entered with an to attempt access. You can enable the AX device to lock s for a specific period of time following a specific number of invalid s entered for the . Table 21 lists the lockout parameters you can configure. TABLE 21 Lockout Parameters Parameter Feature state Threshold Reset time

Duration

Description Controls whether s can be locked. Number of failed attempts allowed for an before it is locked. Number of minutes the AX device re a failed attempt. For an to be locked, greater than the number of failed attempts specified by the threshold must occur within the reset time. Number of minutes a locked remains locked. To keep s locked until you or another authorized unlocks them, set the value to 0.

Default Disabled 5 10 minutes

10 minutes

To configure lockout, use either of the following methods.

USING THE GUI To enable the lockout feature: 1. Select Config > System > . 2. Select Lockout Policy on the menu bar. 3. Select Enable lockout Feature. 4. Optionally, change lockout settings. (For descriptions, see Table 21 on page 685.) 5. Click OK.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

685 of 960

AX Series - Configuration Guide To view lockout status or manually unlock a locked : 1. Select Monitor > System > . 2. Select the . 3. Click Unlock.

USING THE CLI 1. Log on through the CLI and access the global configuration level. 2. Optionally, enter the following commands to change lockout settings: lockout threshold number lockout duration minutes lockout reset-time minutes (For descriptions, see Table 21 on page 685.) 3. Use the following command to enable lockout: lockout enable To view lockout status or manually unlock a locked : 1. Log on through the CLI and access the global configuration level. 2. Enter the following command to view the lockout status of an : show -name detail 3. Enter the following command to access the configuration level for the : -name 4. Use the following command to unlock the : unlock

686 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Securing Access by Ethernet

Securing Access by Ethernet By default, certain types of management access through the AX device’s Ethernet interfaces are blocked. Table 22 lists the default settings for each management service. TABLE 22 Default Management Access Management Service SSH Telnet HTTP HTTPS SNMP Ping

Ethernet Management Interface Enabled Disabled Enabled Enabled Enabled Enabled

Ethernet and VE Data Interfaces Disabled Disabled Disabled Disabled Disabled Enabled

You can enable or disable management access, for individual access types and interfaces. You also can use an Access Control List (ACL) to permit or deny management access through the interface by specific hosts or subnets. To set management access through Ethernet interfaces, use either of the following methods. Notes Regarding Use of ACLs If you use an ACL to secure management access, the action in the ACL rule that matches the management traffic’s source address is used to permit or deny access, regardless of other management access settings. For example, if you disable Telnet access to a data interface, but you also enable access to the interface using an ACL with permit rules, the ACL permits Telnet (and all other) access to the interface, for traffic that matches the permit rules in the ACL. If you want certain types of management access to be disabled on an interface, do not use a permit ACL to control management access to the interface. Each ACL has an implicit deny any any rule at the end. If the management traffic’s source address does not match a permit rule in the ACL, the implicit deny any any rule is used to deny access. On data interfaces, you can disable or enable access to specific services and also use an ACL to control access. However, on the management interface,

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

687 of 960

AX Series - Configuration Guide 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 22, click Reset to Default.

USING THE CLI Disabling Management Access To disable management access, use either of the following commands at the global configuration level of the CLI: disable-management service {all | ssh | telnet | http | https | snmp | ping} {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} or disable-management service acl acl-num {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} In both commands, the following options specify the interfaces to protect: • management – The out-of-band Ethernet management interface

(MGMT) • ve ve-num [to ve-num] – A VE data interface or range of VE data inter-

faces • ethernet port-num [to port-num] – An Ethernet data interface or range

of Ethernet data interfaces In the first command, the following options specify the type of management access you are configuring:

688 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Securing Access by Ethernet • all – Disables access to all the management services listed below. • ssh – Disables SSH access to the CLI. • telnet – Disables Telnet access to the CLI. • http – Disables HTTP access to the management GUI. • https – Disables HTTPS access to the management GUI. • snmp – Disables SNMP access to the AX device’s SNMP agent. • ping – Disables ping replies from AX interfaces. This option does not

affect the AX device’s ability to ping other devices. Disabling ping replies from being sent by the AX device does not affect the device’s 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 global configuration level of the CLI: enable-management service {all | ssh | telnet | http | https | snmp | ping} {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} or enable-management service acl acl-num {management | ethernet port-num [to port-num] | ve ve-num [to ve-num]} The options are the same as those for the disable-management command.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

689 of 960

AX Series - Configuration Guide CLI Example: The following command enables Telnet access to data interface 6: AX(config)#enable-management service telnet ethernet 6

Displaying the Current Management Access Settings To display the management access settings that are currently in effect, enter the following command at any level of the CLI: show management

CLI EXAMPLES Here is an example for an AX device that has 10 Ethernet data ports. In this example, all the access settings are set to their default values. AX#show management PING

SSH

Telnet HTTP

HTTPS

SNMP

ACL

-----------------------------------------------------mgmt on

on

off

on

on

on

-

1

on

off

off

off

off

off

-

2

on

off

off

off

off

off

-

3

on

off

off

off

off

off

-

4

on

off

off

off

off

off

-

5

on

off

off

off

off

off

-

6

on

off

off

off

off

off

-

7

on

off

off

off

off

off

-

9

on

off

off

off

off

off

-

10

on

off

off

off

off

off

-

ve1

on

off

off

off

off

off

-

690 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Changing Web Access Settings Here is an example after entering the commands used in the configuration examples above. AX#show management PING

SSH

Telnet HTTP

HTTPS

SNMP

ACL

-----------------------------------------------------mgmt on

on

off

off

on

on

-

1

on

off

off

off

off

off

1

2

on

off

off

off

off

off

1

3

on

off

off

off

off

off

1

4

on

off

off

off

off

off

1

5

on

off

off

off

off

off

1

6

on

off

on

off

off

off

1

7

on

off

off

off

off

off

1

9

on

off

off

off

off

off

1

10

on

off

off

off

off

off

1

ve1

on

off

off

off

off

off

-

Regaining Access if You Accidentally Block All Access If you disable the type of access you are using on the interface you are using at the time you enter a disable-management command, your management session will end. If you accidentally lock yourself out of the device altogether (for example, if you use the all option for all interfaces), you can still access the CLI by connecting a PC to the AX device’s serial port.

Changing Web Access Settings By default, access to the AX management GUI is enabled and is secure. A valid name and are required to . Table 23 lists the default settings for Web access. TABLE 23 Default Web Access Settings Parameter Auto-redirect

HTTP server HTTP port HTTPS server

P e r f o r m a n c e

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 11/3/2010

Default Enabled

Enabled 80 Enabled

691 of 960

AX Series - Configuration Guide TABLE 23 Default Web Access Settings (Continued) Parameter HTTPS port Timeout

aXAPI Timeout

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.

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 1. Select Config > System > Settings. 2. On the menu bar, select Web. 3. Edit the settings you want to change. 4. Click OK. Note:

692 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Changing Web Access Settings

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:

P e r f o r m a n c e

b y

10 minutes 80 443 Enabled Enabled Disabled

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

693 of 960

AX Series - Configuration Guide

Configuring AAA for Access You can configure the AX device to use remote servers for Authentication, Authorization, and ing (AAA) for sessions. The AX device s RADIUS and TACACS+ servers.

Authentication Authentication grants or denies access based on the credentials presented by the person who is attempting access. Authentication for management access to the AX device grants or denies access based on the name and . By default, when someone attempts to to the AX device, the device checks its local database for the name and entered by the person attempting to gain access. Without additional configuration, the authentication process stops at this point. If the name and 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 177 and Figure 178 show the authentication processes used if the AX device is configured to check RADIUS or TACACS+ before checking the local database.

694 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access FIGURE 177 Authentication Process When Remote Authentication Is First (2 remote servers configured) – Example shown is for RADIUS

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

695 of 960

AX Series - Configuration Guide FIGURE 178 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 ed. If the same name is configured in the local database and on the remote server but the s do not match, the order in which the authentication sources are used determines whether the is granted access. Figure 179 shows an example.

696 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access FIGURE 179 Authentication Process When name and On Server Do Not Match the Local Database

name “” Always Authenticated Locally Unlike other s, the name “” has Root privileges. To ensure against accidental lockout from the AX device, “” is always authenticated using the local database only, regardless of the authentication order used for other names.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

697 of 960

AX Series - Configuration Guide

Authorization for GUI Access s who 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 is granted read-only or readwrite access: • If the command level is 14 or 15, the is granted read-write access in the GUI. • If the command level is 0-13, the is granted read-only access in the GUI. Note:

Also see “RADIUS Authorization Based on Service-Type” on page 700.

Note:

This authorization process does not apply to s who through the CLI. (See “Authorization for CLI Access” on page 698.)

Authorization for CLI Access You can configure the AX device to use external RADIUS or TACACS+ servers to authorize commands entered by s who using the CLI. Following successful Authentication, the authenticated party is granted access to specific system resources by Authorization. For an AX , 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--Privilege Read-only- 1 VALUE A10--Privilege Read-write- 2 The first line grants access to the EXEC level and Privileged EXEC level. The ’s CLI session begins at the EXEC level. The can access the Privileged EXEC level, without entering an enable . Access to the configuration level is not allowed.

698 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access as: 3 Using keyboard-interactive authentication. : ******** Last : 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 ’s CLI session begins at the Privileged EXEC level. as: 4 Using keyboard-interactive authentication. : ******** Last : Fri Mar 26 20:03:39 2010 from 192.168.1.140 [type ? for help] AX#

Also see “RADIUS Authorization Based on Service-Type” on page 700.

Note:

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 s who through the GUI. (See “Authorization for GUI Access” on page 698.)

Note:

CLI Access Levels You can use TACACS+ to authorize an to execute commands at one of the following CLI access levels: • 15() – This is the most extensive level of authorization. Com-

mands at all CLI levels, including those used to configure s, are sent to TACACS+ for authorization.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

699 of 960

AX Series - Configuration Guide • 14(config) – Commands at all CLI levels except those used to configure

s are sent to TACACS+ for authorization. Commands for configuring s are automatically allowed. • 1(priv EXEC) – Commands at the Privileged EXEC and EXEC

levels are sent to TACACS+ for authorization. Commands at other levels are automatically allowed. • 0 ( EXEC) – Commands at the 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 for the enable . Access level 0 grants access to the EXEC level only. Note:

Command levels 2-13 are equivalent to command level 1.

Caution:

The most secure option is 15(). 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.

RADIUS Authorization Based on Service-Type AX Release 2.4.3-P2 provides for the RADIUS Service-Type attribute. The following values are ed: • Service-Type= – Allows access to the EXEC level of the

CLI (AX>), and read-only access to the GUI

700 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access • Service-Type=NAS Prompt – Allows access to the Privileged

EXEC level of the CLI (AX#), and read-only access to the GUI • Service-Type=istrative – Allows access to the con-

figuration level of the CLI [AX(config)#], and read-write access to the GUI By default, if the Service-Type attribute is not used, or the A10 vendor attribute is not used, successfully authenticated s are authorized for readonly access. AX Release 2.4.3-P2 allows you to change the default privilege authorized by RADIUS from read-only to read-write. To change the default access level authorized by RADIUS, use the following command at the global configuration level of the CLI: [no] radius-server default-privilege-read-write

ing You can configure the AX device to use external RADIUS or TACACS+ servers for ing. ing keeps track of activities while the is logged on. For AX s, you can configure ing for the following: • /logoff activity (start/stop ing) • Commands

Command ing (TACACS+ only) You can use TACACS+ servers to track attempts to execute commands at one of the following CLI access levels: • 15() – This is the most extensive level of ing. Commands

at all CLI levels, including those used to configure s, are tracked. • 14(config) – Commands at all CLI levels except those used to configure

s are tracked. Commands for configuring s are not tracked. • 1(priv EXEC) – Commands at the Privileged EXEC and EXEC

levels are tracked. Commands at other levels are not tracked. • 0 ( EXEC) – Commands at the EXEC level are tracked. Com-

mands at other levels are not tracked. Note: P e r f o r m a n c e

b y

Command levels 2-13 are equivalent to command level 1.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

701 of 960

AX Series - Configuration Guide

TACACS+ ing Debug Options The same debug levels that are available for TACACS+ Authorization are also available for TACACS+ ing. (See “TACACS+ Authorization Debug Options” on page 700.)

Configuring AAA for Access To configure AAA for access: 1. Prepare the AAA servers: • Add s (names and s). • 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 s: • 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). 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 ing: 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.

702 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access

Configuring Authentication To configure remote authentication, use either of the following methods.

USING THE GUI 1. Select Config > System > . 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 () expected by the server when it receives requests. 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} secret secret-string The secret-string is the shared secret () expected by the server when it receives requests. 2. To add a backup server to use if the primary server can not be reached, repeat the command, using the backup server’s information.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

703 of 960

AX Series - Configuration Guide 3. Use one of the following commands to specify the order in which to use the authentication methods: [no] authentication type { local [radius | talus] | [radius | talus] local } (For more information, see “Authentication Process” on page 694.)

Configuring Authorization Note:

The command syntax shown in this section is simplified to show the required or more frequently used options. For complete syntax information, see the AX Series CLI Reference.

Note:

The configuration options described in this section are available only in the CLI. 1. Add the RADIUS or TACACS+ server(s), if not already added. [no] tacacs-server host {hostname | ipaddr} secret secret-string [no] radius-server host {hostname | ipaddr} secret secret-string 2. Optionally, if using TACACS+, specify the command levels the TACACS+ server will be used to authorize: authorization commands cmd-level method talus [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 698.)

Note:

If using RADIUS, you can set the GUI access levels on the RADIUS server itself. See “Authorization for GUI Access” on page 698. 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 700.)

704 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access

Configuring ing Note:

The command syntax shown in this section is simplified to show the required or more frequently used options. For complete syntax information, see the AX Series CLI Reference.

Note:

The configuration options described in this section are available only in the CLI. 1. Add the RADIUS or TACACS+ server(s), if not already added. [no] tacacs-server host {hostname | ipaddr} secret secret-string [no] radius-server host {hostname | ipaddr} secret secret-string 2. To configure ing for logon/logoff activity, use the following command: [no] ing exec {start-stop | stop-only} {radius | talus} 3. Optionally, if using TACACS+, configure ing for command execution: ing commands cmd-level stop-only talus 4. Optionally, if using TACACS+, enable ing debugging: ing 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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

705 of 960

AX Series - Configuration Guide 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 talus

TACACS+ ing The following commands configure the AX device to use the same TACACS+ server for ing of logon/logoff activity and of all command activity: AX(config)#ing exec start-stop talus AX(config)#ing commands 15 stop-only talus

EXAMPLE INCLUDING RADIUS SERVER SETUP This example shows the AX commands to configure an AX device to use a RADIUS server, and also shows the changes to make on the RADIUS server itself. The RADIUS server in this example is freeRADIUS. The IP address is 192.168.1.157, and the shared secret is “a10rad”. To implement the solution, the following steps are required: 1. On the AX device: a. Add the RADIUS server. b. Enable RADIUS authentication. 2. On the freeRADIUS server: a. In the clients.conf file, add the AX device as a client. b. Add a dictionary file for vendor “a10networks”, and add the file to the dictionary. c. In the s file, add each AX as a . 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

706 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access Configuration on the freeRADIUS Server Changes in clients.conf File The AX device is added to the clients.conf file as a RADIUS client: vi /usr/local/etc/raddb/clients.conf client 192.168.1.0/24 { secret

= a10rad

shortname

= private-network-1

}

In this example, the AX device’s subnet is added as the client.

Note:

Creation of dictionary.a10networks File In the dictionary file, specify the following: • Vendor name – “A10-Networks” • Vendor code – 22610

After authenticating an , the RADIUS server must return the A10--Privilege attribute, with one of the following values: • “Read-only-” – The can access EXEC and Privileged

EXEC commands only. These are commands at the > and # prompts. • “Read-write-” – The can access 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 a10 Exp $

# #

For a complete list of Private Enterprise Codes, see:

# #

http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers

# VENDOR

A10-Networks

P e r f o r m a n c e

b y

22610

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

707 of 960

AX Series - Configuration Guide

BEGIN-VENDOR A10-Networks ATTRIBUTE A10-App-Name

1

String

ATTRIBUTE A10--Privilege

2

integer

VALUE

A10--Privilege Read-only-

1

VALUE

A10--Privilege Read-write-

2

ATTRIBUTE A10-Single-1

51 String

ATTRIBUTE A10-Single-2

52 String

ATTRIBUTE A10-Single-3

53 String

ATTRIBUTE A10-Single-4

54 String

ATTRIBUTE A10-Single-5

55 String

ATTRIBUTE A10-Multi-1

56 String

ATTRIBUTE A10-Multi-2

57 String

ATTRIBUTE A10-Multi-3

58 String

ATTRIBUTE A10-Multi-4

59 String

ATTRIBUTE A10-Multi-5

60 String

END-VENDOR A10-Networks vi /usr/local/share/freeradius/dictionary add $INCLUDE dictionary.a10networks

#new added for a10networks

Changes in s File vi /usr/local/etc/raddb/s read

Auth-Type := Local, - == "test" A10--Privilege = 1

write

Auth-Type := Local, - == "test" A10--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.

708 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access

Procedure Overview To configure Windows IAS for AX RADIUS authentication: 1. On the IAS server, create the following access groups: • AX--Read-Only • AX--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--Read-Only-Policy • AX--Read-Write-Policy).

4. On the IAS server, add AD s to appropriate AX device access groups, either AX--Read-Only or AX--Read-Write. 5. the IAS server in AD. 6. On the AX device, configure RADIUS. 7. Test the configuration by attempting to log onto the AX device with AD s added in step 4. The following sections provide detailed steps for each of these tasks.

Configure Access Groups 1. Select Start > All programs > tools > Active directory 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 s and groups. However, the rest of this section assumes that AD will be used. 1. Open the Computer Management tool by selecting Start > Programs > istrative Tools > Computer Management. 2. Open the System Tools and Local s 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--Read-Only

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

709 of 960

AX Series - Configuration Guide • Group Description – Read-Only Access to AX devices • – Add the using the Add button.

5. Click Create. 6. Enter the following information for the second group: • Group Name – AX--Read-Write • Group Description – Read-Write to AX devices • – Add 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 > istrative Tools > Internet Authentication Service. 2. Right-click on Client and select New Client.

710 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access 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

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:

P e r f o r m a n c e

b y

Do not select “Request must contain the Message Authenticator attribute”. AX RADIUS authentication does not this option.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

711 of 960

AX Series - Configuration Guide

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--Read-Only-Policy

712 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access

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--Read-Only-Policy) and click OK. 7. In the same Add Remote Access Policy dialog box as before, click Add again.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

713 of 960

AX Series - Configuration Guide 8. In the Select Attribute dialog box, double-click Windows-Groups.

714 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access 9. In the Groups dialog box, click Add, then double-click AX-Read-Only group, Click OK to add the group, then click OK once more to confirm the groups.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

715 of 960

AX Series - Configuration Guide 10. In the same Add Remote Access Policy dialog box as before, click Next. 11. Select Grant remote access permission, and click Next.

716 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access 12. Click Edit Profile.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

717 of 960

AX Series - Configuration Guide 13. In the Edit Dial-in Profile dialog box, select the Authentication tab. Select the type of authentication you are using: CHAP and PAP.

718 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access 14. Select the Advanced tab, and click Add. 15. In the RADIUS attributes list, find and double-click the line beginning with Vendor-Specific.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

719 of 960

AX Series - Configuration Guide 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

720 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access 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--Read-Write-Policy • Group to add – AX--Read-Write • Attribute value – 2

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

721 of 960

AX Series - Configuration Guide

Add AD s to AX Access Groups 1. In the Active Directory management console, add the AX access group to the , tester1:

722 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring AAA for Access 2. Make sure Remote Access Permission is enabled:

the IAS Server in Active Directory The IAS RADIUS server must be ed with AD. Otherwise, RADIUS will use compatibility mode instead of AD to authenticate s. 1. Open the IAS main window. 2. Click Action on the menu bar, and click “ server on active directory”.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

723 of 960

AX Series - Configuration Guide

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

Test the Configuration 1. Access the AX CLI command prompt. 2. Enter the name, in the following format: -name@AD-domain-name In this example, use “[email protected]”. 3. Enter the . 4. Press Enter.

724 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide DDoS Protection

Traffic Security Features AX Series devices the following advanced security features: • DDoS protection • SYN Cookies • ICMP rate limiting • Source-IP based connection rate limiting • DNS security • Access Control Lists (ACLs) • 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 787.

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 ed for IPv4. All filters except IP-option are ed for IPv6.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

725 of 960

AX Series - Configuration Guide 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. • T-no-flag – Drops all T packets that do not have any T flags set • T-SYN-FIN – Drops all T packets in which both the SYN and FIN

flags are set • T-SYN-frag – Drops incomplete (fragmented) T Syn packets,

which can be used to launch T Syn flood attacks IP Anomaly Filters for System-Wide PBSLB The following IP anomaly filters are ed specifically for system-wide PBSLB: • Invalid HTTP or SSL payload • Zero-length T 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 ed only for HTTP and HTTPS traffic. (For information about system-wide PBSLB, see “Configuring SystemWide PBSLB” on page 764.)

726 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide DDoS Protection

Enabling DDoS Protection To enable DDoS protection, use either of the following methods.

USING THE GUI 1. Select Config > Service > SLB. 2. On the menu bar, select Global > DDoS Protection. 3. Select each type of DDoS protection filter to enable. To enable all of them, select Drop All. 4. Click OK.

USING THE CLI Use the following command at the global Config level of the CLI: ip anomaly-drop {drop-all | frag | ip-option | land-attack | ping-of-death | t-no-flag | tsyn-fin | t-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 client’s

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

727 of 960

AX Series - Configuration Guide SYN Cookies connection requests. If a client exceeds the threshold, the AX device applies the system-wide PBSLB policy’s over-limit action to the client. The threshold can be set to 1-127 occurrences of the anomaly. The default is 10. Note:

The thresholds are not tracked by PBSLB policies bound to individual virtual ports. SOCKSTRESS_CHECK Session State While the AX device is checking a data packet against the new IP anomaly filters, the client’s session is in the SOCKSTRESS_CHECK state. You might see this state if you are viewing debug output for the client’s session.

Displaying and Clearing IP Anomaly Statistics USING THE CLI\ Select Monitor > Service > Application > Switch.

USING THE CLI To display IP anomaly statistics, use the following command: show slb l4 For system-wide PBSLB, you also can use the following command: show pbslb client [ipaddr] In the output of this command, the counters for a dynamic client are reset to 0 when a client’s dynamic entry ages out. To clear all Layer 4 SLB statistics, including the IP anomaly counters, use the following command: clear slb l4

SYN Cookies AX Series devices provide enhanced protection against T SYN flood attacks, with SYN cookies. SYN cookies enable the AX to continue to serve legitimate clients during a T SYN flood attack, without allowing illegitimate traffic to consume system resources.

728 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide SYN Cookies The AX device s SYN cookies for Layer 4-7 SLB traffic and for Layer 2/3 traffic. • Layer 4-7 SYN cookies protect against T SYN flood attacks directed

at SLB service ports. • Layer 2/3 SYN cookies protect against T SYN flood attacks

attempted in traffic ing through the AX device.

The Service Provided By SYN Cookies SYN cookies enable the AX device to continue to serve legitimate clients during a T SYN flood attack, without allowing illegitimate traffic to consume system resources. During a T SYN flood attack, an attacker sends a large series of T 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 T connection queue to become full, which prevents the AX from establishing new connections for legitimate clients. When SYN cookies are enabled, the feature prevents the AX device’s T connection queue from filling up during T SYN flood attacks. Instead of leaving a half-completed T connection in the queue, the AX replies to each SYN Request with a SYN cookie, which is a special type of SYN ACK, and does not leave a connection in the queue. If the SYN Request is from a legitimate client, the client sends an ACK in response to the SYN cookie. The AX reconstructs the client’s connection information based on information in the SYN ACK, and establishes a connection for the client. However, if the SYN Request is part of an attack, the attacker does not send an ACK, and the AX therefore does not establish a connection. Dynamic SYN Cookies You can configure the on and off thresholds for SYN cookie use by the AX device. The benefit of this feature is that when there is no T SYN attack, T options are preserved. You can configure the following dynamic SYN cookie options: • On-threshold – specifies the maximum number of concurrent half-

open T connections allowed on the AX device, before SYN cookies are enabled. If the number of half-open T 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 T connections for which to keep SYN cookies enabled. If the number of half-open T connections falls below this level, SYN cookies are disabled. You can specify 0-2147483647 halfopen connections. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

729 of 960

AX Series - Configuration Guide 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 T 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 s 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 731.

Enabling Hardware-Based SYN Cookies To enable hardware-based SYN cookies, use following CLI method.

USING THE GUI 1. Select Config > Service > SLB. 2. On the menu bar, select Global > Settings.

730 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide SYN Cookies 3. Select Enabled next to SYN Cookie. 4. In the On Threshold field, enter the maximum number of concurrent half-open T 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 T connections for which to keep SYN cookies enabled. 6. Click OK.

USING THE CLI To enable hardware-based SYN cookies, use the following command at the global Config level of the CLI: [no] syn-cookie [on-threshold num off-threshold num] The command in the following example enables dynamic-based SYN cookies when the number of concurrent half-open T 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. Figure 180 shows an example.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

731 of 960

AX Series - Configuration Guide SYN Cookies FIGURE 180 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 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. 2. Select Virtual Server on the menu bar.

732 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 T port and click Edit, or click Add. 6. If you are configuring a new port, select T 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 To configure Layer 2/3 SYN cookie : 1. Enable Layer 2/3 SYN cookies on individual interfaces. 2. Optionally, modify the threshold for T 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 t syn-cookie The feature is disabled by default. 2. Optionally, to modify the threshold for T handshake completion, use the following command at the global configuration level of the CLI: [no] ip t syn-cookie threshold seconds You can specify 1-100 seconds. The default is 4 seconds. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

733 of 960

AX Series - Configuration Guide ICMP Rate Limiting CLI Example The following commands globally enable SYN cookie , then enable Layer 2/3 SYN cookies on Ethernet interfaces 4 and 5: AX(config)#syn-cookie on-threshold 50000 off-threshold 30000 AX(config)#interface ethernet 4 AX(config-if: ethernet4)#ip t syn-cookie AX(config-if: ethernet4)#interface ethernet 5 AX(config-if: ethernet5)#ip t 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 IM 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 IM 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:

734 of 960

The maximum rate must be larger than the normal rate. P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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: 1. Select Config > Network > Interface. 2. Click on the interface name to display the configuration sections for it. 3. Select the ICMP Rate Limiting checkbox to activate the configuration fields. 4. Enter the normal rate in the Normal Rate field. 5. Enter the maximum rate in the Lockup Rate field. 6. Enter the lockup time in the Lockup Period field. 7. Click OK. To configure ICMP rate limiting in a virtual server template: 1. Select Config > Service > SLB. 2. On the menu bar, select Template > Virtual Server. 3. To edit an existing template, click on the template name. To create a new template, click Add. The Virtual Server section appears. 4. Select the ICMP Rate Limit Status checkbox to enable the configuration fields. 5. Enter the normal rate in the Normal Rate field. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

735 of 960

AX Series - Configuration Guide Source-IP Based Connection Rate Limiting 6. To configure the lockup time, click Lockup Status. 7. Enter the maximum rate in the Lockup Rate field. 8. Enter the lockup time in the Lockup Period field. 9. Click OK.

USING THE CLI To configure an ICMP rate-limiting filter, use the following command. You can enter this command at the global configuration level, the configuration level for a physical or virtual Ethernet interface, or the configuration level for a virtual server template. [no] icmp-rate-limit normal-rate lockup max-rate lockup-time For descriptions of the parameters, see “ICMP Rate Limiting Parameters” on page 734. 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 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:

736 of 960

IP limiting provides a more robust version of the source-IP based connection rate limiting feature. For information, see “IP Limiting” on page 787.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Source-IP Based Connection Rate Limiting

Parameters Source-IP based connection rate limiting is configured using the following parameters: • T 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 738 for more information.) • Exceed actions – Actions to take when the connection limit is exceeded.

All connection requests in excess of the connection limit that are received from a client within the limit period are dropped. This action is enabled by default when you enable the feature, and can not be disabled. You can enable one or both of the following additional exceed actions: • Logging – Generates a log message when a client exceeds the connection limit. • Lockout – Locks out the client for a specified number of seconds. During the lockout period, all connection requests from the client are dropped. The lockout period can be 1-3600 seconds (1 hour). There is no default. By default, logging and lockout are both disabled.

Log Messages The AX device generates two log messages per offending client, per client activity. The first message is generated the first time a client exceeds the connection limit. The message indicates the source (client) address and the destination address of the session. If lockout is configured, the message also indicates that the client is locked out. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

737 of 960

AX Series - Configuration Guide Source-IP Based Connection Rate Limiting 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 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 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.

738 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Source-IP Based Connection Rate Limiting 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 configuration or monitoring of this feature using the GUI.

Note:

To configure source-IP based connection rate limiting, use the following command at the global configuration level of the CLI: slb conn-rate-limit src-ip {t | udp} conn-limit per {100 | 1000} [shared] [exceed-action [log] [lock-out lockout-period]] The t | udp option specifies the Layer 4 protocol. The conn-limit option specifies the connection limit and can be 1-1000000.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

739 of 960

AX Series - Configuration Guide Source-IP Based Connection Rate Limiting 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

Configuration Examples CLI Example 1 The following command allows up to 1000 T 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 t 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

740 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 that they have been reset: AX(config)#show slb conn-rate-limit src-ip statistics Threshold check count 1022000 Honor threshold

count 20532

Threshold exceeded count 1001408 Lockout drops 60 Log messages sent 20532 DNS requests re-transmitted

1000

No DNS response for request 1021000 AX(config)#clear slb conn-rate-limit src-ip statistics AX(config)#show slb conn-rate-limit src-ip statistics Threshold check count 0 Honor threshold

count 0

Threshold exceeded count 0 Lockout drops 0 Log messages sent 0 DNS requests re-transmitted

0

No DNS response for request

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

741 of 960

AX Series - Configuration Guide 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 1. Select Config > Service > Template. 2. On the menu bar, select Application > DNS. 3. Click on the template name or click Add to create a new one. 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}

742 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs) 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.

Access Control Lists (ACLs) You can use Access Control Lists (ACLs) to permit or deny packets based on address and protocol information in the packets. AX devices 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 T/UDP port numbers. • Extended IPv6 ACL – Extended IPv6 ACLs filter based on source and

destination IPv6 addresses, IP protocol, and T/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).

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

743 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) 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 756.) • 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 757.) • To permit or block management access, use the ACL with the enable-

management command. (See “Securing Access by Ethernet” on page 687.) • 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 615.)

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.

744 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs)

USING THE CLI To configure a standard ACL, use the following command: access-list acl-num [seq-num] {permit | deny | remark string} source-ipaddr {filter-mask | /mask-length} [log [transparent-session-only]] The acl-num specifies the ACL number, from 1-99. The seq-num option specifies the sequence number of this rule in the ACL. (See “Resequencing ACL Rules” on page 758.) 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 753.) 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 754.) P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

745 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) When ACL logging is enabled, the AX device writes the log messages to the local logging buffer. If you configure an external log server, the AX device also sends the messages to the server. For more information, see “Log Rate Limiting” on page 50. Note:

If you plan to use an external log server, the server must be attached to an AX data port in order for ACL logging messages to reach the server. They will not reach the server if the server is attached to the AX management port.

CLI EXAMPLE The following commands configure a standard ACL to deny traffic sent from subnet 10.10.10.x, and apply the ACL to inbound traffic received on Ethernet interface 4: AX(config)#access-list 1 deny 10.10.10.0 0.0.0.255 AX(config)#interface ethernet 4 AX(config-if:ethernet4)#access-list 1 in

Configuring Extended IPv4 ACLs To configure an extended IPv4 ACL, use either of the following methods.

USING THE GUI 1. Select Config > Network > ACL. 2. Select Extended on the menu bar. 3. Click Add. 4. Enter or select the values to filter. (For descriptions, see the CLI syntax below.) 5. Click OK. The new ACL appears in the Extended ACL table. 6. Click OK to commit the change.

746 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs)

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 {any | host host-src-ipaddr | net-src-ipaddr {filter-mask | /mask-length}} {any | host host-dst-ipaddr | net-dst-ipaddr {filter-mask | /mask-length}} [log [transparent-session-only]] The acl-num specifies the ACL number, from 100-199. The seq-num option specifies the sequence number of this rule in the ACL. (See “Resequencing ACL Rules” on page 758.) 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 753.) 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

747 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) 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 754.) When ACL logging is enabled, the AX device writes the log messages to the local logging buffer. If you configure an external log server, the AX device also sends the messages to the server. For more information, see “Log Rate Limiting” on page 50. Note:

If you plan to use an external log server, the server must be attached to an AX data port in order for ACL logging messages to reach the server. They will not reach the server if the server is attached to the AX management port. Syntax for Filtering on ICMP Traffic [no] access-list acl-num [seq-num] {permit | deny | remark string} icmp [type icmp-type [code icmp-code]] {any | host host-src-ipaddr | net-src-ipaddr {filter-mask | /mask-length}} {any | host host-dst-ipaddr | net-dst-ipaddr {filter-mask | /mask-length}} [log [transparent-session-only]] The type and code options enable you to filter on ICMP traffic. The type type-option option matches based on the specified ICMP type. You can specify one of the following. Enter the type name or the type number (for example, dest-unreachable or 3). The type-option can be one of the following: • any-type – Matches on any ICMP type. • dest-unreachable | 3 – Type 3, destination unreachable

748 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs) • 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 T or UDP Protocol Port Numbers [no] access-list acl-num [seq-num] {permit | deny | remark string} {t | udp} {any | host host-src-ipaddr | net-src-ipaddr {filter-mask | /mask-length}} [eq src-port | gt src-port | lt src-port | range start-src-port end-src-port] {any | host host-dst-ipaddr | net-dst-ipaddr {filter-mask | /mask-length}} [eq dst-port | gt dst-port | lt dst-port | range start-dst-port end-dst-port] [log [transparent-session-only]]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

749 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) The t 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 t 10.10.10.0 0.0.0.255 10.10.20.5 /32 eq 80 AX(config)#interface ethernet 7 AX(config-if:ethernet7)#access-list 100 in

Configuring Extended IPv6 ACLs To configure an extended IPv4 ACL, use either of the following methods.

USING THE GUI 1. Select Config > Network > ACL. 2. Select IPv6 on the menu bar. 3. Click Add. 4. Enter or select the values to filter. (For descriptions, see the CLI syntax below.) 5. Click OK. The new ACL appears in the IPv6 ACL table. 6. Click OK to commit the change.

750 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs)

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} [log [transparent-session-only]] or [no] {permit | deny} {t | udp} {any | host host-src-ipv6addr | net-src-ipv6addr /mask-length} [eq src-port | gt src-port | lt src-port | range start-src-port end-src-port] {any | host host-dst-ipv6addr | net-dst-ipv6addr /mask-length} [eq dst-port | gt dst-port | lt dst-port | range start-dst-port end-dst-port] [log [transparent-session-only]]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

751 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) Parameter

Description

seq-num

Sequence number of this rule in the ACL. You can use this option to resequence the rules in the ACL.

deny | permit

Action to take for traffic that matches the ACL. deny – Drops the traffic. permit – Allows the traffic.

ipv6 | icmp

Filters on IPv6 or ICMP packets.

t | udp

Filters on T or UDP packets. The t 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 t 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.

752 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs) range start-src-port end-src-port – The ACL matches on traffic from any source port within the specified range. any | host host-dstipv6addr | net-dstipv6addr /masklength Destination IP address(es) to filter. eq dst-port | gt dst-port | lt dst-port | range startdst-port end-dst-port log [transparentsession-only]

For t 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 754.)

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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

753 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) 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] T 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] T 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.

754 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs) IPv6 Sessions For successfully created T 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] T 2001:10::100:4401 > 2001:7::40:22 ACL rule transparent session expired (IPV6_LIST) Feb 24 2010 02:15:08 Notice [AX]:[ve 21] T 2001:10::100:4401 > 2001:7::40:22 ACL rule transparent session created (IPV6_LIST)

For all other types of transparent IPv6 sessions, a message is generated if the packet is forwarded: Feb 24 2010 02:18:07 Notice [AX]:[ve 21] IP 2001:10::100 > 2001:7::40 rule permitted this packet (IPV6_LIST)

ACL

If a T or UDP packet is denied, a message such as the following is generated: Feb 24 2010 02:18:07 Notice [AX]:[ve 21] T 2001:10::100:57373 > 2001:7::40:80 ACL rule transparent session denied (IPV6_LIST)

For all other types of transparent IPv6 sessions, a message such as the following is generated: Feb 24 2010 02:18:07 Notice [AX]:[ve 21] IP 2001:10::100 > 2001:7::40 rule denied this packet (IPV6_LIST)

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 u-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:

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

755 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) AX(config)#ipv6 access-list tran_sess_log1 AX(config-access-list:trans_sess_log1)#permit t any any log transparent-session-only AX(config-access-list:trans_sess_log1)#exit AX(config)#interface ve 21 AX(config-if:ve21)#ipv6 access-list tran_sess_log1 in

Applying an ACL to an Interface To apply a configured ACL to an interface, use either of the following methods.

USING THE GUI To apply an ACL to an Ethernet port: 1. Select Config > Network > Interface. 2. Select LAN on the menu bar. 3. Click on the port number. 4. In the IPv4 section, select the ACL from the Access List field. 5. Click OK. To apply an ACL to a Virtual Ethernet (VE) interface: 1. Select Config > Network > Interface. 2. Select Virtual on the menu bar. 3. Click on the VE name. 4. Select IPv4. 5. Select the ACL from the Access List field. 6. Click OK.

USING THE CLI Access the configuration level for the interface and use the following command: access-list acl-num in

756 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs) 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 AX(config)#interface ethernet 4 AX(config-if:ethernet4)#access-list 1 in

Applying an ACL to a Virtual Server Port You can apply an ACL to a virtual server port. An ACL applied to a virtual server port permits or denies traffic just as an ACL applied to a physical port or Virtual Ethernet (VE) interface does. To apply a configured ACL to a virtual server port, use either of the following methods.

USING THE GUI 1. Select Config > Service > SLB. 2. Select Virtual Server on the menu bar. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

757 of 960

AX Series - Configuration Guide Access Control Lists (ACLs)

Using an ACL to Control Management Access To use an ACL to control management access, see “Securing Access by Ethernet” on page 687.

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.

758 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Access Control Lists (ACLs) Rules are applied to the traffic in the order they appear in the ACL (from the top rule, which is the first, downward). The first rule that matches traffic is used to permit or deny that traffic. After the first rule match, no additional rules are compared against the traffic. Each ACL has an implicit deny any rule at the end of the ACL. This rule is applied to any traffic that does not match any of the configured rules in the ACL. The deny any rule at the end of the ACL is not displayed and cannot be removed. You can resequence the rules in an ACL. When you create an ACL rule, the AX device assigns a sequence number to the rule and places the rule at the bottom of the ACL. Here is an example: AX(config)#access-list 86 permit host 10.10.10.12 AX(config)#access-list 86 deny 10.10.10.0 /24 AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0

In this example, two rules are configured for ACL 86. The default sequence numbers are used. The first rule has sequence number 10, and each rule after that has a sequence number that is higher by 10. The intent of this ACL is to deny all access from the 10.10.10.x subnet, except for access from specific host addresses. In this example, the permit rule for the host appears before the deny rule for the subnet the host is in, so the host will be permitted. However, suppose another permit rule is added for another host in the same subnet. AX(config)#access-list 86 permit host 10.10.10.13 AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0 access-list 86 30 permit host 10.10.10.13 log Hits: 0

By default, since no sequence number was specified when the rule was configured, the rule is placed at the end of the ACL. Because the deny rule comes before the permit rule, host 10.10.10.13 will never be permitted. To resequence the ACL to work as intended, the deny rule can be deleted, then re-added. Alternatively, either the deny rule or the second permit rule can be resequenced to appear in the right place. To change the sequence number of an ACL rule, delete the rule, then re-add it with the sequence number.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

759 of 960

AX Series - Configuration Guide Access Control Lists (ACLs) AX(config)#no access-list 86 30 AX(config)#access-list 86 11 permit host 10.10.10.13 log AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 11 permit host 10.10.10.13 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0

In this example, rule 30 is deleted, then re-added with sequence number 11. The ACL will now work as intended, and permit hosts 10.10.10.12 and 10.10.10.13 while denying all other hosts in the 10.10.10.x subnet. To permit another host, another rule can be added, sequenced to come before the deny rule. AX(config)#access-list 86 12 permit host 10.10.10.14 log AX(config)#show access-list ipv4 86 access-list 86 10 permit host 10.10.10.12 log Hits: 0 access-list 86 11 permit host 10.10.10.13 log Hits: 0 access-list 86 12 permit host 10.10.10.14 log Hits: 0 access-list 86 20 deny 10.10.10.0 0.0.0.255 log Hits: 0

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.

760 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB)

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

761 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) • 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 ed maximum (32767), the parser will use the longest set of digits in the number you enter that makes a valid value. For example, if the file contains 32768, the parser will use 3276 as the value. As another example, if the file contains 111111, the parser will use 11111 as the value. • The ;comment-string is a comment. Everything to the right of the ; is

ignored by the AX device when it parses the file. Example Black/White List Here is an example black/white list: 10.10.1.3 4; blocking a single host. 4 is the drop group 10.10.2.0/24 4; blocking the entire 10.10.2.x subnet 192.168.1.1/32 #20 ; 20 concurrent connections max, any group ok 192.168.4.69 2 20 ; assign to group 2, and allow 20 max

The first row assigns a specific host to group 4. On the AX device, the drop action will be assigned to this group, thus black listing the client. The second row black lists an entire subnet, by asg 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 s dynamic client entries. To configure this feature, add client address 0.0.0.0/0 (wildcard address) to the black/white list used by the system-wide PBSLB policy. When a client sends an HTTP or HTTPS connection request, the AX device checks the system-wide PBSLB policy’s black/white list for the client’s IP address.

762 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB) • If the list does not already have an entry for the client, the AX device

creates a dynamic entry for the client’s host address. • If the list already has a dynamic entry for the client, the AX device

resets the timeout value for the entry. (Dynamic entry aging is described below.) • If the list contains a static entry for the client’s host or subnet address,

the static entry is used instead. Here is an example of a wildcard address in a black/white list: 0.0.0.0/0 1 #20 In this example, all clients who do not match a static entry in the list will be assigned to group 1, and will be limited to 20 concurrent connections. The AX device s up to 8 million dynamic client entries for systemwide PBSLB. Once this limit is reached, the AX device does not track connections or anomaly counters for additional clients. Connection Limit for Dynamic Entries For dynamic entries in a system-wide PBSLB policy’s black/white list, the connection limit in the list applies to each individual client. In the example above, each client that has a dynamic entry in the black/white list will be allowed to have a maximum of 20 concurrent connections. Aging of Dynamic Entries When the AX device creates a dynamic black/white list entry for a client, the device also sets the timeout for the entry. The timeout value for the dynamic entry decrements until the timeout reaches 0 or the client sends a new HTTP or HTTPS connection request. • If the client sends a new HTTP or HTTPS connection request, the time-

out is reset to its full value. • If the timeout reaches 0 and the client does not have any active connec-

tions, the dynamic entry is removed. However, if the client has an active connection, the dynamic entry is not removed until the client’s connection ends. You can set the timeout to 1-127 minutes. The default is 5 minutes. If client-lockup is enabled, the timeout for a locked up client does not begin decrementing until the lockup expires. (See “Client Lockup” on page 765.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

763 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) Wildcard Address in PBSLB Policies Bound to Virtual Ports Dynamic client entries are ed only for system-wide PBSLB policies. You can add a wildcard address (0.0.0.0/0) to a black/white list that is used by a virtual port’s PBSLB policy. The group ID and connection limit specified for the wildcard address will be applied to clients that do not match a static entry in the list. However, there are a few limitations: • The AX device does not create any dynamic entries in the list. • The connection limit applies collectively to all clients that do not have a

static entry in the list.

Configuring System-Wide PBSLB System-wide PBSLB policies provide options that are not available in policies applied to individual virtual ports: • Dynamic black/white-list client entries • Client lockup • IP anomaly checking and tracking, using IP anomaly filters

To configure a system-wide PBLSB policy, use the following commands at the global configuration level of the CLI: [no] system pbslb bw-list name This command specifies the name of the black/white list to use for the policy. [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.

764 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB) [no] system pbslb over-limit [reset] [lockup minutes] [logging minutes] This command specifies the action to take for clients who either exceed the connection limit specified in the black/white list, or exceed the threshold of any of the new IP anomaly filters. You can use one or both of the following options: • reset – Resets all new connection attempts from the client. If you omit

this option, new connection attempts are dropped instead. • lockup – Continues to apply the over-limit action to all new connection

attempts from the client, for the specified number of minutes. The logging option enables logging. The minutes option specifies how often messages can be generated. [no] system pbslb timeout minutes This command sets the timeout for dynamic black/white-list entries. You can specify 1-127 minutes. The default is 5 minutes. 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 763. Displaying and Clearing System-Wide PBSLB Information To display information for system-wide PBSLB, use the following commands: P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

765 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) 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:

766 of 960

These steps assume that the real servers, service groups, and virtual servers have already been configured.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB)

USING THE GUI To Configure PBSLB Settings Using a Policy Template: 1. Select Config > Service > Template. 2. On the menu bar, select Application > PBSLB Policy. 3. Click Add. 4. In the Name field, enter a name for the template. 5. From the drop-down list below the Name field, select the black/white list or click “create” to create or import one. 6. If you clicked “create”, the PBSLB section appears. a. Enter or select the following information in the fields of the PBSLB section: • Name that will be used for the imported black/white list. • Location of the black/white list (Local or Remote). b. To create the list using a text entry field in the GUI, click Local. The Definition field appears. Copy-and-paste or type the black/white list. c. To import a list from a remote server, select Remote. Enter values for the following parameters: • Interval at which the AX device re-imports the list. This option ensures that changes to the list are automatically replicated on the AX device. • File transfer protocol to use. • IP address or hostname of the device where the list is located. • Path and filename of the list on the remote device. d. Click OK. The Policy section reappears. 7. To configure group options: a. Select the group from the Group ID drop-down list. b. Select one of the following from the Action drop-down list. • Drop – Drops new connections until the number of concurrent connections on the virtual port falls below the port’s connection limit. (The connection limit is set in the black/white list.) • Reset – Resets new connections until the number of concurrent connections on the virtual port falls below the connection limit. • service group name – Each of the service groups configured on the AX device is listed. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

767 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) • 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: a. Select Config > Service > SLB. b. On the menu bar, select Virtual Server. c. Click on the virtual server name or click Add to create a new one. d. In the Port section, click Add, or select a virtual port and click Edit. e. In the Virtual Server Port section, select the PBSLB template from the Policy Template drop-down list. f. Click OK. g. Click OK again.

768 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB) FIGURE 181

P e r f o r m a n c e

b y

PBSLB Policy section

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

769 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) FIGURE 182 section

Config > Service > SLB > Virtual Server - Virtual Server Port

USING THE CLI To Import a Black/White List: Use the following command at the global configuration level of the CLI: bw-list name url [period seconds] [load] The name can be up to 31 alphanumeric characters long. The url specifies the file transfer protocol, directory path, and filename. The following URL format is ed: tftp://host/file

770 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB) 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

771 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) • logging [minutes] [fail] – Enables logging. The minutes

option specifies how often messages can be generated. This option reduces overhead caused by frequent recurring messages. For example, if the logging interval is set to 5 minutes, and the PBSLB rule is used 100 times within a five-minute period, the AX device generates only a single message. The message indicates the number of times the rule was applied since the last message. You can specify a logging interval from 0 to 60 minutes. To send a separate message for each event, set the interval to 0. PBSLB rules that use the service service-group-name option also have a fail option for logging. The fail option configures the AX device to generate log messages only when there is a failed attempt to reach a service group. Messages are not generated for successful connections to the service group. The fail option is disabled by default. The option is available only for PBSLB rules that use the service service-group-name option, not for rules with the drop or reset option, since any time a drop or reset rule affects traffic, this indicates a failure condition. Logging is disabled by default. If you enable it, the default for minutes is 3. The AX device uses the same log rate limiting and load balancing features for PBSLB logging as those used for ACL logging. See “Log Rate Limiting” on page 50. Note:

If the def-selection-if-pref-failed option is enabled on the virtual port, log messages will never be generated for server-selection failures. To ensure that messages are generated to log server-selection failures, disable the def-selection-if-pref-failed option on the virtual port. This limitation does not affect failures that occur because a client is over their PBSLB connection limit. These failures are still logged. [no] bw-list over-limit {lockup min | logging min | reset} This command specifies the action to take for traffic that is over the limit. You can specify one or more of the following options: • lockup min – Continues to apply the over-limit action to all new con-

nection attempts from the client, for the specified number of minutes (1-127). • logging min – Generates a log message when traffic goes over the

limit. The min option specifies the terval 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.

772 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB) [no] bw-list use-destination-ip This command matches black/white list entries based on the client’s destination IP address. By default, matching is based on the client’s source IP address. This option is applicable if you are using a wildcard VIP. (See “Wildcard VIPs” on page 277.) To bind the template to a virtual port, use the following command at the configuration level for the port: [no] template policy template-name To Configure PBSLB Settings Directly on a Virtual Port: To bind a black/white list to a virtual port, use the following command at the configuration level for the virtual port: pbslb bw-list name The name is the name you assign to the list when you import it. To map client IP addresses in a black/white list to specific service groups, use the following command at the configuration level for the virtual port: pbslb id id {service service-group-name | drop | reset} [logging [minutes] [fail]]] The id is a group ID in the black/white list and can be from 1 to 31. The service-group-name is the name of an SLB service group on the AX. The drop option immediately drops all connections between the clients in the list and any servers in the service group. The reset option resets the connections between the clients in the list and any servers in the service group. The logging option enables logging. The minutes option specifies how often messages can be generated. This option reduces overhead caused by frequent recurring messages. For example, if the logging interval is set to 5 minutes, and the PBSLB rule is used 100 times within a five-minute period, the AX device generates only a single message. The message indicates the number of times the rule was applied since the last message. You can specify a logging interval from 0 to 60 minutes. To send a separate message for each event, set the interval to 0. The default is 3 minutes. PBSLB rules that use the service service-group-name option also have a fail option for logging. The fail option configures the AX device to generate P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

773 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) log messages only when there is a failed attempt to reach a service group. Messages are not generated for successful connections to the service group. The fail option is disabled by default. The option is available only for PBSLB rules that use the service service-group-name option, not for rules with the drop or reset option, since any time a drop or reset rule affects traffic, this indicates a failure condition. The AX device uses the same log rate limiting and load balancing features for PBSLB logging as those used for ACL logging. See “Log Rate Limiting” on page 50. Note:

If the def-selection-if-pref-failed option is enabled on the virtual port, log messages will never be generated for server-selection failures. To ensure that messages are generated to log server-selection failures, disable the def-selection-if-pref-failed option on the virtual port. This limitation does not affect failures that occur because a client is over their PBSLB connection limit. These failures are still logged. To specify the action to take if the virtual port’s connection threshold is exceeded, use the following command at the configuration level for the virtual port: [no] bw-list over-limit {drop | reset} This command specifies the action to take for traffic that is over the limit. • drop – Drops new connections until the number of concurrent connec-

tions on the virtual port falls below the port’s connection limit. (The connection limit is set in the black/white list.) • reset – Resets new connections until the number of concurrent connec-

tions on the virtual port falls below the connection limit.The connection threshold is set in the black/white list.

Displaying PBSLB Information To show the configuration of a PBSLB policy template, use the following command: show slb template policy template-name To show client IP addresses contained in a black/white list, use the following command: show bw-list [name [detail | ipaddr]] The name is the name you assign to the list when you import it. The ipaddr is the client IP address.

774 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB) To show policy-based SLB statistics, use the following command: show pbslb [name] The name option specifies a virtual server name. If you use this option, statistics are displayed only for that virtual server. Otherwise, statistics are shown for all virtual servers.

CLI CONFIGURATION EXAMPLES The following commands import black/white list “sample-bwlist.txt” onto the AX device: AX(config)#bw-list sample-bwlist tftp://myhost/TFTP-Root/AX_bwlists/samplebwlist.txt AX(config)#show bw-list Name

Url

Size(Byte)

Date

-----------------------------------------------------------------------------sample-bwlist

tftp://myhost/TFTP-Root/AX_

N/A

N/A

bwlists/sample-bwlist.txt Total: 1

The following commands configure a PBSLB template and bind it to a virtual port: AX(config)#slb template policy bw1 AX(config-policy)#bw-list name bw1 AX(config-policy)#bw-list id 2 service srvcgroup2 AX(config-policy)#bw-list id 4 drop AX(config-policy)#exit AX(config)#slb virtual-server PBSLB_VS1 10.10.10.69 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#template policy bw1

The following commands configure the same PBSLB settings directly on a virtual port: AX(config)#slb virtual-server PBSLB_VS2 10.10.10.70 AX(config-slb virtual server)#port 80 http AX(config-slb virtual server-slb virtua...)#pbslb bw-list sample-bwlist AX(config-slb virtual server-slb virtua...)#pbslb id 4 drop AX(config-slb virtual server-slb virtua...)#pbslb id 2 service srvcgroup2

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

775 of 960

AX Series - Configuration Guide Policy-Based SLB (PBSLB) 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

2

0

0

0

4

0

0

0

2

0

0

0

4

0

0

0

Configuration Example—Sockstress Attack Protection You can use system-wide PBSLB in combination with IP anomaly filters to protect against Sockstress attacks, a type of DDoS attack. In this example, the AX device drops all new connection attempts from a client if either of the following occurs: • The client already has 20 active connections and attempts to open a new

HTTP or HTTPS connection. • The client exceeds any of the IP anomaly thresholds.

The lockup period is set to 5 minutes, to continue enforcing the over-limit action for 5 minutes after the over-limit action is triggered. The timeout for dynamic black/white list entries is set to 2 minutes. This example uses the following black/white list: 0.0.0.0/0 1 #20 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:

776 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Policy-Based SLB (PBSLB) AX(config)#show slb l4 Total -----------------------------------------------------------------IP out noroute

20061

T out RST

0

T out RST no SYN

0

... Anomaly out of sequence 225408 Anomaly zero window

225361

Anomaly bad content

224639

The following command shows statistics for the system-wide PBSLB policy: AX(config)#show pbslb system System B/W list: bwlist-wc Virtual Server Port Blacklist/whitelist GID Connection # (Establish Reset Drop) -------------------------------------------------------------------------------System bwlist-wc 1 12 0 0 2 0 0 0

The following command shows summary statistics for individual black/ white-list clients: AX#show pbslb client GID = Group ID, S/D = Static or dynamic entry Out-s = Out of sequence, Zero-w = Zero window, Bad-c = Bad content IP

S/D GID Conn-limit Curr-conn Age

Lockup Out-s Zero-w Bad-c

------------------+---+---+----------+---------+-----+------+-----+------+---40.40.40.168

/32

D

1

20

5

120

0

0

5

5

40.40.40.169

/32

D

1

20

6

0

5

0

6

6

40.40.40.170

/32

D

1

20

6

0

5

0

6

6

40.40.40.171

/32

D

1

20

6

0

5

0

6

6

40.40.40.172

/32

D

1

20

6

0

5

0

6

6

40.40.40.173

/32

D

1

20

2

120

0

0

2

2

40.40.40.174

/32

D

1

20

5

120

0

0

5

5

40.40.40.175

/32

D

1

20

5

120

0

0

5

5

40.40.40.160

/32

D

1

20

5

120

0

0

5

5

40.40.40.161

/32

D

1

20

6

120

0

0

6

6

40.40.40.162

/32

D

1

20

6

0

5

0

6

6

40.40.40.163

/32

D

1

20

6

0

5

0

6

6

40.40.40.164

/32

D

1

20

6

0

5

0

6

6

40.40.40.165

/32

D

1

20

5

120

0

0

5

5

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

777 of 960

AX Series - Configuration Guide 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:

1

Connection limit (0 = no limit):

1984

Current connection:

6

Age:

0 second

Lockup time:

5 minute

Out of sequence:

0

Zero window:

6

Bad content:

6

Geo-location-based Access Control for VIPs 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 client’s location by looking up the client’s subnet in the geo-location database used by Global Server Load Balancing (GSLB). Note:

778 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Geo-location-based Access Control for VIPs

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 client’s 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 client’s IP address; for example, “US”, “US.CA”, or “US.CA.SanJose”. The group-id is a number from 1 to 31 that identifies a group of clients (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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

779 of 960

AX Series - Configuration Guide Geo-location-based Access Control for VIPs Here is a simple example of a black/white list for this feature: L "US"

1

L "US.CA"

2

L "JP"

3

USING THE GUI To configure or import a black/white list using the GUI: 1. Select Config > 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: 1. Select Config > Service > Template. 2. On the menu bar, select Application > PBSLB Policy. 3. Click Add. 4. In the Name field, enter a name for the template. 5. From the drop-down list below the Name field, select the black/white list. 6. Select a group ID from the Group ID drop-down list. 7. Select one of the following from the Action drop-down list. • Drop – Drops new connections until the number of concurrent con-

nections on the virtual port falls below the port’s connection limit. (The connection limit is set in the black/white list.) • Reset – Resets new connections until the number of concurrent connections on the virtual port falls below the connection limit.

780 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Geo-location-based Access Control for VIPs • 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 50.) 9. Click Add. 10. Repeat step 6 through step 9 for each group ID. 11. Click OK. To load the IANA geo-location database: 1. Select Config > Service > GSLB. 2. On the menu bar, select Geo-location > Import. 3. In the Load/Unload section, enter “iana” in the File field. Leave the Template field blank. 4. Click Add. If preferred, you can import a custom geo-location database instead. For information, see “Loading or Configuring Geo-Location Mappings” on page 467.

Note:

To apply the policy template to a virtual port: 1. Select Config > Service > SLB. 2. On the menu bar, select Virtual Server. 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

781 of 960

AX Series - Configuration Guide Geo-location-based Access Control for VIPs 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 ed: tftp://host/file 2. To configure a PBSLB template, use the following commands: [no] slb template policy template-name Enter this command at the global configuration level of the CLI. The command creates the template and changes the CLI to the configuration for the template, where the following PBSLB-related commands are available. [no] bw-list name file-name This command binds a black/white list to the virtual ports that use this template. [no] bw-list id id service {service-group-name | drop | reset} [logging [minutes] [fail]] This command specifies the action to take for clients in the black/white list: • id – Group ID in the black/white list. • service-group-name – Sends clients to the SLB service group 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}

782 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Geo-location-based Access Control for VIPs 4. To apply the policy template to a virtual port, use the following command at the configuration level for the virtual port: [no] template policy template-name 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} ]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

783 of 960

AX Series - Configuration Guide Geo-location-based Access Control for VIPs CLI Example The following command imports black/white list “geolist” onto the AX device. AX(config)#import bw-list geolist s://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 AX(config-policy)#exit

The following commands apply the policy template to port 80 on virtual server “vip1”: AX(config)#slb virtual-server vip1 AX(config-slb virtual server)#port 80 http 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 The current release does not this feature in 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

784 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Geo-location-based Access Control for VIPs 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 client’s connection is permitted. Likewise, the permit counter is incremented only for that specific geo-location level. Table 24 shows an example set of geo-location connection limits and current connections. TABLE 24 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 client’s specific geo-location, but for all geo-locations higher up in the domain tree. Based on full-domain checking, all three connection requests from the 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:

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

785 of 960

AX Series - Configuration Guide Geo-location-based Access Control for VIPs • US – Deny counter is incremented by 1. • US.CA – Deny counter is incremented by 1.

USING THE GUI The current release does not this feature in 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:

786 of 960

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.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 up to 255 class lists. Each class list can contain up to 8 million host IP addresses and 64,000 subnets.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

787 of 960

AX Series - Configuration Guide 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.

788 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

789 of 960

AX Series - Configuration Guide 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 T, the AX device sends a T 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 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 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.

790 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

791 of 960

AX Series - Configuration Guide Configuring Source IP Limiting

USING THE GUI Importing a Class List onto the AX Device 1. Select Config > Service > SLB. 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, R, or S. 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 and fields, enter the name and required for access to the remote server. 13. Click OK. Configuring a Class List in the GUI 1. Select Config > Service > SLB. 2. On the menu bar, select Class List. 3. Click Create. 4. In the Name field, enter a name for the class list.

792 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

793 of 960

AX Series - Configuration Guide Configuring Source IP Limiting The file-name specifies the name the class list will have on the AX device. The url specifies the file transfer protocol, name (if required), and directory path. You can enter the entire URL on the command line or press Enter to display a prompt for each part of the URL. If you enter the entire URL and a is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]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.

794 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting 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 798.

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 1. Select Config > Service > Template. 2. On the menu bar, select Application > PBSLB Policy. 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 789.) 6. Leave the Destination IP and Overlap options disabled. 7. Click OK. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

795 of 960

AX Series - Configuration Guide Configuring Source IP Limiting Configuring Standalone IP Limiting Rules for System-Wide IP Limiting 1. Select Config > Service > SLB. 2. On the menu bar, select LID. 3. Configure the IP limiting rules. (For parameter information, see “IP Limiting Rules” on page 789.) 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: [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 level for the template, where the following commands are available. For information about the valid values and defaults, see “IP Limiting Rules” on page 789. [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.

796 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting [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 796.) Specifying the Match IP Address 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 • 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]}

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

797 of 960

AX Series - Configuration Guide Configuring Source IP Limiting 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 792 • “Configuring Standalone IP Limiting Rules for System-Wide IP Limit-

ing” on page 796 Applying Source IP Limiting to a Virtual Server 1. Select Config > Service > SLB. 2. On the menu bar, select Virtual Server. 3. Click on the virtual server name or click Add 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.

798 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting 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 798.) 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 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: [no] template policy template-name Applying Source IP Limiting to a Virtual Port To apply source IP limiting to a virtual port, use the following command at the global configuration level for the virtual port: [no] template policy template-name

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

799 of 960

AX Series - Configuration Guide Configuring Source IP Limiting

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

800 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting

CLI Examples—Configuration The examples in this section show how to configure IP limiting.

Configure System-Wide IP Limiting With a Single Class The following commands configure a standalone IP limiting rule to be applied globally to all IP clients (the clients that match class list “global”): AX(config)#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 AX(config-policy)#exit

The following command imports the class list used by the policy: AX(config)#import class-list global_list ftp: Address or name of remote host []?1.1.1.2 name []?ax []?********* File name [/]?global_list

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

801 of 960

AX Series - Configuration Guide Configuring Source IP Limiting 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)#class-list lid 1 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-policy-policy lid)#exit AX(config-policy)#exit

The following command imports the class list used by the policy: AX(config)#import class-list vs_list ftp: Address or name of remote host []?1.1.1.2 name []?ax []?********* 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

802 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting

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)#class-list lid 1 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-policy-policy lid)#exit AX(config-policy)#exit

The following command imports the class list used by the policy: AX(config)#import class-list vp_list ftp: Address or name of remote host []?1.1.1.2 name []?ax []?********* 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)#port 80 http AX(config-slb virtual server-slb virtua...)#template policy vp_policy

CLI Examples—Display This section shows example show command output for IP limiting.

Class Lists The following command displays the class-list files on the AX device: AX#show class-list Name

IP

Subnet

Location

test

4

3

file

-limit

14

4

config

Total: 2

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

803 of 960

AX Series - Configuration Guide Configuring Source IP Limiting Table 25 describes the fields in the command output. TABLE 25 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:

4

Total IP subnet:

3

Content: 1.1.1.1 /32 glid 1 2.2.2.2 /32 glid 2 10.1.2.1 /32 lid 1 10.1.2.2 /32 lid 2 20.1.1.0 /24 lid 1 20.1.2.0 /24 lid 2 0.0.0.0 /0 lid 31

The following commands show the closest matching entries for specific IP addresses in class list “test”: AX#show class-list test 1.1.1.1 1.1.1.1 /32 glid 1 AX#show class-list test 1.1.1.2 0.0.0.0 /0 lid 31

The class list contains an entry for 1.1.1.1, so that entry is shown. However, since the class list does not contain an entry for 1.1.1.2 but does contain a wildcard entry (0.0.0.0), the wildcard entry is shown.

804 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Source IP Limiting

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 conn-rate-limit 2000 per 10 request-limit 200 request-rate-limit 200 per 1 over-limit-action reset log 3 lid 30 conn-limit 10000 conn-rate-limit 1000 per 1 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 conn-rate-limit 100 per 10 request-limit 1 request-rate-limit 10 per 10 over-limit-action reset log 1

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

805 of 960

AX Series - Configuration Guide Configuring Source IP Limiting

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: F = Flag (C-Connection, R-Request), Over-RL = Over rate limit 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: F = Flag (C-Connection, R-Request), Over-RL = Over rate limit 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

806 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

Role-Based istration The AX Series provides Virtualized Management, through Role-Based istration (RBA). RBA allows s (“s”) to configure and view SLB resources based on istrative domains (“partitions”). RBA s separate partitions for these types of resources. Partitioning allows the AX device to be logically segmented to separate configurations for different customers; for example, separate companies or separate departments within an enterprise. s assigned to a partition can manage only the resources inside that partition. Note:

P e r f o r m a n c e

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 11/3/2010

807 of 960

AX Series - Configuration Guide Overview

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

Role-Based istration

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. s 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 s can add, modify, delete and save only the resources in B.com's partition. The following sections describe RBA in more detail.

808 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview

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

configured only by s 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

s who are assigned to it, and by s 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 s who have Root or Read Write privileges. A maximum of 128 partitions are ed. (For descriptions of privileges, see Table 26 on page 811.) 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 s 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

809 of 960

AX Series - Configuration Guide 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 184

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 s 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 ed for each partition.

810 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview FIGURE 185

Configurable Partition Logos

Roles The type of access (read-only or read-write) allowed to an , and the partitions where the access applies, depend on that ’s privilege level (role). An can have one of the privilege levels listed in Table 26 on page 811. The “Partition” privilege levels apply specifically to s who are assigned to private partitions.

Note:

Table 26 describes the roles. TABLE 26 Privilege Levels Privilege Level (Role) Root

Access to Shared Partition Read-write

Read Write Read Only Partition Write

Read-write Read-only Read-only

P e r f o r m a n c e

Access to Private Partition Read-write Read-write Read-only Read-write, for the partition to which the is assigned

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

Can configure other s

Can Change Own ?

Yes1 No No No

Yes2 Yes No Yes

811 of 960

AX Series - Configuration Guide Overview TABLE 26 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 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 s No

Can Change Own ? No

No

No

No other read-only or read-write privileges are granted. All access is restricted to the partition to which the is assigned. 1. Only the named “” is allowed to configure other s, and cannot be deleted. Otherwise, the Root and Read-write privilege levels are the same. 2. The Root privilege level can also change the s of other s.

Types of Resources That Can Be Viewed and Saved By Private Partition s All s can view resources in the shared partition. However, the only s who can add, modify, or delete resources in the shared partition are s with Root or Read Write privileges. s who are assigned to a partition can view but not modify resources in the shared partition. s 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 assigned to a partition displays the running-config or startup-config, only the resources within the partition are listed. Likewise, when an assigned to a private partition saves the configuration, only the startup-config for that partition is modified. The configuration changes in the partition’s running-config are copied to the partition’s startup-config. Only s with Root or Read Write privileges can select the partition(s) for which to save changes. s 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 s have no other privileges.

812 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Role-Based istration

Configuring Role-Based istration To configure role-based istration, using an with Root privileges, and perform the following steps: 1. Configure partitions. 2. Configure s 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 with Partition-write privileges who is assigned to the partition. Note:

This document shows how to set up partitions and assign s to them. The partition s 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 s for the partition.

Note:

To configure s, 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 1. Select Config > System > . 2. On the menu bar, select Partition. 3. Click New. The Partition section appears. 4. Enter a name for the partition. 5. To a logo for the partition, click Browse and navigate to the logo file. 6. If a partition logo is not ed, the A10 Networks logo is used by default. 7. Click OK. The new partition appears in the partition list.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

813 of 960

AX Series - Configuration Guide Configuring Role-Based istration FIGURE 186

Config > System > > Partition

FIGURE 187

Config > System > > Partition - List

USING THE CLI To configure a private partition, use the following command at the global configuration level of the CLI: 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 814.)

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 attempts to add more aFleX policies than are allowed for the partition, an error message is displayed to the . You can specify a maximum of 1-128 aFleX policies, on an individual partition basis.

814 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Role-Based istration

USING THE GUI 1. Select Config > System > . 2. On the menu bar, select Partition. 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. 5. Click OK.

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 specify 1-128. The default is 32.

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

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

USING THE CLI To delete a partition, use the following command at the global configuration level of the CLI: no partition [partition-name] P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

815 of 960

AX Series - Configuration Guide Configuring Role-Based istration If you do not specify a partition name, the CLI displays a prompt to whether you want to delete all partitions and the resources within them. Enter “y” to confirm or “n” to cancel the request.

Configuring Partition s To configure s and assign them to partitions, use either of the following methods. Note:

To delete an , see “Deleting an ” on page 684.

USING THE GUI To configure an for a private partition: 1. Select Config > System > (if not already selected). 2. On the menu bar, select Management. 3. Click New. The section appears. 4. Enter a name and for the . 5. From the Role drop-down list, select one of the following: • Partition Write – Gives read-write privileges within the par-

tition you select below. • Partition Read – Gives read-only privileges within the partition you select below. • Partition RS Operator – Allows the 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 asg the . 7. Click OK. The new appears in the list with their respective partition logos.

816 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Role-Based istration FIGURE 188

Config > System > > Management

USING THE CLI To configure an for a private partition, use the following commands: [no] -name string [no] privilege {partition-write | partition-read | partition-enable-disable} partition-name The command creates the and changes the CLI to the configuration level for the . The command syntax shown here includes the option. You can specify the with the command, or with the separate command at the configuration level for the . The default is “a10”. The privilege command specifies the privilege level for the and assigns the to a partition. (The partition-enable-disable option gives Partition Real Server Operator privileges.) Note:

P e r f o r m a n c e

b y

The other configuration commands do not apply specifically to role-based istration. For information about these other commands, see “Configuring Additional s” on page 679.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

817 of 960

AX Series - Configuration Guide Configuring Role-Based istration

CLI Example The following commands configure two private partitions, “companyA” and “companyB”, and 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 s

-----------------------------------------------------companyA

32

0

companyB

32

0

The following commands configure an for each partition: AX(config)# compA compApwd AX(config-:compA)#privilege partition-write companyA Modify successful ! AX(config-:compA)#exit AX(config)# compB compBpwd AX(config-:compB)#privilege partition-write companyB Modify successful ! AX(config-:compB)#exit

The following command displays the s: AX(config)#show Name

Status

Privilege Partition

------------------------------------------------------

Enabled

Root

compA

Enabled

P.R/W

companyA

compB

Enabled

P.R/W

companyB

The show command shows privilege information as follows: • Root – The has Root privileges. • R/W – The has Read Write privileges. • R – The has Read Only privileges. • P.R/W – The is assigned to a private partition and has Partition-

write (read-write) privileges within that partition.

818 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Viewing and Saving the Configuration • P.R – The is assigned to a private partition and has Partition-read

(read-only) privileges within that partition. • P.RS Op – The 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.

Viewing and Saving the Configuration s with Root, Read Write, or Read Only privileges can view resources in any partition. s 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. s with Root or Read Write privileges can save resources in any partition. s 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 821.

USING THE CLI To view the configuration, use the following commands: show running-config [all-partitions | partition partition-name] show startup-config [all-partitions | partition partition-name] If you enter the command without either option, the command shows only the resources that are in the shared partition. The all-partitions option shows all resources in all partitions. In this case, the resources in the shared partition are listed first. Then the resources in each private partition are listed, organized by partition. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

819 of 960

AX Series - Configuration Guide Viewing and Saving the Configuration If you specify a private partition-name, only the resources in that partition are listed. Note:

If an 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 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 [all-partitions | partition partition-name] If you enter the command without either option, the command saves only the changes for resources that are in the current partition. The all-partitions option saves changes for all resources in all partitions. If you specify a private partition-name, only the changes for the resources in that partition are saved.

820 of 960

Caution:

Before saving all partitions or before a reload, reboot, or shutdown operation, a Root or Read Write should notify all partition s to save their configurations if they wish to. Saving all partitions without consent from the partition s is not recommended.

Note:

The all-partitions and partition partition-name options are not applicable for s with Partition-write privileges. Partition s can only save their respective partitions. For these s, the command syntax is

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Switching To Another Partition the same as in previous releases. The options are available only to s 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 ed 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 s with Root, Read Write, or Read Only privileges can select the partition to view. When an 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. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

821 of 960

AX Series - Configuration Guide 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

Synchronizing the Configuration When an 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 with Root or Read Write privileges can specify any partitions(s) to synchronize. Note:

If you plan to synchronize the Active AX device’s running-config to the Standby AX device’s running-config, make sure to use one of the following synchronization options. Performing any one of these options ensures that new private partitions appear correctly in the Standby AX device’s configuration. – Synchronize all partitions – Synchronize the shared partition to the startup-config first, then synchronize the private partition to the running-config. – On the Active AX device, synchronize the shared partition to the running-config first. Log onto the Standby AX device and save the shared partition (write memory partition shared). Then, on the Active AX device, synchronize the private partition to the running-config.

Note:

In the current release, HA config-sync to a partition is ed only for Active-Standby HA configurations.

USING THE GUI In the GUI, the synchronization applies only to the current partition.

822 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Synchronizing the Configuration

USING THE CLI The ha sync commands have new options that enable you to specify the partition. For s with Root or Read Write privileges, here is the new syntax for the ha sync commands: ha sync all {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ha sync startup-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ha sync running-config {to-startup-config [with-reload] | to-running-config} [all-partitions | partition partition-name] ha sync data-files [all-partitions | partition partition-name] 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 s 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 s with Partition Write privileges are not allowed to synchronize to the running-config or to reload the other AX device.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

823 of 960

AX Series - Configuration Guide Operator Management of Real Servers

Operator Management of Real Servers This section is for s 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. with your Partition-enable-disable . 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 189

Note:

Real Server Management in Operator Mode

Although the GUI displays the Delete and New buttons, these buttons are not ed for s with Partition Real Server Operator privileges. To Disable or Re-Enable Individual Real Server Ports 1. with your Partition Real Server Operator . 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.

824 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Operator Management of Real Servers 5. Select the port numbers you want to disable or re-enable. A single row appears for each port number. Selecting a row selects the port number on each of the real servers you selected in step 2. 6. Click Disable or Enable. 7. Click OK. FIGURE 190

Disabling Service Ports – Selecting the Servers

FIGURE 191

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, with your Partition-enable-disable and use the following command: show slb server [server-name] [config]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

825 of 960

AX Series - Configuration Guide Operator Management of Real Servers CLI Example as:compAoper Welcome to AX Using keyboard-interactive authentication. :******** Last : Wed Aug 20 08:58:45 2008 from 192.168.1.130 [type ? for help] AX>show slb server Total Number of Services configured: 2 Current = Current Connections, Total = Total Connections Fwd-pkt = Forward packets, Rev-pkt = Reverse packets Service

Current

Total

Fwd-pkt Rev-pkt

State

-----------------------------------------------------------------------------compArs1:80/t

23

320543

1732383

1263164

compArs1: Total

23

321024

1732383

1263164

Up /60 ms Up

AX>show slb server config Total Number of Services configured: 2 H-check = Health check Service

Max conn = Max. Connection

Address

H-check

Wgt = Weight

Status

Max conn Wgt

-----------------------------------------------------------------------------compArs1:80/t

7.7.7.7

Default

Enable

1000000

1

compArs1

7.7.7.7

Default

Disable

1000000

1

compArs2:80/t

8.8.8.8

Default

Enable

1000000

1

compArs2

8.8.8.8

Default

Enable

1000000

1

To Disable or Re-Enable Servers Use the following commands to access the configuration level of the CLI: enable config The enable command accesses the Privileged EXEC level. The end of the command prompt changes from > to #. If you are prompted for a , enter the enable assigned by the root . 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]

826 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Operator Management of Real Servers Use one of the following commands to change the state of the server: {disable | enable} To the state change, use the show slb server command. To Disable or Re-Enable Real Service Ports Access the configuration level, then use the following command to access the operation level for the server: slb server server-name [ipaddr] Use the following command to access the operation level for the service port: port port-num {t | udp} Use one of the following commands to change the state of the service port: {disable | enable} To the state change, use the show slb server command. CLI Example The following commands access the configuration level and disable real server “compArs1” and the change: AX>enable :******** 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 Current = Current Connections, Total = Total Connections Fwd-pkt = Forward packets, Rev-pkt = Reverse packets Service Current Total Req-pkt Rev-pkt State/Rsp Time -----------------------------------------------------------------------------compArs1:80/t 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/t

7.7.7.7

Default

Enable

1000000

1

compArs1

7.7.7.7

Default

Disable

1000000

1

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

827 of 960

AX Series - Configuration Guide Operator Management of Real Servers

828 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 381. For information about GSLB parameters, see “Global Server Load Balancing” on page 435. For information about FWLB parameters, see “Firewall Load Balancing” on page 333.

Service Template Parameters 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 361.

Note:

Table 29 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: • T • HTTP • Connection Reuse (The parameters in this default template are all

unset.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

829 of 960

AX Series - Configuration Guide Service Template Parameters For information about the default settings in a template, see the section in this chapter that describes the template. To override the settings in a default template, you must configure another template of the same type and apply that template to the service port instead. For example, to override the settings that will be applied from the HTTP 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 port’s service type, so when you add a template to the virtual port, the other template of the same type is automatically removed from the virtual port. TABLE 27 Template Types Valid for Service Types Service Type

Template Type

FastHTTP

Cache

H T T P

H T T P S

V

V

F T P

M M S

R T S P

S I P

SIPT

V

Client SSL 1 Connection Reuse

V

V

V

Cookie Persistence

V

V

V

V

DNS

S I P S

S M T P

SSLProxy

V

V

V

T C P

U D P

Others

V

V

V

Destination-IP

V

Persistence 2 HTTP

V

V

V

Policy

V

V

V

V

V

V

V

Server SSL Source-IP Persistence

V

V V

V V

V V

SIP

V

V

V

V

V

V V

V

V

V

V

V

V

V

V

SMTP

V

SSL Session-ID Persistence

V

Streamingmedia T

V

V V

V

V

V V

T-Proxy UDP

V V

V

V

V

V

V

V

V

V

V

V

V

V

1. To use a client-SSL template, you must install a valid certificate and key on the AX device, then configure the template to refer to the certificate and key. 2. Destination-IP persistence templates apply only to wildcard virtual ports.

830 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters

Cache Template Parameters Table 28 lists the parameters you can configure in RAM caching templates. TABLE 28 Cache Template Parameters Parameter Template name

Age time

Description and Syntax Name of the template.

ed 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

Config > Service > Template > Application > 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

Config > Service > Template > Application > RAM Caching Enables for the following Cache-Control headers:

Enabled or disabled Default: disabled

• Cache-Control: no-cache • Cache-Control: max-age=0 When 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

Config > Service > Template > Application > 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 Config > Service > Template > Application > RAM Caching

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

831 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 28 Cache Template Parameters (Continued) Parameter Maximum object size

Description and Syntax Maximum object size that can be cached. The AX device will not cache objects larger than this size.

Minimum object size

Config > Service > Template > Application > RAM Caching minimum object size that can be cached. The AX device will not cache objects smaller than this size.

ed 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

Config > Service > Template > Application > 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. Config > Service > Template > Application > RAM Caching

host

832 of 960

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 ed 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] -host Config > Service > Template > Application > RAM Caching

Default: Disabled

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 28 Cache Template Parameters (Continued) Parameter Age header insertion

Via header insertion

Cookie removal

Description and Syntax Disables insertion of Age headers into cached responses. [no] disable-insert-age Config > Service > Template > Application > RAM Caching Enables insertion of Via headers into cached responses. [no] disable-insert-via Config > Service > Template > Application > 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.)

ed Values Default: Disabled (Age header insertion is enabled.)

Default: Disabled (Age header insertion is enabled.)

Default: Disabled

[no] remove-cookies

Replacement policy

Note: The current release does not configuration of this option using the GUI. 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 ed in the current release is Least Frequently Used (LFU). Default: LFU

[no] replacement-policy LFU Config > Service > Template > Application > RAM Caching

Client SSL Template Parameters Table 29 lists the parameters you can configure in client SSL templates. TABLE 29 Client SSL Template Parameters Parameter Template name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template client-ssl template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > SSL > Client SSL

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

833 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 29 Client SSL Template Parameters (Continued) Parameter Certificate Authority (CA) certificate name

Description and Syntax Name of the Certificate Authority (CA) certificate to use for validating client certificates.

ed Values Name of a CA certificate imported onto the AX device

[no] ca-cert cert-name Config > Service > Template > SSL > Client SSL

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 Config > Service > Template > SSL > Client SSL

Certificate key-chain name

Note: To use the certificate, you must import it onto the AX device. (See “Importing SSL Certificates” on page 467.) Chain of certificates to use for terminating or initiating SSL connections with clients.

String of 1-31 characters

[no] chain-cert chain-cert-name Certificate key

Config > Service > Template > SSL > Client SSL Key for the certificate, and the phrase used to encrypt the key.

Key name: string of 1-31 characters

[no] key key-name [phrase phrase-string]

Default: None configured

phrase: string of 1-16 characters

Config > Service > Template > SSL > Client SSL

834 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 29 Client SSL Template Parameters (Continued) Parameter AX response to connection request from client

Description and Syntax Action that the AX device takes in response to a client’s connection request. [no] client-certificate {ignore | request | require} Config > Service > Template > SSL > Client SSL

ed 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 ing 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 Config > Service > Template > SSL > Client SSL 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)

Config > Service > Template > SSL > Client SSL

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

835 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 29 Client SSL Template Parameters (Continued) Parameter Ciphers

Description and Syntax Cipher suite to for decrypting certificates from clients.

ed 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_64_CBC_SHA

• 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_AES_256_SHA • TLS1_RSA_EXPORT1024_RC4_56 _MD5 • TLS1_RSA_EXPORT1024_RC4_56 _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 30 lists the parameters you can configure in connection reuse templates. TABLE 30 Connection Reuse Template Parameters Parameter Template name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template connection-reuse template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > Connection Reuse

836 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 30 Connection Reuse Template Parameters (Continued) Parameter Connection limit

Description and Syntax Maximum number of reusable connections per server port.

ed 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

Config > Service > Template > Connection Reuse 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

Config > Service > Template > Connection Reuse 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)

Config > Service > Template > Connection Reuse

Cookie Persistence Template Parameters Table 31 lists the parameters you can configure in cookie persistence templates. TABLE 31 Cookie Persistence Template Parameters Parameter Template name

Cookie expiration

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template persist cookie template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > Persistent > Cookie Persistence Number of seconds a cookie persists on a client’s PC before being deleted by the client’s browser. [no] expire expire-seconds Config > Service > Template > Persistent > Cookie Persistence

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/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.

837 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 31 Cookie Persistence Template Parameters (Continued) Parameter Domain

Path

Insert always

Description and Syntax Adds the specified domain name to the cookie.

ed Values Valid domain name

[no] domain domain-name

Default: Not set

Config > Service > Template > Persistent > Cookie Persistence Adds path information to the cookie.

1-31 characters

[no] path path-name

Default: “ / ”

Config > Service > Template > Persistent > Cookie 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. One of the following:

• 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 Config > Service > Template > Persistent > Cookie 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 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} Config > Service > Template > Persistent > Cookie Persistence

838 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 31 Cookie Persistence Template Parameters (Continued) Parameter Cookie name

Description and Syntax Specifies the name of the persistence cookie. The format of the cookie depends on the match type.

ed Values String of 1-63 characters Default: sto-id

[no] name cookie-name

Ignore connection limits

Config > Service > Template > Persistent > Cookie 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 Config > Service > Template > Persistent > Cookie Persistence

Destination-IP Persistence Template Parameters Table 32 lists the parameters you can configure in destination-IP persistence templates. TABLE 32 Destination-IP Persistence Template Parameters Parameter Template name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template persist destination-ip template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > Persistent > Destination IP Persistence

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

839 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 32 Destination-IP Persistence Template Parameters (Continued) Parameter Match type

Description and Syntax Granularity of persistence:

ed Values One of the following:

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

• Port (selectable in the GUI but not 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 {server | service-group} Config > Service > Template > Persistent > Destination IP Persistence

840 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 32 Destination-IP Persistence Template Parameters (Continued) Parameter Netmask

Description and Syntax Granularity of IP address hashing for initial server port selection. You can specify an IPv4 network mask in dotted decimal notation.

ed 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

Config > Service > Template > Persistent > Destination 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

[no] timeout timeout-minutes

Ignore connection limits

Config > Service > Template > Persistent > Destination IP 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 client source IP address.

Enabled or Disabled Default: Disabled. By default, the connection limit set on real servers and real ports is used.

[no] dont-honor-conn-rules Config > Service > Template > Persistent > Destination IP Persistence

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

841 of 960

AX Series - Configuration Guide Service Template Parameters

DNS Template Parameters Table 33 lists the parameters you can configure in DNS templates. TABLE 33 DNS Template Parameters Parameter Template name

Action for malformed DNS queries (DNS security)

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template dns template-name

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

[no] slb template dns template-name Config > Service > Template > Application > DNS

HTTP Template Parameters Table 34 lists the parameters you can configure in HTTP templates. TABLE 34 HTTP Template Parameters Parameter Template name

Failover URL

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template http templatename

Default: “default”. The default template has the default values listed 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 Config > Service > Template > Application > HTTP

842 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 34 HTTP Template Parameters (Continued) Parameter Retry and reassignment when server replies with 5xx status code

Description and Syntax Configures the AX device to retry sending a client’s request to a service port that replies with an HTTP 5xx status code, and reassign the request to another server if the first server replies with a 5xx status code.

ed 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 Config > Service > Template > Application > HTTP By default, logging of HTTP retries is disabled by default. To enable logging of HTTP retries, use the following command at the configuration level for the HTTP template: [no] log-retry Note: The current release does not configuration of the log-retry option using the GUI.

Logging of retries

Note: This option is ed only for virtual port types HTTP and HTTPS. It is not ed for fastHTTP or any other virtual port type. Logs HTTP retries. An HTTP retry occurs when the AX device resends a client’s 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 Note: The current release does not configuration of this option using the GUI.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

Enabled or disabled Default: disabled

843 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 34 HTTP Template Parameters (Continued) Parameter Compression

Description and Syntax Offloads Web servers from U-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} Config > Service > Template > Application > HTTP Note: Compression is ed only for HTTP and HTTPS virtual ports. Compression is not ed of fast-HTTP virtual ports.

ed 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-31 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 U 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.

844 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 34 HTTP Template Parameters (Continued) Parameter Compression

Description and Syntax

(cont.)

ed 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 String of 1-256 characters 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] Config > Service > Template > Application > HTTP

Header erase

Note: These options are not ed 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.

String of 1-256 characters Default: Not set

[no] request-header-erase field [no] response-header-erase field Config > Service > Template > Application > HTTP Note: These options are not ed 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. Note: You can use URL switching or Host switching in an HTTP template, but not both.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

845 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 34 HTTP Template Parameters (Continued) Parameter Host switching

Description and Syntax 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:

ed 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 Config > Service > Template > Application > HTTP

Client IP insert

Note: You can use URL switching or Host switching in an HTTP template, but not both. However, if you need to use both types of switching, you can do so with an aFleX script. Inserts the client’s source IP address into HTTP headers. [no] insert-client-ip [http-fieldname] [replace] Config > Service > Template > Application > HTTP

Redirect rewrite

Modifies redirects sent by servers by rewriting the matching URL string to the specified value before sending the redirects to clients.

String of 1-256 characters 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 Config > Service > Template > Application > HTTP

846 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 34 HTTP Template Parameters (Continued) Parameter Redirect rewrite secure

Strict transaction switching

Description and Syntax Changes HTTP redirects sent by servers into HTTPS redirects before sending the redirects to clients. [no] redirect-rewrite secure {port t-portnum} Config > Service > Template > Application > HTTP 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.

ed Values Strings of 1-256 characters Default: Not set

Enabled or disabled Default: Disabled

[no] strict-transaction-switch URL switching

Config > Service > Template > Application > HTTP Selects a service group based on the URL string requested by the client. The selection overrides the service group configured on the virtual port.

Strings of 1-256 characters Default: Not set

[no] url-switching {starts-with | contains | ends-with} url-string service-group service-group-name If the URL-string does not match, the service group configured on the virtual port is used. Selection is performed using the following match 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. 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 URL matches on more than one match filter of the same type, the most specific match is used. Config > Service > Template > Application > HTTP Note: You can use URL switching or Host switching in an HTTP template, but not both. However, if you need to use both types of switching, you can do so with an aFleX script.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

847 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 34 HTTP Template Parameters (Continued) Parameter URL hash persistence (also called URL hash switching)

Description and Syntax 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.

ed 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 136.) [no] url-hash-persist {first | last} bytes [use-server-status} Session termination for non-compliant HTTP 1.1 clients

Config > Service > Template > Application > HTTP 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 Note: The current release does not configuration of this option using the GUI.

848 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters

Policy Template Parameters Table 35 lists the parameters you can configure in Policy-Based SLB (PBSLB) templates. TABLE 35 Policy Template Parameters Parameter Template name

Black/white list name

Action for overlimit traffic

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template policy templatename

Default: None.

Config > Service > Template > Application > Policy Binds a black/white list to the virtual ports that use this template. [no] bw-list name file-name Config > Service > Template > Application > 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 terval 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

Config > Service > Template > Application > 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 Note: The current release does not configuration of this option using the GUI.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

849 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 35 Policy Template Parameters (Continued) Parameter Action

Description and Syntax Specifies the action to take for clients in the black/ white list.

ed Values The following settings are configurable:

[no] bw-list id id {service service-group-name | drop | reset} [logging [minutes] [fail]]

• List ID – ID of the black/white list.

Config > Service > Template > Application > 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 port’s connection limit. (The connection limit is set in the black/white list.) • Reset – Resets new connections until the number of concurrent connections on the virtual port falls below the connection limit. • 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 client’s destination IP address. [no] overlap Config > Service > Template > Application > Policy

850 of 960

• Logging – Disabled. If you enable logging, the default for minutes is 3. Enabled or Disabled Default: Disabled. Matching is based on the client’s source IP address.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 35 Policy Template Parameters (Continued) Parameter Matching based on destination IP address

Class list IP address matching

Description and Syntax Matches black/white list entries based on the client’s destination IP address. [no] bw-list use-destination-ip Config > Service > Template > Application > 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.

ed Values Enabled or Disabled Default: Disabled. Matching is based on the client’s source IP address.

Client IP address, destination IP address, or request header. Default: Matching is based on the client’s 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]} Config > Service > Template > Application > Policy Applies an IP class list to the template. [no] class-list name name Config > Service > Template > Application > Policy

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

Name of a configured class list Default: not set

851 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 35 Policy Template Parameters (Continued) Parameter Class list IP limiting rule

Description and Syntax 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.

ed 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 T, the AX device sends a T 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 Config > Service > Template > Application > Policy

852 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 35 Policy Template Parameters (Continued) Parameter Geo-location statistics sharing

Description and Syntax 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:

ed Values Disabled

• Permit • Deny • Connection number • Connection limit [no] geo-location share Note: The current release does not configuration of this option using the GUI. Note: It is recommended to enable or disable this option before enabling GSLB. Changing the state of this option while GSLB is running can cause the related statistics counters to be incorrect.

Server SSL Template Parameters Table 40 lists the parameters you can configure in Server SSL templates. TABLE 36 Server SSL Template Parameters Parameter Template name

Certificate Authority (CA) certificate name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template server-ssl template-name

Default: “default”. The default template has the default values listed 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

Config > Service > Template > SSL > Server SSL Note: To use the certificate, you must import it onto the AX device. (See “Importing SSL Certificates” on page 467.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

853 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 36 Server SSL Template Parameters (Continued) Parameter Ciphers

Description and Syntax Cipher suite to for decrypting certificates from servers.

ed Values One or more of the following:

[no] cipher

• SSL3_RSA_DES_40_CBC_SHA

Config > Service > Template > SSL > Server SSL

• SSL3_RSA_DES_64_CBC_SHA

• 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_AES_256_SHA • TLS1_RSA_EXPORT1024_RC4_56 _MD5 • TLS1_RSA_EXPORT1024_RC4_56 _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 T/TLS) Table 37 lists the parameters you can configure in SIP templates for SIP over T/TLS. TABLE 37 SIP Template Parameters for SIP over T/TLS Parameter Template name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template sip template-name

Default: None.

Config > Service > Template > Application > SIP

854 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 37 SIP Template Parameters for SIP over T/TLS (Continued) Parameter Client Keep-Alive

Description and Syntax 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.

ed Values Enabled or disabled Default: Disabled

[no] client-keep-alive Server Keep-Alive

Config > Service > Template > Application > SIP 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 server’s 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 836.) Note: This option is applicable only if the configuration includes a connection-reuse template. [no] server-keep-alive seconds Insert Client IP

Config > Service > Template > Application > SIP 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

Config > Service > Template > Application > SIP 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} Config > Service > Template > Application > SIP

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

855 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 37 SIP Template Parameters for SIP over T/TLS (Continued) Parameter Select Server Fail Action

Description and Syntax Specifies the AX response when selection of a SIP server fails. You can specify one of the following:

ed 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

Config > Service > Template > Application > SIP 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

Config > Service > Template > Application > SIP Number of minutes a call can remain idle before the AX Series terminates it.

1-250 minutes Default: 30 minutes

[no] timeout minutes Config > Service > Template > Application > SIP

856 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters

SIP Template Parameters (SIP over UDP) Table 38 lists the parameters you can configure in SIP templates for SIP over UDP. TABLE 38 SIP Template Parameters for SIP over UDP Parameter Template name

Registrar service group

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template sip template-name

Default: None.

Config > Service > Template > Application > SIP Name of a configured service group of SIP Registrar servers.

Name of a configured service group

[no] registrar service-group group-name Header erase

Config > Service > Template > Application > SIP Erases the specified SIP header from the SIP request before sending it to a SIP Registrar.

String of 1-256 characters Default: None

[no] header-erase string Header insert

Config > Service > Template > Application > SIP Inserts the specified SIP header into the SIP request before sending it to a SIP Registrar.

String of 1-256 characters Default: None

[no] header-insert string Header replace

Config > Service > Template > Application > SIP Replaces the specified SIP header in the SIP request before sending it to a SIP Registrar.

String of 1-256 characters Default: None

[no] header-replace string new-string Config > Service > Template > Application > SIP 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 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 server’s IP address or subnet as the destination address. [no] -real-server-ip-for-acl acl-id Config > Service > Template > Application > SIP

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

857 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 38 SIP Template Parameters for SIP over UDP (Continued) Parameter Call timeout

Description and Syntax Number of minutes a call can remain idle before the AX Series terminates it.

ed Values 1-250 minutes Default: 30 minutes

[no] timeout minutes Config > Service > Template > Application > SIP

SMTP Template Parameters Table 39 lists the parameters you can configure in SMTP templates. TABLE 39 SMTP Template Parameters Parameter Template name

Domain name switching

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template smtp template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > Application > 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. Selection is performed using the following match 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.)

858 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 39 SMTP Template Parameters (Continued) Parameter Domain name switching (cont.)

Description and Syntax 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.

ed 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

Config > Service > Template > Application > SMTP Disables 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

Config > Service > Template > Application > 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

Config > Service > Template > Application > 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 Config > Service > Template > Application > SMTP

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

859 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 39 SMTP Template Parameters (Continued) Parameter STARTTLS requirement

Description and Syntax Specifies whether use of STARTTLS by clients is required. starttls {disable | optional | enforced} Config > Service > Template > Application > SMTP

ed Values One of the following: • Disabled – Clients cannot use STARTTLS. Use this option if you need to disable STARTTLS 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 40 lists the parameters you can configure in source-IP persistence templates. TABLE 40 Source-IP Persistence Template Parameters Parameter Template name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template persist source-ip template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > Persistent > Source IP Persistence

860 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 40 Source-IP Persistence Template Parameters (Continued) Parameter Match type

Description and Syntax Granularity of persistence:

ed Values One of the following:

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

• Port (selectable in the GUI but not 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 option scans all bound to the template. This option is useful in configurations where match-type “server” is used, and where some have different priorities or are disabled. (See “Scan-All- Option in Persistence Templates” on page 911.) 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} Config > Service > Template > Persistent > Source IP Persistence

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

861 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 40 Source-IP Persistence Template Parameters (Continued) Parameter Netmask

Description and Syntax Granularity of IP address hashing for server port selection.

ed 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

Config > Service > Template > Persistent > Source 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. [no] timeout timeout-minutes

Include source port

Ignore connection limits

Config > Service > Template > Persistent > Source IP Persistence Includes the source port in persistent sessions. [no] incl-sport Note: The current release does not configuration of this option using the GUI. 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 client source IP address.

Enabled or Disabled Default: Disabled.

Enabled or Disabled Default: Disabled. By default, the connection limit set on real servers and real ports is used.

[no] dont-honor-conn-rules Config > Service > Template > Persistent > Source IP Persistence

862 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters

SSL Session-ID Persistence Template Parameters Table 41 lists the parameters you can configure in SSL session-ID persistence templates. TABLE 41 SSL Session-ID Persistence Template Parameters Parameter Template name

Timeout

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template persist ssl-sid template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > Persistent > 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

[no] timeout timeout-minutes

Ignore connection limits

Config > Service > Template > Persistent > SSL Session ID 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 SSL session ID.

Enabled or Disabled Default: Disabled. By default, the connection limit set on real servers and real ports is used.

[no] dont-honor-conn-rules Config > Service > Template > Persistent > SSL Session ID Persistence

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

863 of 960

AX Series - Configuration Guide Service Template Parameters

Streaming-Media Template Parameters Table 42 lists the parameters you can configure in streaming-media templates. TABLE 42 Streaming-media Template Parameters Parameter Template name

URI switching

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template streaming-media template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > Application > RTSP Service group to which to send requests for a specific URI. [no] uri-switching stream uri-string service-group group-name

Name of a configured service group Default: Requests are sent to the service group that is bound to the virtual port.

Config > Service > Template > Application > RTSP Note: This option is ed only for Windows Media Server.

T Template Parameters Table 43 lists the parameters you can configure in T templates. TABLE 43 T Template Parameters Parameter Template name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template t template-name

Default: “default”. The default template has the default values listed below. 60-120000 seconds (about 33 hours) Default: 120 seconds

Config > Service > Template > L4 > T 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. [no] idle-timeout seconds Config > Service > Template > L4 > T

864 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 43 T Template Parameters (Continued) Parameter Aging of halfclosed sessions

Server reset

Description and Syntax Enables aging of half-closed T sessions. A halfclosed T 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 > T Sends a T RST to the real server after a session times out.

ed 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

Config > Service > Template > L4 > T Sends a T 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 Config > Service > Template > L4 > T Sets the initial T window size in SYN ACK packets to clients. The T 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 T window size set by the client or server.

[no] initial-window-size bytes Config > Service > Template > L4 > T

T-Proxy Template Parameters Table 43 lists the parameters you can configure in T-proxy templates. TABLE 44 T-Proxy Template Parameters Parameter Template name

FIN timeout

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template t-proxy template-name

Default: “default”. The default template has the default values listed below.

Config > Service > Template > T 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 Config > Service > Template > T Proxy

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

1-60 seconds Default: 5 seconds

865 of 960

AX Series - Configuration Guide Service Template Parameters TABLE 44 T-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

866 of 960

Description and Syntax Enables aging of half-closed T sessions. A halfclosed T 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 > T Proxy Number of seconds that a connection can be idle before the AX Series terminates the connection. 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. [no] idle-timeout seconds Config > Service > Template > T Proxy Enables Nagle congestion compression (described in RFC 896). [no] nagle Config > Service > Template > T Proxy Maximum number of bytes addressed to the port that the AX Series will buffer. [no] receive-buffer number Config > Service > Template > T Proxy 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 Config > Service > Template > T Proxy Number of times the AX Series can retransmit a SYN for which the AX Series does not receive an ACK. [no] syn-retries number Config > Service > Template > T Proxy 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 Config > Service > Template > T Proxy Number of bytes sent by the port that the AX Series will buffer. [no] transmit-buffer number Config > Service > Template > T Proxy

ed Values 60-15000 seconds Default: Not set. The AX device keeps half-closed sessions open indefinitely.

60-120000 seconds (about 33 hours) Default: 600 seconds

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 Default: 16384 bytes

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Template Parameters TABLE 44 T-Proxy Template Parameters (Continued) Parameter Initial window size

Description and Syntax Sets the initial T window size in SYN ACK packets to clients. The T 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.

ed Values 1-65535 bytes Default: The AX device uses the T window size set by the client or server.

[no] initial-window-size bytes Config > Service > Template > T Proxy

UDP Template Parameters Table 45 lists the parameters you can configure in UDP templates. TABLE 45 UDP Template Parameters Parameter Template name

Description and Syntax Name of the template.

ed Values String of 1-31 characters

[no] slb template udp template-name

Default: “default”. The default template has the default values listed below. One of the following: • Immediate

Config > Service > Template > L4 > UDP Aging

Specifies how quickly sessions are terminated when the request is received. aging {immediate | short [seconds]} Config > Service > Template > L4 > UDP • 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

867 of 960

AX Series - Configuration Guide Global SLB Parameters TABLE 45 UDP Template Parameters (Continued) Parameter Idle timeout

Server reselection

Description and Syntax Number of seconds a connection can remain idle before the AX Series 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. [no] idle-timeout number Config > Service > Template > L4 > UDP 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 Config > Service > Template > L4 > UDP

ed Values 60-120000 seconds (about 33 hours) Default: 120 seconds

Enabled or disabled Default: Disabled

Global SLB Parameters Table 47 lists the SLB parameters you can configure globally. TABLE 46 Global SLB Parameters Parameter Server state

Description and Syntax Globally disables or re-enables a real or virtual server.

ed 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] Config > Service > SLB > Server Config > Service > SLB > Virtual Server

868 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Global SLB Parameters TABLE 46 Global SLB Parameters (Continued) Parameter DSR health check

Description and Syntax Enables Layer 4-7 health checking in Direct Server Return (DSR) configurations.

ed 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 394. 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] Config > Service > SLB > Global > Settings Maximum session life following completion of a T flow.

1-65535 seconds (about 18 hours) Default: Not set. When you delete a real or virtual service port, the AX device places all the port’s 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

Config > Service > SLB > Global > Settings Enables system-wide protection against T SYN flood attacks. SYN cookies enable the AX device to continue to serve legitimate clients during a T SYN flood attack, without allowing illegitimate traffic to consume system resources. • On-Threshold – Specifies the maximum number of concurrent half-open T connections allowed on the AX device, before SYN cookies are enabled. If the number of halfopen T 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 T connections for which to keep SYN cookies enabled. If the number of half-open T 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 T connections present on the AX device.

[no] syn-cookie [on-threshold num off-threshold num] Config > Service > SLB > Global > Settings Note: This option is ed only on models AX 2200, AX 3100, AX 3200, AX 5100, and AX 5200. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

869 of 960

AX Series - Configuration Guide Global SLB Parameters TABLE 46 Global SLB Parameters (Continued) Parameter Use of IP pool default gateways by real servers

Source-IP based connection rate limiting

Description and Syntax 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 server’s IP address, and a default gateway is defined for the pool, the AX device forwards the server traffic through the pool’s default gateway. [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 configuration of this feature using the GUI. For more information about this feature, see “Source-IP Based Connection Rate Limiting” on page 736.

ed 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.) 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: (cont.)

870 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Global SLB Parameters TABLE 46 Global SLB Parameters (Continued) Parameter Source-IP based connection rate limiting

Description and Syntax

(cont.)

DNS caching

ed Values • 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.

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

Source NAT on VIP

[no] dns-cache-age seconds Config > Service > SLB > Global > Settings Globally enables IP NAT for VIPs. Source IP NAT can be configured on a virtual port in the following ways:

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 source IP NAT on FTP or RTSP virtual ports. [no] slb snat-on-vip Config > Service > SLB > Global > Settings

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

871 of 960

AX Series - Configuration Guide Global SLB Parameters TABLE 46 Global SLB Parameters (Continued) Parameter Layer 7 request ing

Description and Syntax Globally enables Layer 7 request ing.

ed Values Enabled or disabled

Note: Layer 7 request ing is automatically enabled for service groups that use the least-request load-balancing method.

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

Config > Service > SLB > Global > Settings 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.

Idle timeout for through T sessions

Trunk load balancing

[no] slb hw-compression Config > Service > SLB > Global > Settings Sets the idle timeout for -through T sessions. A -through T 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 T template. The idle timeout in the T template is used. Only the idle timeout setting in the specified T template is applicable to -through T sessions. None of the other options in T templates affect -through T sessions. [no] slb transparent-t-template template-name Note: This parameter is not configurable using the GUI. Disables or re-enables trunk load balancing or Layer2/Layer 3 traffic. [no] slb l2l3-trunk-lb-disable

Name of a configured T template. To use the default T template, specify the name “default”. Default: The default idle timeout for -through T sessions is 30 minutes. The default idle timeout in T templates is 120 seconds.

Enabled or disabled Default: Enabled.

Note: This parameter is not configurable using the GUI.

872 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Global SLB Parameters TABLE 46 Global SLB Parameters (Continued) Parameter Fast-path processing

Description and Syntax Enables fast-path processing, wherein the AX device does not perform a deep inspection of every field within a packet.

ed Values Enabled (slb fast-path-disable) or disabled (no slb fastpath-disable)

[no] slb fast-path-disable Config > Service > SLB > Global > Settings T Maximum Segment Size (MSS)

Statistics collection

Changes the minimum T MSS the AX device allows for client traffic. [no] slb mss-table num Note: This parameter is not configurable using the GUI. Globally disables or re-enables collection of statistical data for system resources and for load-balancing resources. stats-data-disable stats-data-enable Note: Statistical data collection for load-balancing resources also must be enabled on the individual resources.

SLB application buffer threshold

Default: Enabled. Deep inspection of every packet field is enabled. 128-750 Default: 538

Config > Service > SLB > Global > Settings Fine-tunes thresholds for SLB buffer queues. • Hardware buffer – IO buffer threshold. For each U, 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 U’s IO buffer.

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

[no] slb buff-thresh hw-buff num relieve-thresh num sys-buff-low num sys-buff-high num Config > Service > SLB > Global > Settings Changes the default compression block size used for SLB.

6000-32000 bytes Default: 16000 bytes

[no] compress-block-size bytes Config > Service > SLB > Global > Rate-Limit Log P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

873 of 960

AX Series - Configuration Guide Real Server Parameters TABLE 46 Global SLB Parameters (Continued) Parameter DDoS Protection Log rate limiting

Description and Syntax See “DDoS Protection” on page 725. 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.

ed Values Default: Not set • Max-local-rate – 1-100 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

• Max-remote-rate – 1-100000 messages per second

Defaults:

• Max-remote-rate – 15000 messages per second • Exclude-destination – Logging to both destinations is enabled.

Real Server Parameters Table 47 lists the parameters you can configure on real servers. TABLE 47 Real Server Parameters

Parameter Server name and IP address

Description and Syntax Name and IP address of the real server. [no] slb server server-name ipaddr

IPv4 or IPv6 address

Config > Service > SLB > Server

Server state

874 of 960

Configurable in Real Server Template? N/A

ed Values String of 1-31 characters

Note: The name does not need to match the hostname configured on the server. State of the real server.

Default: None configured

[no] {disable | enable}

Enabled or disabled

Config > Service > SLB > Server

Default: Enabled

P e r f o r m a n c e

No

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Real Server Parameters TABLE 47 Real Server Parameters (Continued)

Parameter Real server template

Description and Syntax Configuration template of real server parameters. [no] template server template-name Config > Service > SLB > Server

Health check

Enables or disables Layer 3 health monitoring and species the monitor to use. [no] health-check [monitor-name] Config > Service > SLB > Server

Connection limit

Number of concurrent connections allowed on a real server. [no] conn-limit max-connections Config > Service > SLB > Server

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 Config > Service > SLB > Server

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

ed Values Name of a configured real server template Default: “Default” real server template Enabled or disabled Name of a configured health monitor Default: Enabled; ping (ICMP) 1-1000000 (one million) if configured on the real server; 1-1048575 if configured in the server template Default: 1000000 if configured on the real server; 1048575 if configured in the server template 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 below the connection limit.

Configurable in Real Server Template? N/A

Yes

Yes

Yes, but as additional parameter with conn-limit command (CLI) or additional field under Connection Limit Status (GUI)

875 of 960

AX Series - Configuration Guide Real Server Parameters TABLE 47 Real Server Parameters (Continued)

Parameter Service port

Description and Syntax T or UDP port number. [no] port port-num {t | udp} Config > Service > SLB > Server - Port (For parameters you can set on the service port, see “Real Service Port Parameters” on page 877.)

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.

ed Values Transport protocol: T or UDP

Configurable in Real Server Template? N/A

Port number: 0-65534 Default: None configured Enabled or disabled

Yes

Default: Disabled

[no] slow-start Config > Service > SLB > Server - Port

Weight

Note: It is recommended to configure this feature in the real server template or real port template instead. See “Behavior When Slow Start Is Also Configured on the Real Server Itself” on page 376. istrative weight of the server, used for weighted load balancing (weighted-least-connection or weighted-round-robin).

1-100

No

Default: 1

[no] weight num External IP address

Config > Service > SLB > Server 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 Spoofing cache

Statistics collection

Config > Service > SLB > Server Enables for a spoofing cache server. A spoofing cache server uses the client’s IP address instead of its own as the source address when obtaining content requested by the client. This command applies to the Transparent Cache Switching (TCS) feature. (See “Transparent Cache Switching” on page 301.) [no] spoofing-cache

Enabled or disabled Default: Disabled

No

Config > Service > SLB > Server Enables or disables collection of statistical data for the server.

Enabled or disabled

No

stats-data-enable

Default: enabled

stats-data-disable Config > Service > SLB > Server

876 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Real Service Port Parameters TABLE 47 Real Server Parameters (Continued)

Parameter GSLB IPv6 mapping

Description and Syntax Assigns an IPv6 address to the real server for GSLB.

ed Values Valid IPv6 address

Configurable in Real Server Template? No

Default: None

[no] ipv6 ipv6-addr Note: The current release does not configuration of this option using the GUI.

Real Service Port Parameters Table 48 lists the parameters you can configure on individual service ports on real servers. TABLE 48 Real Service Port Parameters

Parameter Service port number and transport protocol

Description and Syntax T or UDP port number. [no] port port-num {t | udp} Config > Service > SLB > Server - Port 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. [no] {disable | enable} Config > Service > SLB > Server - Port Configuration template of real port parameters. [no] template port template-name Config > Service > SLB > Server - Port

ed Values T 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 269.) Enabled or disabled

Configurable in Real Port Template? N/A

No

Default: Enabled Name of a configured real port template

N/A

Default: “Default” real port template

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

877 of 960

AX Series - Configuration Guide Real Service Port Parameters TABLE 48 Real Service Port Parameters (Continued)

Parameter Health check

Description and Syntax Enables or disables health monitoring and species the monitor to use. To base the port’s 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] Config > Service > SLB > Server - Port Note: In the current release, the follow-port option is not ed in the GUI.

Connection limit

Number of concurrent connections allowed on the service port. [no] conn-limit max-connections Config > Service > SLB > Server - 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 Config > Service > SLB > Server - Port

Weight

istrative weight of the service port, used for weighted load balancing (service-weighted-leastconnection).

Configurable in Real Port Template? Yes (The follow-port option can not be configured using a template.)

ed Values Enabled or disabled Name of a configured health monitor Default: The AX performs the default T or UDP check every 5 seconds. (See “Default Health Checks” on page 381.) 1-1000000 (one million) if configured on the server port; 1-1048575 if configured in the server port template

Yes

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 below the connection limit. 1-100

Yes, but as additional parameter with conn-limit command (CLI) or additional field under Connection Limit Status (GUI)

Yes

Default: 1

[no] weight num Config > Service > SLB > Server - Port

878 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Group Parameters TABLE 48 Real Service Port Parameters (Continued)

Parameter No-SSL

Description and Syntax 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.

ed Values Enabled or disabled

Configurable in Real Port Template? 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 Statistics collection

Config > Service > SLB > Server - Port Enables or disables collection of statistical data for the port.

Enabled or disabled

stats-data-enable

Default: enabled

No

stats-data-disable Config > Service > SLB > Server - Port

Service Group Parameters Table 48 lists the parameters you can configure in service groups. TABLE 49 Service Group Parameters Parameter Service group name and type

Description and Syntax Name of a service group and the transport protocol used by service ports in the group.

ed Values String of 1-31 characters T or UDP

[no] slb service-group group-name {t | udp}

Default: None configured

Config > Service > SLB > Service Group

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

879 of 960

AX Series - Configuration Guide Service Group Parameters TABLE 49 Service Group Parameters (Continued) Parameter Member

Description and Syntax Real servers and service ports managed by the group. [no] member server-name:portnum [disable | enable] [priority num] [template template-name] [stats-data-enable] 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. Config > Service > SLB > Service Group

880 of 960

ed Values 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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Group Parameters TABLE 49 Service Group Parameters (Continued) Parameter Load balancing method

Description and Syntax Algorithm used to select a real server and service port to fulfil a client’s request. [no] method lb-method Config > Service > SLB > Service Group 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.

ed Values One of the following: • 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 server’s istratively 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’ istratively assigned weights. If the weight value is the same on each server, this load-balancing method simply selects the servers in rotation. (cont.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

881 of 960

AX Series - Configuration Guide Service Group Parameters TABLE 49 Service Group Parameters (Continued) Parameter Load balancing method (cont.)

Description and Syntax

ed 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 291.) • Stateless-src-ip-hash – Balances server load based on a hash value calculated using the source IP address and source T or UDP port. • Stateless-src-dst-ip-hash – Balances server load based on a hash value calculated using both the source and destination IP addresses and T or UDP ports. • Stateless-dst-ip-hash – Balances server load based on a hash value calculated using the destination IP address and destination T 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)

882 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Service Group Parameters TABLE 49 Service Group Parameters (Continued) Parameter Health monitor

Minimum active

Reset after server selection failure

Statistics collection

Description and Syntax Assigns a health monitor to all 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 their health checks, and clients of those sites will be sent to the server. [no] health-check monitor-name Config > Service > SLB > Service Group 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] Config > Service > SLB > Service Group Sends a T reset (RST) to clients if server selection fails. [no] reset-on-server-selectionfail Config > Service > SLB > Service Group

ed 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 905. Enables or disables collection of statistical data for the service group.

Enabled or disabled

stats-data-enable

Default: enabled

stats-data-disable Config > Service > SLB > Service Group

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

883 of 960

AX Series - Configuration Guide Virtual Server Parameters

Virtual Server Parameters Table 50 lists the parameters you can configure on virtual servers. TABLE 50 Virtual Server Parameters

Parameter Virtual server name and virtual IP address

Description and Syntax 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

ed Values String of 1-31 characters IPv4 or IPv6 address Default: None configured

[no] slb virtual-server name ipaddr or [no] slb virtual-server server-name starting-ip {subnet-mask | /mask-length} Virtual server state

Config > Service > SLB > Virtual Server 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

884 of 960

Name of a configured virtual server template

N/A

Default: “Default” virtual server template

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Virtual Server Parameters TABLE 50 Virtual Server Parameters (Continued)

Parameter Virtual service port number and service type

[no] port port-num service-type

ed 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

• t

• ssl-proxy – SSL proxy service

• udp

• t – Transmission Control Protocol

• others

• udp – Datagram Protocol

Default: None configured

Description and Syntax 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 269.) (For parameters you can set on the service port, see “Virtual Service Port Parameters” on page 887.)

ARP disable

Note: Fast-HTTP is optimized for very high performance information transfer in comparison to regular HTTP. Due to this optimization, fastHTTP does not all the comprehensive capabilities of HTTP such as header insertion and manipulation. It is recommended not to use fast-HTTP for applications that require compete data transfer integrity. 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

[no] ha-group group-id

Default: Not set

[no] arp-disable Config > Service > SLB > Virtual Server HA group ID

Enabled or disabled

No

No

Config > Service > SLB > Virtual Server

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

885 of 960

AX Series - Configuration Guide Virtual Server Parameters TABLE 50 Virtual Server Parameters (Continued)

Parameter VIP-based High Availability (HA) failover

Description and Syntax Enables dynamic failover based on server weight. The configured amount is subtracted from the HA group’s priority value for each real server that goes down.

OSPF redistribution

Config > Service > SLB > Virtual Server Explicitly include or exclude the VIP in OSPF redistribution.

ed Values 1-255

Configurable in Virtual Server Template? No

Default: Not set

[no] ha-dynamic server-weight Set or not set

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

Note: The current release does not configuration of this option using the GUI. Enables or disables collection of statistical data for the virtual server.

Enabled or disabled

stats-data-enable

Default: enabled

No

stats-data-disable Config > Service > SLB > Virtual Server

886 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Virtual Service Port Parameters

Virtual Service Port Parameters Table 51 lists the parameters you can configure on individual service ports on virtual servers. TABLE 51 Virtual Service Port Parameters

Parameter Virtual service port number and service type

Description and Syntax Service port number and service type. [no] port port-num service-type

ed 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 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-t – SIP over T • sips – Secure SIP over TLS • smtp – Simple Mail Transfer Protocol

Configurable in Virtual Port Template? N/A

• fast-http • http • https • mms • rtsp • sip • sip-tls • sips • smtp • ssl-proxy • t • udp Default: None configured

• ssl-proxy – SSL proxy service • t – Transmission Control Protocol • udp – Datagram Protocol Note: Fast-HTTP is optimized for very high performance information transfer in comparison to regular HTTP. Due to this optimization, fastHTTP does not all the comprehensive capabilities of HTTP such as header insertion and manipulation. It is recommended not to use fast-HTTP for applications that require compete data transfer integrity. Note: The AX device allocates processing resources to HTTPS virtual ports when you bind them to an SSL template. This results in increased U utilization, regardless of whether traffic is active on the virtual port.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

887 of 960

AX Series - Configuration Guide Virtual Service Port Parameters TABLE 51 Virtual Service Port Parameters (Continued)

Parameter Virtual service port state Virtual port template

Description and Syntax State of the virtual service port. [no] {disable | enable} Config > Service > SLB > Virtual Server - Virtual Server Port Configuration template of virtual port parameters. [no] template virtual-port template-name Config > Service > SLB > Virtual Server - Virtual Server Port

Service group

Configurable in Virtual Port Template? No

ed Values Enabled or disabled

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.

Default: Enabled Name of a configured virtual port template

N/A

Default: “Default” virtual port template Name of a configured service group

No

Default: Not set

[no] service-group group-name

Template

Config > Service > SLB > Virtual Server - Virtual Server Port Connection or application template to use for service port parameters. [no] template template-type template-name Config > Service > SLB > Virtual Server - Virtual Server Port

Template type: One of the types described in “Service Template Parameters” on page 829.

N/A

Template name: Name of a configured template. 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 829.)

888 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Virtual Service Port Parameters TABLE 51 Virtual Service Port Parameters (Continued)

Parameter Access Control List (ACL)

Description and Syntax 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.

ed Values Valid standard or extended ACL ID Default: None

Configurable in Virtual Port Template? 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]

aFleX policy

Config > Service > SLB > Virtual Server - Virtual Server Port aFleX policy to use for custom SLB processing. [no] aflex aflex-name

Connection limit

Config > Service > SLB > Virtual Server - Virtual Server Port Number of concurrent connections allowed on the virtual service port. By default, after the connection limit is exceeded, new connections are silently dropped and no reset is sent to the client. You can use the reset option to send a connection reset to the client instead. [no] conn-limit number [reset] [no-logging]

Session synchronization (connection mirroring)

Config > Service > SLB > Virtual Server - Virtual 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.

Name of a configured aFleX policy. Default: None

No

0-8000000 (8 million) 0 means no limit. Default: Not set. When the feature is enabled, the reset option is disabled and logging is enabled.

Yes, but the range is 1-1048575

Enabled or disabled

No

Default: Disabled

[no] ha-conn-mirror Config > Service > SLB > Virtual Server - Virtual Server Port 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

889 of 960

AX Series - Configuration Guide Virtual Service Port Parameters TABLE 51 Virtual Service Port Parameters (Continued)

Parameter Direct Server Return (DSR)

Description and Syntax Disables destination NAT, so that server responses go directly to clients. [no] no-dest-nat

Policy-based SLB (PBSLB)

Config > Service > SLB > Virtual Server - Virtual Server Port 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}

Configurable in Virtual Port Template? No

ed Values Enabled or disabled Disabled: Destination NAT is enabled. Name of a configured black/white list. The list must be imported onto the AX device.

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 761.) Name of a pool of IP addresses to use for Network Address Translation (NAT). [no] source-nat pool pool-name Config > Service > SLB > Virtual Server - Virtual 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.

890 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Virtual Service Port Parameters TABLE 51 Virtual Service Port Parameters (Continued)

Parameter VIP Source NAT

Description and Syntax Enables IP NAT for the VIP. Source IP NAT can be configured on a virtual port in the following ways:

ed 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 Config > Service > SLB > Virtual Server - Virtual Server Port

Softwarebased protection against T SYN flood attacks

Use receive hop for responses

Note: The current release does not source IP NAT on FTP or RTSP virtual ports. Protects against T SYN floods. [no] syn-cookie [sack] Config > Service > SLB > Virtual Server - Virtual Server Port Note: If hardware-based SYN cookies are ed on the AX model you are configuring, use that version of the feature instead. (See “SYN Cookies” on page 728.) 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 Config > Service > SLB > Virtual Server - Virtual Server Port

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

891 of 960

AX Series - Configuration Guide Virtual Service Port Parameters TABLE 51 Virtual Service Port Parameters (Continued)

Parameter Reset after server selection failure

Default forwarding after server selection failure

Default selection if preferred server selection fails

Description and Syntax Sends a T reset (RST) to clients if server selection fails. [no] reset-on-server-selectionfail Config > Service > SLB > Virtual Server - Virtual Server Port Note: For more information about this option, see “Sending a Reset After Server Selection Failure” on page 905. Forwards client traffic at Layer 3, if SLB server selection fails. Note: This option applies only to wildcard VIPs (VIP address 0.0.0.0). [no] use-default-if-no-server Config > Service > SLB > Virtual Server - Virtual 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.

ed Values Enabled or disabled

Configurable in Virtual Port Template? No

Default: disabled

Enabled or disabled

No

Default: disabled. If SLB server selection fails, the traffic is dropped. 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.)

892 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Virtual Service Port Parameters TABLE 51 Virtual Service Port Parameters (Continued)

Parameter Default selection if preferred server selection fails (cont.)

Description and Syntax 3. Default service group. If none of the items above results in selection of a server, the default service group is used.

ed 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 client’s IP address in a black/white list, the service group specified by the list is used for the client request. [no] def-selection-if-pref-failed

GSLB enable (DNS proxy ports only)

Config > Service > SLB > Virtual Server - Virtual 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 Config > Service > SLB > Virtual Server - Virtual 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. Enables or disables collection of statistical data for the virtual port.

Enabled or disabled

stats-data-enable

Default: enabled

No

stats-data-disable Config > Service > SLB > Virtual Server - Virtual Server Port

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

893 of 960

AX Series - Configuration Guide Virtual Service Port Parameters

894 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

Dynamic Real Server Creation Using DNS You can use DNS to simplify real server creation, by specifying a DNS hostname instead of an IP address. In this case, the AX device periodically sends a DNS query for the hostname’s IP address, and dynamically creates a real server with the IP address returned by DNS. The AX device also creates a service-group member for the server, in each service group that contains the server. To create and maintain dynamic real servers, the AX device sends a DNS query for each hostname real server, at a configurable interval. • If the DNS server replies with an Address (A) record for a hostname real

server, the AX device creates the server or, if the server is already created, the AX device refreshes its TTL. The AX device also creates service-group 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 s 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 server’s initial TTL when the server is created. The initial TTL value is the greater of the following: • TTL value in the DNS reply • DNS query interval multiplied by the min-ttl-ratio (described in “Tem-

plate Options for Dynamically Created Real Servers” on page 896) The server’s TTL is decremented by 60 every minute. The TTL is refreshed each time the DNS server replies with the address.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

895 of 732

AX Series - Configuration Guide 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.

896 of 732

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 : • dynamic-member-priority and decrement-delta – Sets the initial priority

of dynamic service-group , and specifies how much to decrement from the priority after each DNS query. Within a service group, the priorities of the determine which of those can be used to service client requests. Normally, only the highest priority can be used. Decrementing the priorities of dynamic provides a way to ensure that the service group uses newer dynamically created 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:

P e r f o r m a n c e

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 11/3/2010

897 of 732

AX Series - Configuration Guide Configuring Dynamic Real Server Creation

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 ed in the GUI.

USING THE GUI 1. Select Config > Service > SLB. 2. On the menu bar, select Server. 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. 6. When finished, click OK.

USING THE CLI To configure a dynamic real server, use the following command at the global configuration level of the CLI: 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.

898 of 732

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Dynamic Real Server Creation 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 , 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-rport)#exit 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 AX(config-rserver)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

899 of 732

AX Series - Configuration Guide Configuring Dynamic Real Server Creation 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 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure a static real server: AX(config)#slb server s-test2 10.4.2.1 AX(config-real server)#port 80 t AX(config-real server-node port)#exit AX(config-real server)#exit

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 t AX(config-slb svc group)#member s-test1:80 template temp-port AX(config-slb svc group)#member s-test2:80 AX(config-slb svc group)#exit

The following commands adds the DNS server to use for resolving the real server hostname into server IP addresses: AX(config)#ip dns primary 10.10.10.10

The following command displays detailed information for the hostname server. The configuration details are shown first, followed by details for the dynamically created servers. AX#show slb server s-test1 detail Server name:

s-test1

Hostname:

s1.test.com

Last DNS reply:

Tue Nov 17 03:41:59 2009

State:

Up

Server template:

temp-server

DNS query interval:

5

Minimum TTL ratio:

3

Maximum dynamic server:

16

Health check:

none

Current connection:

0

Current request:

0

Total connection:

1919

900 of 732

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Configuring Dynamic Real Server Creation 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:

5

Minimum TTL ratio:

15

Maximum dynamic server:

1023

Health check:

none

Current connection:

0

Current request:

0

Total connection:

1919

Total request:

1919

Total request success:

1877

Total forward bytes:

546650

Total forward packets:

5715

Total reverse bytes:

919730

Total reverse packets:

5631

The following command displays service-group information. A separate row of information appears for each dynamically created member. AX#show slb service-group Total Number of Service Groups configured: 40 Current = Current Connections, Total = Total Connections Fwd-p = Forward packets, Rev-p = Reverse packets Service Group Name Service

Current

Total

Fwd-p

Rev-p

----------------------------------------------------------------------*sg-test

State: All Up

DRS-10.4.2.6-s2.test.com:80

0

0

0

0

DRS-10.4.2.5-s1.test.com:80

36

1919

5714

5631

s-test2:80

0

53

265

212

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

901 of 732

AX Series - Configuration Guide Configuring Dynamic Real Server Creation The following command displays detailed statistics for the dynamically created service-group : AX#show slb service-group sg-test Service group name: sg-test

State: All Up

Service selection fail drop:

0

Service selection fail reset:

0

Service: DRS-10.4.2.6-s2.test.com:80

UP

Forward packets:

0

Reverse packets:

0

Forward bytes:

0

Reverse bytes:

0

Current connections:

0

Persistent connections:

Current requests:

0

Total requests:

Total connections:

0

Total requests succ:

Forward bytes:

0

Response time: 0.00

msec

0

Service: DRS-10.4.2.5-s1.test.com:80 Forward packets:

5715 546650

UP

Reverse packets:

5631

Reverse bytes:

919730

Current connections:

10

Persistent connections:

Current requests:

10

Total requests:

Total connections:

1919

Total requests succ:

0

1919

Response time: 0.00

msec

1877

Service: s-test1:80

UP

Forward packets: Forward bytes:

0

450 31500

Reverse packets: Reverse bytes:

360 44820

Current connections:

0

Persistent connections:

Current requests:

0

Total requests:

Total connections:

90

Total requests succ:

1877

Response time: 0.00

0

0 msec

The following command displays configuration information for the service group. In this example, the service group has dynamic and a static member. AX#show slb service-group sg-test config Service group name: sg-test Type: t

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

902 of 732

Priority: 1

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

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 ed 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 s this feature only for DNS ports on the

default DNS port number (T port 53 or UDP port 53).

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

903 of 732

AX Series - Configuration Guide

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

904 of 732

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

Sending a Reset After Server Selection Failure The AX device provides an option or send a T 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 192 on page 906 shows an example of a Policy-Based SLB (PBSLB) solution that uses the reset-on-server-selection-fail option. Note:

P e r f o r m a n c e

b y

The T 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 11/3/2010

905 of 732

AX Series - Configuration Guide FIGURE 192

906 of 732

PBSLB Used With reset-on-server-selection-fail Option

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide This deployment categorizes clients as follows: • White-list clients • Grey-list clients • Black-list clients

In this solution, if a white-list client exceeds the connection limit specified in the black/white list, the AX device sends a RST to the client. However, if a grey-list or black-list client exceeds its connection limit, the AX device drops the connection, instead of sending a RST. To implement this solution, a separate service group is configured for each client category. In the black/white list, each client is assigned to one of the service groups, according to the client’s category. For example, client 192.168.1.1 is a white-list client, and is therefore assigned to the white-list service group. To configure the AX device to send a RST to white-list clients upon server selection failure, but not to grey-list or black-list clients, the reset-on-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 P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

907 of 732

AX Series - Configuration Guide 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 192 on page 906. The following commands configure the real servers: AX(config)#slb server ms1 10.10.10.11 AX(config-real server)#port 25 AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server ms2 10.10.10.12 AX(config-real server)#port 25 AX(config-real server-node port)#exit AX(config-real server)#exit AX(config)#slb server ms3 10.10.10.13 AX(config-real server)#port 25 AX(config-real server-node port)#exit AX(config-real server)#exit

The following commands configure the service groups: 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)#exit AX(config)#slb service-group grey-list AX(config-slb service group)#member ms2:25 AX(config-slb service group)#exit AX(config)#slb service-group black-list AX(config-slb service group)#member ms3:25 AX(config-slb service group)#exit

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 AX(config-policy)#exit

908 of 732

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 t 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

909 of 732

AX Series - Configuration Guide

910 of 732

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

Scan-All- Option in Persistence Templates In cookie, source-IP, and destination-IP persistence templates, the match-type server option has a suboption called scan-all-. The scan-all- option allows a persistent session to continue even when the real server port the session is on becomes unavailable. This chapter describes the scan-all- 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. Figure 193 shows an example.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

911 of 960

AX Series - Configuration Guide FIGURE 193

Scan-all-

VIP 192.168.10.11 uses 3 real servers to provide HTTP service. Two of the servers have a single protocol port for HTTP. However, one of the servers has HTTP service on multiple service ports. For a new session, the SLB load-balancing method enabled on the service group is used to select a server and port for the client (source IP address). Because source-IP persistence is enabled, subsequent requests from the same client are always sent to the same server. By default, when the match-type is changed to match-type server, the AX device uses the service group’s load-balancing method for the first request to select a service-group member (server+port). For subsequent connections from the same client, the AX device uses fast-path processing to select the first service-group member that has the same IP address as the server that was initially selected by the service group’s load-balancing method for the first request.

912 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide In this example, if the load-balancing method happens to choose port 80 on server s3 for the first request, subsequent connections also are sent to port 80 on s3, since port 80 is in the first member (server+port) for s3 listed in the service-group configuration. Because the match-type is set to matchtype server, if port 80 goes down, the next request for the persistent session is still sent to s3, but to a different port on s3. If the load-balancing method happens to choose port 8080 on server s3 for the first request, subsequent requests are sent to port 80 on s3, since port 80 is in the first member (server+port) for s3 listed in the service-group configuration. However, if the member (port 80 on s3) is set to a lower priority or is istratively disabled, the AX device again will use the load-balancing method to select a server and port for the next request. Any of the available service-group can be selected, even if they are different servers. In this case, it is possible that a different server will be selected for the next request. For example, if an needs to perform some maintenance on port 80, and disables that 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. In a match-type server configuration, to ensure that sessions do remain persistent on the same server if a member is istratively disabled or is set to a lower priority, use the scan-all- option. In this case, the AX device selects the first available service-group member on the same server as the member that is out of service. In this example, if s3:80 is disabled or is set to a lower priority, the AX device selects the next member on the same server, s3:8080. When s3:80 is available again, it is selected for any new connections. However, connections that are already in existence when s3:80 comes back up continue to go to s3:8080. CLI Example The commands in this section configure the source-IP persistence template and service group in Figure 193 on page 912. 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- AX(config-source ip persistence template)#exit

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

913 of 960

AX Series - Configuration Guide The following commands configure the service group: AX(config)#slb service-group sg-1 AX(config-slb service group)#member s1:80 AX(config-slb service group)#member s2:80 AX(config-slb service group)#member s3:80 AX(config-slb service group)#member s3:8080 AX(config-slb service group)#member s3:8081 AX(config-slb service group)#exit

The following commands configure the virtual server: AX(config)#slb virtual-server vip1 192.168.10.11 AX(config-slb vserver-vport)#service-group sg-1 AX(config-slb vserver-vport)#template persist source-ip persist-source

914 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 225.)

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 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 client’s data, then send an encrypted reply to the client. The client will decrypt the server reply, and so on. Note:

SSL is an older version of TLS. The AX device s SSL version 3.0 and TLS version 1.0. The AX device also s RFC 3268: “AES Ciphersuites for TLS”. For simplicity, elsewhere this document and other AX documents use the term “SSL” to mean both SSL and TLS.

Note:

The AX device s Privacy Enhanced Mail (PEM) format for certificate files and CRLs. AX SSL processing s 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 server’s identity. From the client’s perspective, this certificate comes from the server. Once the SSL handshake is complete, the client begins an encrypted client-server session with the AX device. P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

915 of 960

AX Series - Configuration Guide Overview Figure 194 shows a simplified example of an SSL handshake. In this example, the AX device is acting as an SSL proxy for backend servers. FIGURE 194

Typical SSL Handshake (simplified)

To begin, the client sends an HTTPS request. The request includes some encryption details such as the cipher suites ed 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

916 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 CA’s certificate. If the CA that signed the server certificate is not a root CA, the client browser should have another certificate or a certificate chain that includes the CA that signed the CA’s certificate. A certificate chain contains the “chain” of signed certificates that leads from the CA to the signature authority that signed the certificate for the server. Typically, the certificate authority that signs the server certificate also will provide the certificate chain. Figure 195 shows an example of a certificate chain containing three certificates: FIGURE 195

SSL Certificate Chain Example

-----BEGIN CERTIFICATE----ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw Oi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQAD gYEAheIVEe8vArUOZxKkUIGjaYymzJAh8Ty0uUPrikLpQ0IGezByVdbDUJ+HQLGp 2eruTPZpBNADaEfymstIPIxrsuCRhyr3Ymsa2rgzwy9kSXeG83H7E7HxRnpxDNZ8 l+uzpU/rk4j3bO/JVxPZMnwzMWriPSYgL1EKYcOSKyReaxQ= -----END CERTIFICATE---------BEGIN CERTIFICATE----ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw Oi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQAD gYEAheIVEe8vArUOZxKkUIGjaYymzJAh8Ty0uUPrikLpQ0IGezByVdbDUJ+HQLGp 2eruTPZpBNADaEfymstIPIxrsuCRhyr3Ymsa2rgzwy9kSXeG83H7E7HxRnpxDNZ8 l+uzpU/rk4j3bO/JVxPZMnwzMWriPSYgL1EKYcOSKyReaxQ= -----END CERTIFICATE---------BEGIN CERTIFICATE----ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw Oi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQAD gYEAheIVEe8vArUOZxKkUIGjaYymzJAh8Ty0uUPrikLpQ0IGezByVdbDUJ+HQLGp 2eruTPZpBNADaEfymstIPIxrsuCRhyr3Ymsa2rgzwy9kSXeG83H7E7HxRnpxDNZ8 l+uzpU/rk4j3bO/JVxPZMnwzMWriPSYgL1EKYcOSKyReaxQ= -----END CERTIFICATE-----

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

917 of 960

AX Series - Configuration Guide Overview The certificate chain file and the server certificate files are text files. Each certificate must begin with the “-----BEGIN CERTIFICATE-----” line and end with the “-----END CERTIFICATE-----” line. The certificate at the top of the certificate chain file is the root CA’s 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 CA’s 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 195.

Certificate Warning from Client Browser After the client browser validates the server certificate, the client accepts the certificate and begins an encrypted session with the AX device. If the client can not validate the server certificate or the certificate is out of date, the client’s browser may display a certificate warning. Figure 196 shows an example of a certificate warning displayed by Internet Explorer. FIGURE 196

Note:

918 of 960

Example of Certificate Warning

It is normal for the AX device to display a certificate warning when an accesses the AX management GUI. Certificates used for SLB are not used by the management GUI.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 creates a key and a Certificate g Request (CSR), and sends the CSR to the CA.The CSR includes the key. The CA then creates and signs a certificate. The 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 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 917.) The example in Figure 194 on page 916 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 client’s browser may display a certificate warning. This can be alarming or confusing to end s. s can select the option to trust a self-signed certificate, in which case the warning will not re-appear.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

919 of 960

AX Series - Configuration Guide 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 194 on page 916, 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 server’s 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 917.) • 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.

920 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Overview The CRL should be signed by the same issuer as the CA certificate. Otherwise, the client and AX device will not be able to establish a connection.

Note:

• 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 ed by the AX device.

When the client sends its connection request, it also sends a list of the cipher suites it can . The AX device selects the strongest cipher suite ed 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_DES_192_CBC3_SHA • SSL3_RSA_DES_40_CBC_SHA • SSL3_RSA_DES_64_CBC_SHA • SSL3_RSA_RC4_128_MD5 • SSL3_RSA_RC4_128_SHA • SSL3_RSA_RC4_40_MD5 • TLS1_RSA_AES_128_SHA • TLS1_RSA_AES_256_SHA • TLS1_RSA_EXPORT1024_RC4_56_MD5 • TLS1_RSA_EXPORT1024_RC4_56_SHA • Session cache size – Specifies the maximum number of cached sessions for SSL session ID reuse.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

921 of 960

AX Series - Configuration Guide Overview Server-SSL Template Options A server-SSL template is needed only if traffic between the AX device and real servers will be encrypted using SSL. In this case, the AX device will be required to validate the identities of the servers. • CA certificate – Specifies a CA certificate that the AX device can use to

validate the identity of a server. • Cipher list – Specifies the cipher suites ed by the AX device.

When the server sends its connection request, it also sends a list of the cipher suites it can . The AX device selects the strongest cipher suite ed by the server that is also enabled in the template and uses that cipher suite for traffic with the server. The same cipher suites ed in client-SSL templates are ed in server-SSL templates. 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 919). 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 925 and “Importing a Certificate and Key” on page 928. 1. Create an encryption key. 2. Create a Certificate g 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.

922 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 CA’s public key from the CA, import them onto the AX device. • If the key and certificate are provided by the CA in separate files

(PKCS #7 format), import the certificate. You do not need to import the key if the CSR was created on the AX device. In this case, the key is already on the AX device. If the certificate is not in PEM 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 937. 5. If applicable, import the certificate chain onto the AX device. The certificate chain must be a single text file, beginning with a root CA’s certificate at the top, followed in order by each intermediate g authority’s certificate. (See “Certificate Chain” on page 917.) Figure 197 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.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

923 of 960

AX Series - Configuration Guide Overview FIGURE 197

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 client’s browser is still likely to display a certificate warning to the end .

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

924 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Generating a Key and CSR for a CA-Signed Certificate

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 Phrase and Confirm 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 phrase. 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 g 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 . Note:

If the browser security settings normally block s, you may need to override the setting. For example, in Internet Explorer, hold the Ctrl key while clicking . b. Click Save. c. Navigate to the save location. d. Click Save again.

Note:

P e r f o r m a n c e

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 11/3/2010

925 of 960

AX Series - Configuration Guide Generating a Key and CSR for a CA-Signed Certificate 11. When you receive the certificate from the CA, import it onto the AX device. (See “Importing a Certificate and Key” on page 928.)

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, name (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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file • http://[@]host/file • https://[@]host/file

This command displays a series of prompts, for the following information: • IP address of the server to which to export the CSR • name for write access to the server • 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 • phrase to use for the key, 0-31 characters

926 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Generating a Key and CSR for a CA-Signed Certificate 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: Address or name of remote host []?192.168.1.10 name []?ax []?******** 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:[email protected] input Phrase, 0~31:csrpword Confirm Phrase:csrpword AX(config)#import ca-signedcert1 ftp: Address or name of remote host []?192.168.1.10 name []?ax []?******** File name [/]?ca-signedcert1

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

927 of 960

AX Series - Configuration Guide Importing a Certificate and Key

Importing a Certificate and Key To import certificate and key files, place them on the PC that is running the GUI or CLI session, or onto a PC or file server that can be locally reached over the network. Note:

If you are importing a CA-signed certificate for which you used the AX device to generate the CSR, you do not need to import the key. The key is automatically generated on the AX device when you generate the CSR.

USING THE GUI 1. Select Config > Service > SSL Management, if not already selected. 2. On the menu bar, select Certificate. 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, R, or S. – 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 and fields, enter the name and required for access to the remote server.

928 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Importing a Certificate and Key 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, name (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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file • http://[@]host/file • https://[@]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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

929 of 960

AX Series - Configuration Guide Generating a Self-Signed Certificate

Generating a Self-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 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 global configuration level of the CLI: 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

930 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Generating a Self-Signed Certificate • 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 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:[email protected] 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

931 of 960

AX Series - Configuration Guide 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 1. Select Config > Service > SSL Management, if not already selected. 2. On the menu bar, select Cert Revocation List. 3. Click Import. 4. Click Browse and navigate to the location of the CRL. 5. Click Open. The path and filename appear in the Source field. 6. Click OK.

USING THE CLI To import a CRL, use the following command at the Privileged EXEC or global Config level of the CLI: import ssl-crl file-name url The url specifies the file transfer protocol, name (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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file

932 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Exporting Certificates, Keys, and CRLs

Exporting Certificates, Keys, and CRLs Exporting a Certificate and Key USING THE GUI 1. Select Config > Service > SSL Management, if not already selected. 2. On the menu bar, select Certificate. 3. To export a certificate: a. Select the certificate. (Click the checkbox next to the certificate name.) b. Click Export. If the browser security settings normally block s, you may need 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 The url specifies the file transfer protocol, name (if required), directory path, and filename.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

933 of 960

AX Series - Configuration Guide Exporting Certificates, Keys, and CRLs 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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file

Exporting a CRL USING THE CLI To export a CRL, use the following command at the Privileged EXEC or global Config level of the CLI: export ssl-crl file-name url

USING THE GUI 1. Select Config > Service > SSL Management, if not already selected. 2. On the menu bar, select Cert Revocation List. 3. Select the CRL. (Click the checkbox next to the CRL name.) 4. Click Export. Note:

If the browser security settings normally block s, you may need 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:

934 of 960

The CLI does not export of CRLs.

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide 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 1. Select Config > Service > Template. 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 920, the AX Series GUI Reference, or the online help.) 5. When finished, click OK.

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 920 or the AX Series CLI Reference.)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

935 of 960

AX Series - Configuration Guide Converting Certificates and CRLs to PEM Format

Binding an SSL Template to a VIP USING THE GUI 1. Select Config > Service > SLB. 2. On the menu bar, select Virtual Server. 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.

Converting Certificates and CRLs to PEM Format The AX device s 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:

936 of 960

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

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Converting Certificates and CRLs to PEM Format imported certificate into PEM format. (See “Importing a Certificate and Key” on page 928.)

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 , Service , and Computer . e. Select Computer 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 phrase to use to encrypt the key.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

937 of 960

AX Series - Configuration Guide Converting Certificates and CRLs to PEM Format 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 phrase from the key, use the following command: $ openssl rsa -in encrypted.key -out unencrypted.key Note:

Although removing the phrase is optional, A10 Networks recommends that you remove the phrase 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

938 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Route Tables

Using the Management Interface as the Source for Management Traffic By default, the AX device attempts to use a route from the main route table for management connections originated on the AX device. You can enable the AX device to use the management route table to initiate management connections instead. This chapter describes the AX device’s two route tables, for data and 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:

P e r f o r m a n c e

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 11/3/2010

939 of 960

AX Series - Configuration Guide Management Routing Options connected to the management interface, and the IP default gateway configured on the management interface. When you 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.

Management Routing Options You can configure the AX device to use the management interface as the source interface for the following management protocols, used for automated management traffic: • SYSLOG • SNMPD • NTP • RADIUS • TACACS+ • SMTP

For example, when use of the management interface as the source interface for control traffic is enabled, all log messages sent to remote log servers are 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:

940 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Management Routing Options • Upgrade of the AX software • SSH or Telnet connection to a remote host • Import or export of files • Export of show tech 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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

941 of 960

AX Series - Configuration Guide Management Routing Options

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 ed with the following commands.

Commands at the EXEC Level ssh [use-mgmt-port] {host-name | ipaddr) -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) -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

942 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Management Routing Options [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 tech [[use-mgmt-port] export url] [page]

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

943 of 960

AX Series - Configuration Guide Management Routing Options

944 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.2 11/3/2010

AX Series - Configuration Guide Backing Up System Information

Configuration Management By default, when you click the Save button in the GUI or enter the write memory command in the CLI, all unsaved configuration changes are saved to the startup-config. The next time the AX device is rebooted, the configuration is reloaded from this file. In addition to these simple configuration management options, the AX device has advanced configuration management options that allow you to save multiple configuration files. You can save configuration files remotely on a server and locally on the AX device itself. Note:

For information about managing configurations for separate partitions on an AX device configured for Role-Based istration (RBA), see “Role-Based istration” on page 701.

Note:

For information about synchronizing configuration information between AX devices in a High Availability (HA) pair, see “Synchronizing Configuration Information” on page 556.

Note:

For upgrade instructions, see the release notes for the AX release to which you plan to upgrade.

Backing Up System Information The AX device allows you to back up the system, individual configuration files, and even log entries onto remote servers. You can use any of the following file transfer protocols: • Trivial File Transfer Protocol (TFTP) • File Transfer Protocol (FTP) • Secure Copy Protocol (S) • Unix Remote Copy (R)

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

945 of 960

AX Series - Configuration Guide Backing Up System Information

USING THE GUI 1. Select Config > System > Maintenance. 2. Select one of the following from the menu bar: • Backup > System – This option backs up the configuration file(s),

aFleX 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 device’s syslog buffer. (If there are any core files on the system, this option backs them up as well.) 3. Select the backup location: • Local – Saves the backup on the PC or workstation where you are

using the AX GUI. • Remote – Saves the backup onto another PC or workstation. 4. If you selected Local: a. Click OK. b. Click Save and navigate to the save location. Optionally, you can edit the filename. c. Click Save. 5. If you selected Remote: a. In the Protocol drop-down list, select the file transfer protocol: FTP, TFTP, R, or S. 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 and fields, enter the name and required for write access to the remote device. f. Click OK.

946 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Saving Multiple Configuration Files Locally

USING THE CLI At the Privileged EXEC level of the CLI, use the following command: backup {config | log} url The config option backs up the startup-config file, aFleX scripts, and SSL certificates and keys. The log option backs up the log entries in the AX device’s syslog buffer. The url option specifies the file transfer protocol, name, 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 is required, you will still be prompted for the . To enter the entire URL: • tftp://host/file • ftp://[@]host[:port]/file • s://[@]host/file • r://[@]host/file

Saving Multiple Configuration Files Locally The AX device has CLI commands that enable you to store and manage multiple configurations on the AX device. Note:

Unless you plan to locally store multiple configurations, you do not need to use any of the advanced commands or options described in this section. Just click Save in the GUI or enter the write memory command in the CLI to save configuration changes. These simple options replace the commands in the startup-config stored in the image area the AX device booted from with the commands in the running-config.

Note:

Management of multiple locally stored configuration files is not ed in the GUI.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

947 of 960

AX Series - Configuration Guide Saving Multiple Configuration Files Locally

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 s are loaded as part of the system configuration, they are not saved in the configuration profiles. Changes to the enable or to the name or 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.

948 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Saving Multiple Configuration Files Locally 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: P e r f o r m a n c e

b y

Copying a profile from the compact flash to the hard disk is not ed.

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

949 of 960

AX Series - Configuration Guide Saving Multiple Configuration Files Locally (The url option backs up the configuration to a remote device. See “Backing Up System Information” on page 945.) 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.

950 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Saving Multiple Configuration Files Locally 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 profile’s name. The command deletes only the profile you specify.

Note:

If the configuration profile you specify is linked to “startup-config”, “startup-config” is automatically relinked to the default. (The default is the configuration profile stored in the image area from which the AX device most recently rebooted).

CLI EXAMPLES The following command saves the running-config to a configuration profile named “slbconfig2”: AX(config)#write memory slbconfig2

The following command shows a list of the configuration profiles locally saved on the AX device. The first line of output lists the configuration proP 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 11/3/2010

951 of 960

AX Series - Configuration Guide Saving Multiple Configuration Files Locally file that is currently linked to “startup-config”. If the profile name is “default”, then “startup-config” is linked to the configuration profile stored in the image area from which the AX device most recently rebooted. AX(config)#show startup-config all Current Startup-config Profile: slb-v6 Profile-Name

Size

Time

-----------------------------------------------------------1210test

1957

Jan 28

18:39

ipnat

1221

Jan 25

10:43

ipnat-l3

1305

Jan 24

18:22

ipnat-phy

1072

Jan 25

19:39

ipv6

2722

Jan 22

15:05

local-bwlist-123

3277

Jan 23

14:41

mgmt

1318

Jan 28

10:51

slb

1354

Jan 23

18:12

slb-v4

12944

Jan 23

19:32

slb-v6

13414

Jan 23

19:19

The following command copies the configuration profile currently linked to “startup-config” to a profile named “slbconfig3”: AX(config)#copy startup-config slbconfig3

The following command compares the configuration profile currently linked to “startup-config” with configuration profile “testcfg1”. This example is abbreviated for clarity. The differences between the profiles are shown in this example in bold type.

952 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide Saving Multiple Configuration Files Locally 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

t

<

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

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

953 of 960

AX Series - Configuration Guide Saving Multiple Configuration Files Locally

954 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

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 ed 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 ed. If the AX device is deployed in gateway mode, a Virtual Ethernet (VE) interface is required in the bridge VLAN group.

P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

955 of 960

AX Series - Configuration Guide

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 device’s interfaces to the VLAN. 2. Configure a bridge VLAN group. Add the VLANs to the group. If the AX device is deployed in gateway mode, add a Virtual Ethernet (VE) interface to the group. Optionally, you can assign a name to the group. You also can change the types of traffic to be bridged between VLANs in the group. 3. If the AX device is deployed in gateway mode, configure an IP address on the VE to place the AX device in the same subnet as the bridged VLANs.

USING THE CLI To configure a bridge VLAN group, use the following commands. [no] bridge-vlan-group group-num Use this command at the global configuration level of the CLI to create the bridge VLAN group and enter the configuration mode for it, where the following commands are available. The group-num can be 1-64. [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

956 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

AX Series - Configuration Guide

Group Information and Statistics To display information for a bridge VLAN group, use the following command: show bridge-vlan-group [group-id] CLI Example – Transparent Mode The commands in this section configure an AX device deployed in transparent mode to forward IP traffic between VLANs 2 and 3. The following commands configure the VLANs: AX(config)#vlan 2 AX(config-vlan:2)#tagged ethernet 2 AX(config-vlan:2)#exit AX(config)#vlan 3 AX(config-vlan:3)#tagged ethernet 3 AX(config-vlan:3)#exit

The following commands configure the bridge VLAN group: AX(config)#bridge-vlan-group 1 AX(config-bridge-vlan-group:1)#vlan 2 to 3 AX(config-bridge-vlan-group:1)#exit

CLI Example – Gateway Mode The commands in this section configure an AX device deployed in gateway mode to forward IP traffic between VLANs 2 and 3 on IP subnet 192.168.1.x. The following commands configure the VLANs: AX(config)#vlan 2 AX(config-vlan:2)#tagged ethernet 2 AX(config-vlan:2)#exit AX(config)#vlan 3 AX(config-vlan:3)#tagged ethernet 3 AX(config-vlan:3)#exit

The following commands configure the bridge VLAN group, which includes a VE: AX(config)#bridge-vlan-group 1 AX(config-bridge-vlan-group:1)#vlan 2 to 3 AX(config-bridge-vlan-group:1)#router-interface ve 1 AX(config-bridge-vlan-group:1)#exit P e r f o r m a n c e

b y

D e s i g n Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

957 of 960

AX Series - Configuration Guide The following commands assign an IP address to the VE: AX(config)#interface ve 1 AX(config-if:ve1)#ip address 192.168.1.100 /24 AX(config-if:ve1)#exit

958 of 960

P e r f o r m a n c e

b y

D e s i g n

Document No.: D-030-01-00-0006 - Ver. 2.4.3 11/3/2010

P e r f o r m a n c e

960

b y

D e s i g n

P e r f o r m a n c e

b y

D e s i g n

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

This document is for informational purposes only. A10 Networks MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the . Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of A10 Networks Corporation. A10 Networks may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from A10 Networks, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2010 A10 Networks Corporation. All rights reserved. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

960

A10 Ax Confguration Guide 2p6k1h

Overview 26281t

More details 6y5l6z

Related Documents 3h463d

A10 Ax Confguration Guide 2p6k1h

A10 Networks Waf Guide ax6i

Microsoft Dynamics Ax Installation Guide 5r4w25

Microsoft Dynamics Ax Implementation Guide 6t4n6c

A10 Thunder Series 1040_1040s_940 Installation Guide 2m6p2y

Ax-ref 2p3137

More Documents from "Rudolf TheRednose Reindeer" 296t2w

Ax_cli_ref_v2_4_3-20101103 6f134v

A10 Ax Confguration Guide 2p6k1h

Monografia El Parkinson 3b17f

The Android Arsenal - Dialogs - Prettydialog 383q1e

The Android Arsenal - Dialogs - Dialogplus 4q396f

The Android Arsenal - Dialogs - Spots Progress Dialog 474l1j